Nine Days, Six People, and a Product Owner Who Wants Everything
Nine working days remain before a release date that cannot move. Your team of six has 14 backlog items: three mandatory for a regulatory filing, four customer-visible fixes, five internal improvements, and two that have never been estimated. Historical velocity is 11 points per ten-day sprint, but the last two sprints delivered 7 and 6 because unplanned support requests consumed roughly 30 percent of capacity. One of your two senior engineers is on leave days 4 through 6. The product owner wants all three regulatory items plus all four customer fixes committed, and has asked you to "stretch" for two internal items. Two of the mandatory items depend on the same single service owned by the engineer who is on leave.
1. Produce a defensible capacity number for the nine days and state exactly what you commit to. Show the arithmetic.
Read the worked answer
Nine days is 0.9 of a nominal sprint. Naive capacity is 11 x 0.9, about 10 points. That number is not defensible because it uses a velocity the team has not achieved in two sprints. The recent delivered figures of 7 and 6 already include the support load, so they are the better predictor; averaging them gives about 6.5 points per ten days, or roughly 5.9 points for nine days.
Adjust further for the three-day absence of a senior engineer. If that person carries roughly a third of team throughput, the loss is about 1 point. A defensible commitment is therefore 5 points of scope, with 6 as a stretch that is stated as such and not promised.
The commitment should be the three regulatory items if they total 5 points or less; if they total more, escalate the gap to the product owner immediately rather than absorbing it silently. Nothing else is committed. The two unestimated items get a time-boxed spike of half a day, not an estimate invented under pressure.
2. Sequence the work and handle the shared-service dependency across the leave period. What gets cut, and by what criterion?
Read the worked answer
Sequence by irreversibility and dependency, not by stakeholder volume. The two mandatory items that both touch the single engineer's service go first, and they go before day 4. If they cannot both finish by then, split the service work so the dependency is removed or stubbed for the second item before the engineer leaves; document what the stub assumes.
Cuts are made by an explicit criterion stated up front: anything not mandatory for the filing and not a customer-visible defect is out. Of the customer fixes, rank by number of affected users times severity, and take them in order until committed capacity is exhausted. The five internal improvements are cut entirely, including the two the product owner wants to stretch for.
The criterion matters more than the specific cuts. Announcing "mandatory work first, then customer impact ranked by users times severity, internal work deferred" lets the product owner reorder within a category without renegotiating the whole plan daily.
3. Name the one early-warning signal you would track, and define the threshold at which you change the plan.
Read the worked answer
Track unplanned support load as a percentage of elapsed capacity, measured daily, because that is the specific mechanism that caused the last two sprints to underdeliver. Velocity is a lagging indicator; by the time it moves, the decision window has closed.
Threshold: if unplanned support exceeds 25 percent of consumed capacity by the end of day 3, cut the lowest-ranked customer fix the same day and notify the product owner in writing. Do not wait for day 5 to confirm a trend. A second trigger is the leave-period handover: if the shared-service work is not demonstrably merged or stubbed by end of day 3, freeze scope and treat the second dependent item as at risk.
The plan should state these triggers before work starts, with the name of the person who acts on them. A trigger nobody owns is a wish. Writing the threshold down also protects the team from being asked later why they did not raise the problem earlier.