The Sprint That Promised Everything
A four-person team is building a booking system for a school's equipment loans. The client wants it live before the end of term, eight weeks away. The team's velocity over the last three sprints has been 21, 24, and 22 story points per two-week sprint. The backlog has 190 points of "must have" items, 70 points of "should have", and 40 points of "could have". The team has also committed to mentoring two work-experience students for one day each week, and one developer will be on leave for one sprint. The project manager's plan is to "work overtime in the last two sprints to close the gap" and to defer all testing to a final two-week phase. A parent volunteer has offered to help with data entry, which the manager counts as freeing up team capacity.
1. Calculate whether the plan is feasible and identify the planning errors.
Read the worked answer
Capacity. Eight weeks is four sprints. Historical velocity averages (21 + 24 + 22) / 3 ≈ 22.3 points per sprint, so four sprints yield roughly 89 points.
Adjustments reduce this further. One developer is on leave for one sprint: with four people, losing one for a sprint removes about a quarter of that sprint's capacity, roughly 5–6 points. Mentoring two students one day a week removes roughly 20% of capacity across all four sprints, another ~18 points. Realistic capacity is therefore closer to 65–70 points.
Demand. Must-have items alone total 190 points, nearly three times realistic capacity. Even the full backlog (300 points) is irrelevant; the must-have set alone is infeasible.
Planning errors.
- Ignoring measured velocity. The plan assumes the team can deliver 190 points in four sprints when it has never exceeded 24 in one.
- Counting the volunteer as team capacity. The volunteer does data entry, not development; this does not convert into story points and may even add coordination overhead.
- Overtime as a plan. Sustained overtime typically reduces throughput through fatigue and defects; it is a hope, not a schedule.
- Deferring all testing. Testing deferred to the end means defects are found when there is no time to fix them, and it makes the final sprint's estimate fictional.
- Treating all must-haves as fixed. No negotiation with the client has occurred; the scope was accepted as given.
The honest conclusion: the plan cannot succeed as written, and the gap is not closable by effort alone.
2. Recommend how the project manager should restructure scope, schedule, and quality, and explain the trade-offs.
Read the worked answer
Negotiate scope with the client first. The must-have list is 190 points against ~68 of capacity. The manager should present the velocity data and ask the client to identify the smallest set of features that delivers real value. A plausible cut: booking creation and cancellation, with notifications and reporting deferred. That might reduce the must-have set to roughly 60–70 points, which fits.
Restructure the schedule. Move to a walking-skeleton approach: deliver a thin end-to-end slice (create a booking, see it in a list) in the first two sprints, then thicken it. This gives the client something usable early and makes progress visible, which supports honest conversation about what will not fit.
Protect quality continuously. Testing is not a phase; each story should carry its own acceptance tests. Deferring testing to the end is precisely how teams end up shipping untested software on the last day. If the team cannot test a story within the sprint, the story is too big.
Handle the mentoring honestly. The mentoring commitment is real and valuable; it should be subtracted from capacity in the plan rather than absorbed by overtime. Same for leave.
Trade-offs. Cutting scope means the client gets less than they hoped, but gets it working and on time. Fixing the date and the scope simultaneously would force quality down, and a booking system that loses bookings is worse than one without notifications. The manager should document the decision and the deferred items so they can be scheduled next term.
The judgement is that scope, schedule, and quality cannot all be fixed; the manager's job is to choose which one moves and to make that choice explicit with the client.