Sprint Planning: Commitment, Not Estimation

Role reversal: the keyboard is with the team now

In grooming the direction was from the PO to the team. In planning it reverses, and that reversal defines the whole meeting.

• The team explains the plan: "For this story we will expose this endpoint, add a column to this table, and run the migrations in this order." This is the read-back.
• The PO confirms: "Yes, what you just described meets the need."

The value of the read-back: if the PO's mental solution differs from the team's, the gap surfaces here. If it does not, it surfaces at the end of the sprint, during the demo.

Estimation: it should be fast, because the hard part is done

If the technical preparation happened, planning poker takes minutes. Everyone already knows the complexity, the "how" discussion is over, and the unknowns were either resolved earlier or the item was rejected.

If estimation drags, it is not an estimation problem. It is one of three things: the item is not understood, the item is too big, or only one person on the team knows that area. The fix for all three lies outside the planning session, not inside it.

Capacity: the step most teams skip

"We are six people, there are ten days, that is sixty person-days." That calculation is wrong, and it is wrong the same way every sprint. The real one:

Raw capacity     6 people × 10 days           = 60 person-days
Time off         -1 person 3 days, -1 for 2   =  -5
Meeting overhead ~10% (daily, review, retro)  =  -6
Production duty  1 person on call × 10 days   = -10
-------------------------------------------------------
Plannable                                     =  39 person-days
Unplanned-work buffer 15%                     =  -6
=======================================================
Committable                                   =  33 person-days

Sixty became thirty-three. A team planning against sixty overspills every time and calls it "we estimated badly". It is not an estimation problem, it is arithmetic.

Base the buffer on measurement: compute the actual percentage of unplanned work over the last three sprints and set the buffer to that. A guessed buffer is either too small or gets treated by the team as free time.

The pull system: do not pre-assign

Assigning an owner to every item at the start of the sprint is a common habit, and it cuts both ways.

• Everyone takes only their first item.
• The rest sits unassigned in the sprint backlog — but sorted by priority.
• When someone finishes, they update the item and pull the next highest priority one.

The way between the two is to make pair programming part of planning: mark here which items will be paired. A junior pulling a hard item knows who to pair with; a senior pulling a dull one pairs in order to teach. Reserving 20–40% of total sprint effort for pairing slows you down in the short term and raises throughput from about the third month.

Pull QA into day one

QA drowning in the last two days of a sprint is not a capacity problem, it is a flow problem. Set the target in planning: the first testable item should reach QA by the end of day one.

Day one is not idle time for QA: test data sets, environments and test scenarios are prepared then. In teams that never discuss this in planning, QA waits through the first half of the sprint and cannot keep up in the second.

The commitment

A commitment is not a negotiation. The team looks at its capacity and pulls the work it knows it can deliver. Because the technical risks were resolved earlier, this is stronger than an estimate.

The answer to the PO's "can we fit one more?" is this: "We can, and here is what we are taking out in exchange." Any planning session where added scope has no price is a rehearsal for an argument mid-sprint.

Checklist

Conclusion

Sprint planning should be boring. If big debates and surprises show up here, the problem is not in planning but in everything before it. A good session is a short confirmation ritual: "We are ready, let us start."