Sprint Planning Template for One-Week Sprints
One-week sprints create a forcing function for small, shippable work. They eliminate the "we will finish it next sprint" trap that plagues two-week sprints, and they create weekly shipping momentum that builds team confidence. The tradeoff is that every meeting and process must be lean — a two-hour planning meeting is 5% of a one-week sprint, which is unsustainable.
This template is optimized for the weekly cadence: a 30-minute Monday planning session, a lightweight Wednesday check-in to catch blockers early, and a combined Friday demo-and-retro that wraps the week. It assumes your backlog is pre-refined and prioritized before Monday — if stories are not ready to pull, one-week sprints will fail within three weeks.
Why one-week sprints work (and when they do not)
One-week sprints excel when your team ships frequently and the work is naturally decomposable into small pieces. For teams doing continuous delivery, weekly sprints align planning with deployment cadence. For early-stage products where learning is the primary objective, weekly cycles compress the feedback loop: build, ship, learn in seven days instead of fourteen.
The critical prerequisite is story discipline. In a two-week sprint, a three-point story that takes five days is recoverable. In a one-week sprint, it is a crisis. Every story pulled into a one-week sprint must be completable by one engineer in two to three days at most. This forces better story slicing — which is actually a skill that makes your team faster at any sprint length.
One-week sprints do not work well for platform-level work, major architectural changes, or teams with high interrupt load (on-call rotations, heavy customer support). For those contexts, consider Kanban or two-week sprints with a dedicated 20% buffer for interrupts. Running one-week sprints on inherently two-week work just creates a pattern of broken commitments.
Template sections
4 sections covering the complete sprint planning workflow.
Monday planning session (30 minutes maximum)
The planning session covers exactly three things: the sprint goal in one sentence, story selection from the pre-refined backlog, and a capacity check. If you are spending more than 30 minutes, you are refining stories during planning — which means the backlog was not ready and you need to fix your refinement process.
Sprint 47 Goal: Users can invite teammates via CSV bulk upload and the invitation email contains a personalized onboarding link. Stories selected: [T-89, T-90, T-91, T-94] = 14 points Capacity: 3 engineers × 5 days × 70% (meetings, reviews) = ~10 eng-days available
Tips
- The sprint goal must be a business outcome, not a list of stories: "Users can do X" not "Complete T-89 and T-90"
- Pull 80% of capacity into planned stories — leave 20% as buffer for reviews, bugs, and unplanned work that always appears in week-long cycles
- If any story is estimated above 3 points (more than 1.5 days), it must be split before pulling into the sprint — this is a hard rule, not a guideline
Story size constraints
In one-week sprints, story size is the most important quality metric. Every story must be completable by one engineer in two to three days at most — ideally one day for a healthy velocity. Stories estimated at three or more days must be split before the sprint starts. Common splitting patterns: separate the API from the UI, separate the happy path from edge cases, separate the feature from the analytics.
BAD: "Implement user invitation flow" (5 days) GOOD: - T-89: API endpoint for sending invitations (1 day) - T-90: Invitation email template and delivery (1 day) - T-91: Frontend invitation form with validation (1.5 days) - T-92: Acceptance flow for invited users (1 day)
Tips
- If engineers consistently underestimate, run a capacity calibration: track planned vs actual hours for four sprints and adjust your velocity baseline
- Thin vertical slices (API + UI + test) are better than horizontal layers (API only, then UI later) — they ship value and reveal integration issues early
- The "but we need the whole feature" objection is usually wrong: every feature has a minimum useful increment. Find it.
Wednesday mid-week check-in (15 minutes)
At mid-week in a one-week sprint, there is zero margin for blocked work. A quick Wednesday check-in — async in Slack or a 15-minute stand-up — surfaces blockers with enough time to resolve them before Friday. Each engineer answers: what did I ship, what is in progress, and is anything blocked?
Wed check-in format (post in #sprint channel by noon): → T-89 API endpoint: shipped to staging ✓ → T-90 Email template: in review, PR linked → T-91 Frontend form: in progress, blocked on design sign-off for error states — tagging @sarah
Tips
- Make Wednesday check-ins async by default — a Slack thread is faster and creates a searchable record of mid-sprint status
- The PM's job in the Wednesday check-in is to immediately resolve any dependency or decision block that engineers surface — do not let a blocker sit for 24 hours in a one-week sprint
- If more than one story is blocked on Wednesday, assess whether the sprint goal is still achievable and communicate proactively to stakeholders
Friday demo and retro (30 minutes)
Combine the sprint demo and retrospective into a single 30-minute Friday session. Spend the first 15 minutes on a live demo of everything shipped — each engineer demos their own work. Spend the final 15 minutes on a focused retrospective with one question: "What one change would make next week better?"
Friday 4:30pm — Sprint 47 Demo + Retro Demo (15 min): - T-89/90: Invitation API + email — [Engineer name] demos in staging - T-91: Invitation form — [Engineer name] demos in staging Retro question: "What one thing would make Sprint 48 go smoother?" Top answer: "Stories need design sign-off before pulling into sprint" → Action: add to Definition of Ready
Tips
- Demos must be live in staging — screenshots or Loom recordings are not demos
- One retro question keeps the meeting under 15 minutes. If you want more depth, alternate with a full retrospective every third sprint
- Publish a one-paragraph sprint summary in Slack after the Friday meeting — this creates visibility for stakeholders and builds a culture of shipping
Copy-paste template
# Sprint [N] — Week of [Start Date] ## Sprint Goal [One sentence: the business outcome this sprint delivers. Not a list of tickets.] --- ## Stories | ID | Story | Est. (days) | Owner | Status | |---|---|---|---|---| | [T-XX] | [Story description] | [1] | [Engineer name] | Not started | | [T-XX] | [Story description] | [1.5] | [Engineer name] | Not started | | [T-XX] | [Story description] | [1] | [Engineer name] | Not started | **Total estimated:** [X] days | **Team capacity:** [Y] days (at 80%) | **Buffer:** [Z] days --- ## Capacity | Engineer | Availability | Notes | |---|---|---| | [Name] | 4 days | OOO Friday | | [Name] | 5 days | Full week | --- ## Wednesday Check-In (post by noon) > Format: [Ticket] — [Status]. Blocked on: [Blocker or "none"]. | Engineer | T-XX Status | T-XX Status | Blocked? | |---|---|---|---| | [Name] | In progress | — | No | --- ## Friday Demo + Retro Notes **Shipped:** - [T-XX]: [What was built and demoed] **Carried over (why):** - [T-XX]: [Brief reason — estimation, blocker, scope change] **Retro question:** What one change would make next sprint go better? **Top answer → Action item:** - Action: [Specific change] — Owner: [Name] — Done by: [Monday of next sprint]
Frequently asked questions
Generate instead of filling in templates
Connect your tools, and Vantage generates the content using real product data. Free to start.
Free to start. No credit card required.