Sprint Planning That Won't Converge
You are the Scrum Master facilitating Sprint Planning for a two-week Sprint. The team is seven developers plus a Product Owner, and the timebox is two hours. The Product Backlog holds 31 refined items; the Product Owner has pre-selected the top 14 and says the release depends on all of them. At minute 75 the team has discussed four items, three estimates have been reopened twice, and no Sprint Goal has been drafted. The Product Owner says, "We need all 14 or we slip the release date." A developer replies, "We can't commit to any of it until we know what the API contract from Team B looks like - that's not settled." Team B is in another building and nobody has called them. Two developers start estimating a fifth item. Energy is flat and the clock is the loudest thing in the room.
1. At minute 75, what is your diagnosis, and what is your first intervention?
Read the worked answer
This is not primarily an estimation problem. Three symptoms point elsewhere: no Sprint Goal exists, so there is no criterion for “enough” and every item is equally arguable; the Product Owner pre-selected 14 items, so the team is being asked to validate a plan rather than create one; and a real dependency is being used as an estimation blocker when it is a coordination problem with a five-minute fix. The timebox also had no midpoint checkpoint, which is your design miss.
First intervention: stop the estimating and name the order of operations. “We're 75 minutes in, we've covered four items, and we haven't said what this Sprint is for. I think we're working in the wrong sequence - choosing what before agreeing why. Can we park the item list for 20 minutes and draft a Sprint Goal?”
Reasoning: the Sprint Goal is the convergence device. With it, item selection becomes “what serves the goal?”; without it, everything is negotiable. Second, put the API contract on a visible risk list with an owner and resolve it during planning, not after. You are not choosing the goal or the scope - you are enforcing sequence.
2. How do you structure the remaining 45 minutes, and why that structure?
Read the worked answer
Minutes 0-20, Sprint Goal: ask the Product Owner for the one outcome that matters most this Sprint; three minutes of silent writing on “what would make this Sprint worth doing?”; then 1-2-4-all to converge on a single sentence the team can commit to.
Minutes 20-30, dependency: someone messages or calls Team B now. If an answer arrives, capture it. If not, agree the assumption explicitly with a check-by date - an unresolved dependency is a risk to log, not a reason to leave planning empty-handed.
Minutes 30-40, selection: take items top-down that serve the Goal and stop when the developers say the forecast is honest. Do not estimate all 14. Estimates in service of nothing are the reason the last hour evaporated.
Minutes 40-45, confirm: read back the Goal, the forecast, and the first step for Monday.
Why: this spends the remaining time where the ambiguity actually is. The fifth item's estimate is not the bottleneck. If the forecast that emerges cannot satisfy the release, that is information the Product Owner needs today, not at the Sprint Review.
3. The Product Owner insists all 14 items must ship. How do you facilitate without taking either side?
Read the worked answer
Make the trade-off visible instead of arguing it. Ask the Product Owner to state the consequence: “If we take all 14 and finish eight, what happens to the release?” Then ask the developers for their forecast range and put both answers side by side on a flip chart. You are not adjudicating; you are putting two facts in the same frame.
Then move from positions to interests: “What does the release actually need - all 14 items, or the outcome those items are meant to produce?” Frequently three of the fourteen carry the release and the rest are nice-to-have bundled in. A simple must/should/could split, or a 2x2 of release-critical versus not, will surface that in ten minutes.
If they still disagree, say so plainly: “We have a scope disagreement that we won't settle by estimating harder. I'd rather record it and let the Sprint Review evidence inform it than manufacture agreement now.”
Neutral about content, firm about process: the session must end with a Goal and an honest forecast. Do not force consensus, and do not let neutrality collapse into passivity.