How long should sprint planning take?

Forty-five minutes to one hour for a two-week sprint, assuming the PM has done pre-planning. If your sprint planning regularly exceeds 90 minutes, either the backlog is not ready (add pre-planning) or you have too many people in the room (reduce attendees). The Scrum Guide suggests up to 8 hours for a month-long sprint, but most teams that follow that guidance end up wasting half the time.

Should the PM estimate or should engineers estimate?

Engineers estimate. Always. The PM provides context about priority and acceptance criteria. The PM should never say "this should be small" because it biases the estimate downward. If you disagree with an estimate, ask questions: "Help me understand what makes this complex." You might learn something about the codebase. Or the engineer might realize it is simpler than they thought. Either way, the conversation is more productive than arguing about numbers.

How do we handle urgent requests mid-sprint?

Every team needs a protocol for interrupts. Here is one that works: if the request is truly urgent (production is down, critical customer blocked), it enters the sprint and something of equal size comes out. The PM decides what gets removed. If the request can wait 5 business days, it goes into the next sprint's backlog. If someone claims everything is urgent, escalate to their manager. "Urgent" without consequences is just "I want this now."

What if the team consistently overcommits?

Track commitment vs. completion over 4-6 sprints. If the team regularly finishes 70% of committed work, reduce sprint scope by 30%. Overcommitment is a trust problem: the team tells the PM what the PM wants to hear instead of what is realistic. Fix it by celebrating accurate estimation, not high output. "We committed to 12 stories and finished 12" is a better sprint than "we committed to 18 and finished 13."

Should we do sprint planning on Monday or Friday?

Monday. Planning on Friday means the team forgets the details over the weekend and spends Monday morning re-reading the sprint board. Planning on Monday means engineers can start work immediately. Use Friday for the retrospective and backlog grooming so you walk into Monday planning with a clean, prioritized backlog.

Sprint Planning Done Right

TL;DR: Sprint planning meetings average 2 hours and produce 30 minutes of value. Here's how to fix that with better prep, tighter scope, and a format engineers won't dread.

Two Hours of Your Team's Life, Every Two Weeks

That is what sprint planning costs. Ten people in a room for two hours means 20 person-hours. If your team runs two-week sprints, that is 520 person-hours per year on a single meeting. And most of it is wasted.

The typical sprint planning session looks like this: the PM presents a list of tickets. The Scrum Guide defines sprint planning as a collaborative event, but in practice most teams treat it as a PM presentation. The team argues about estimates. Someone brings up a tech debt item that is not on the list. The discussion spirals. Two hours later, the team commits to roughly what they would have committed to anyway, minus the two items they argued about for 40 minutes.

There is a better way. It starts before the meeting.

Pre-Planning: The Work Before the Work

The single biggest mistake PMs make with sprint planning is walking into the meeting with a backlog that is not ready. "Ready" means every item the team might pull into the sprint meets these criteria:

Clear acceptance criteria. Not "improve the onboarding flow." Instead: "New users see a progress bar during setup. The bar shows 4 steps. Users can skip step 3 (optional integrations) and return to it later. Skipping step 3 takes the user directly to the dashboard."

Edge cases documented. At least the obvious ones. What happens if the user's session expires mid-setup? What if they have already connected one integration and come back to add another? You will not catch every edge case, but the effort of thinking through the common ones prevents 30-minute tangents during planning.

Design ready (if applicable). Link to the Figma file. If design is still in progress, the ticket is not ready for sprint planning. Pulling in a story with pending design is how you get developers blocked on day 2 of the sprint.

Dependencies identified. If a story requires an API that another team is building, note the dependency and its status. If the dependency is not resolved, the story should not enter the sprint. Nothing destroys sprint velocity like a team sitting idle because another team has not finished their part.

The pre-planning work takes 2-3 hours per sprint. It is the PM's job, not the team's. If you invest those 3 hours, the planning meeting itself takes 45 minutes instead of two hours. That is a net win of 75 minutes for the entire team every sprint.

Who Should Be in the Room

Sprint planning has a recurring attendee problem: too many people. Here is who needs to be there and who does not.

Must attend:

PM (owns the priorities and acceptance criteria)
Tech lead or engineering manager (owns feasibility and estimation)
Engineers who will do the work (own the commitment)

Optional:

Designer (only if there are design-heavy stories that need clarification)
QA lead (only if the team has dedicated QA and testing approach needs discussion)

Should not attend:

Other PMs (unless there is a specific cross-team dependency to discuss)
Stakeholders (they get the sprint plan afterward, not during)
Managers who are not directly involved in execution

Every extra person adds communication overhead and extends discussion time. A team of 6 in sprint planning is twice as efficient as a team of 12. If people need to know the outcome, send them the sprint plan afterward.

The Meeting Itself: A 45-Minute Format

Here is a format that respects everyone's time. It assumes pre-planning is done.

Part 1: Sprint goal (5 minutes)

The PM states the sprint goal in one sentence. Not a list of tickets. A goal. "This sprint, we are shipping the self-service onboarding flow so new users can reach the dashboard without support assistance." Or: "This sprint, we are paying down the database migration debt that has been causing timeouts."

The sprint goal connects the work to the product roadmap. If the team cannot articulate how this sprint advances the quarterly goals, either the sprint is misaligned or the goals need updating.

Part 2: Carry-over check (5 minutes)

What did not get finished last sprint? Is it still a priority? Every carry-over item gets a 30-second review:

Still important, needs to finish. Stays in the sprint. Discuss any blockers.
Context changed. Move it back to the backlog.
Partially done, needs a spike. Scope it down or split it.

Do not spend 15 minutes relitigating a carry-over item. If it needs extensive discussion, park it and handle it after planning.

Part 3: Story review and commitment (30 minutes)

The PM presents stories in priority order. For each story:

PM: 30-second summary of what and why (not reading the ticket aloud)
Team: any clarifying questions
Tech lead or assigned engineer: effort estimate
Team: does this fit in the sprint given current capacity?

When the team's capacity is full, stop. Do not try to squeeze in "one more small thing." The small things are never small, and overcommitment is the top cause of sprint failure.

Part 4: Capacity and risk check (5 minutes)

Quick round-the-room: any planned time off, other commitments, or concerns about the plan? This is where someone mentions they have jury duty on Thursday or a production support rotation that will eat two days.

Adjust the sprint scope based on actual capacity, not theoretical capacity. A 10-day sprint with one engineer on vacation and another on production support is a 7-day sprint. Plan accordingly.

Estimation Without the Story Points Debate

Story points are divisive. Some teams swear by them. Others think they are theater. Mike Cohn at Mountain Goat Software originally popularized story points as relative effort measures, but even he acknowledges they are frequently misused. The honest truth: the specific estimation method matters far less than whether the team estimates consistently.

Here are three approaches that work. Pick one and commit to it for at least a quarter.

T-shirt sizing

S, M, L, XL. No numbers, no pseudo-math. S is half a day. M is 1-2 days. L is 3-5 days. XL is "this needs to be broken down further."

Advantage: Fast. Low cognitive overhead. Prevents the "is this a 3 or a 5?" debate.

Disadvantage: Hard to aggregate. You cannot add up t-shirt sizes to calculate velocity.

Time-based estimates

"This will take 2 days." Direct, clear, and everyone understands what it means.

Advantage: Intuitive. New team members immediately understand the system.

Disadvantage: Confuses calendar time with effort time. A "2-day task" that gets interrupted by production issues takes 4 calendar days. The team needs to agree on whether estimates are effort-days or calendar-days.

Reference-based estimation

Pick 3 completed stories that the whole team remembers: a small one, a medium one, and a large one. Every new story gets compared to those reference stories. "Is this bigger or smaller than the authentication refactor?"

Advantage: Eliminates abstract number debates. Grounded in shared experience.

Disadvantage: Breaks down when team composition changes significantly. New engineers do not have the shared reference points.

Whichever method you choose, the goal is the same: build a shared understanding of how much work the team can do in a sprint, and avoid committing to more than that. The WSJF calculator can help prioritize which items deliver the most value relative to their effort, especially when you are deciding between carry-over items and new work.

Connecting Sprints to Roadmap Goals

Sprint planning in a vacuum is busywork. Every sprint should connect to a quarterly objective or a roadmap theme. If you are choosing between Scrum and Kanban, the connection to roadmap goals should factor into your decision. Scrum's fixed sprint cadence forces regular alignment checkpoints; Kanban requires more discipline to maintain strategic focus.

Here is how to maintain the connection:

Start each quarter with a sprint roadmap. Not a detailed plan for every sprint (plans change). A rough allocation: "Sprints 1-3: onboarding improvements. Sprints 4-5: billing integration. Sprint 6: stability and tech debt." This gives the team a sense of trajectory without locking them into specific tickets 6 weeks out.

Review the connection at retros, not just planning. At the sprint retrospective, ask: "Did this sprint's work advance our quarterly goal?" If the answer is "no" for two sprints in a row, something is wrong. Either the sprint work is being hijacked by reactive requests, or the quarterly goal needs adjustment.

Track sprint-level themes, not just ticket completion. Instead of reporting "we completed 14 of 17 tickets," report "we shipped 3 of the 5 onboarding improvements planned for this quarter." Themes tell the story. Ticket counts do not.

Anti-Patterns: What to Stop Doing

Planning poker theater

If the entire team spends 20 minutes debating whether a story is a 5 or an 8, the estimation method is not serving the team. It is serving the ritual. The difference between a 5 and an 8 rarely changes the sprint plan. If estimates are within a factor of 2x, move on.

"We'll figure it out in sprint"

This phrase appears when a story has unclear requirements, pending design, or unresolved dependencies. It is a trap. Stories that enter a sprint without clear acceptance criteria take 2-3x longer than estimated because the team discovers the ambiguity during implementation and has to stop work to get clarification. If the story is not ready, it is not ready. Send it back to the backlog.

No acceptance criteria

"Build the notifications feature" is not a user story. It is a project name. Without acceptance criteria, the PM and the engineer have different visions of what "done" means. The PM imagines a notification center with filtering and preferences. The engineer implements a basic toast notification. Both are technically "notifications." Neither is wrong. The acceptance criteria are what prevent this mismatch.

Ignoring tech debt

Some teams treat sprint planning as exclusively feature-driven. Tech debt gets no allocation unless it causes a production incident. This approach works for a quarter. Then accumulated debt starts slowing feature delivery by 20-30%, a pattern Martin Fowler describes as the "cruft" tax.

A better pattern: allocate 15-20% of sprint capacity to engineering-chosen improvements. The engineering lead picks the items. The PM does not need to understand every refactoring decision. What the PM does need: a clear explanation of how the tech debt work protects future feature velocity. "If we don't address the database indexing issues now, the report generation feature next quarter will take 3x longer to build" is a compelling case.

The same person talks the entire meeting

If the PM or tech lead is speaking 80% of the time, the meeting is a presentation, not a planning session. Engineers who do not speak during planning feel no ownership over the commitment. Actively pull in quieter team members: "Chen, you worked on the API layer last sprint. Any concerns about the integration story?"

After Planning: Making the Sprint Visible

The sprint plan is only useful if the team can reference it easily. Within 30 minutes of the planning meeting, post the sprint plan in the team's primary channel.

Include:

Sprint goal (one sentence)
Committed stories (numbered list, linked to tickets)
Carry-over items (flagged)
Known risks or dependencies
Who is out of office this sprint

This becomes the reference document for standup. When someone asks "what's left in the sprint?", point them to the list. When a stakeholder asks "are you working on X?", the answer is in the list. The sprint planning guide on IdeaPlan covers the full process end to end, including templates for sprint planning documents.

Sprint Planning Done Right: A PM's Playbook for Efficient Sprints