Team Hydra's Draft Plan: 78 Points, 60 of Capacity, Two Fingers
Team Hydra (five engineers, one PO) is in the team breakout on day one of PI Planning for PI 6. Its draft plan totals 78 story points against a demonstrated capacity of 60. The plan includes 20 points of 'tech debt cleanup' that nobody has broken down. Iteration 1 is loaded to 32 points, Iteration 2 to 28, Iteration 3 to 18, and the IP iteration to 5. Halfway through the breakout Hydra realises two of its top features depend on a service owned by Team Vulcan, which sits in a different ART, in a different timezone, and is not in the room. The dependency was not known when the features were prioritized. At the confidence vote Hydra holds up two fingers; the tech lead says, 'We'll stretch, it'll be fine - don't make us look bad in front of the business owners.' The business owners have assigned 8 business value points across Hydra's four PI objectives.
1. 78 points against 60 of capacity, with 20 unestimated points and an uneven load. What does the Scrum Master do before the management review?
Read the worked answer
First, name the arithmetic plainly: 78 against 60 is not a stretch, it is a plan that has already failed. And 20 unestimated points are not a plan at all - they are a placeholder, and placeholders are where overcommitment hides.
Moves, in order:
- Break down or size the tech-debt work in the breakout. It will either shrink, grow, or reveal itself as several unrelated items - all three outcomes are useful.
- Re-plan to capacity. Load each iteration to roughly 60/4 and keep the IP iteration for innovation and the PI's deferred hardening, not for overflow.
- Read the shape. 32/28/18/5 is a red flag: the back half going quiet usually means the work is not sliced finely enough to be visible, or the early iterations are padded with work that will slide.
- Force the trade-off into the open with the PO. Something has to move or drop. The SM does not shave points silently to make the number fit, and does not let the PO discover the gap in iteration three.
The SM's product here is not a tidier plan; it is a plan the team actually believes, plus a visible record of what was consciously left out.
2. Two fingers, and 'we'll stretch'. How do you handle the confidence vote and the cross-ART dependency?
Read the worked answer
The vote. A two is information, not defiance. In a fist-of-five, three or more is the threshold to proceed; below that the objective of the remaining breakout time is to find what would move the team to a four. Facilitate that question directly: 'What specifically would have to change for this to be a four?' The answers are almost always visible already - the unestimated 20 points, the Vulcan dependency, or a skill gap.
Refuse the social pressure, gently and out loud. A confidence vote exists precisely so that bad news is cheap now rather than expensive in iteration three. 'Don't make us look bad' is a psychological-safety problem that the SM names, because if the vote is not honest it has no value at all.
The dependency. Vulcan is not in the room and is in a different ART, so this is not a hallway conversation.
- Put it on the program board with the specific deliverable, the date it is needed, and the red string.
- ROAM it in the planning: Resolved (we have a confirmed commitment and date), Owned (a named person here will chase it), Accepted (we plan around it), Mitigated (we have a fallback). 'Owned' requires a name, not a team.
- Contact Vulcan's Scrum Master or their RTE the same day. Cross-ART dependencies are exactly what the RTE network and ART Sync exist for; the SM's job is to route it fast, not to wait for the next event.
A plan with a two and an unowned cross-ART dependency is not ready for the management review - and saying so is the SM's contribution.
3. Should the Scrum Master push to reduce Hydra's four PI objectives, or reduce the business value assigned to them?
Read the worked answer
Neither directly - both are negotiated between the team, the PO and the business owners, and the SM does not own the objectives. What the SM owns is whether the conversation is honest and whether the objectives are worth committing to.
What to check:
- Are they outcomes? Four objectives with 8 points total suggests thinly spread value. Objectives should describe a demonstrable business or customer outcome, not 'complete features X and Y'.
- Is the value negotiated or assigned? Business owners propose; the team and PO should be able to challenge. If the team says a 3-point objective is actually worth 1, that conversation belongs in planning, not in the I&A retrospective.
- Is the stretch labelled? Stretch objectives are legitimate and should be marked as such, so that missing them is not a failure and the predictability measure stays meaningful.
- Is scope genuinely reduced? If Vulcan dependency or capacity forces features out, the planned business value should come down with them. Leaving value at 8 while cutting scope inflates the apparent achievement later.
So: do not campaign for fewer objectives. Make the SM's standard case - that a committed objective the team believes in is worth more than an aspirational list - and let the PO and business owners make the call with the capacity numbers and the dependency on the table.