Practice the vocabulary of estimating how much work a team can realistically commit to.
0 / 5 completed
1 / 5
At standup, a dev mentions estimating how much actual work the team can realistically commit to next sprint based on each person's available hours, rather than just assuming everyone is fully available for the entire sprint. What is this practice called?
Team capacity planning estimates how much actual work the team can realistically commit to in an upcoming sprint, based on each person's genuinely available hours, accounting for a planned vacation, a recurring meeting load, or another team commitment. Assuming everyone is fully available for the entire sprint ignores these very common, entirely normal reductions in real available time. This capacity-based estimate is what keeps a sprint commitment realistic rather than optimistic and likely to slip.
2 / 5
During a design review, the team wants to factor in a known, recurring commitment, like a fixed amount of time spent on production support each sprint, when calculating how much new feature work the team can actually take on. Which capability supports this?
Accounting for recurring overhead, like a fixed amount of time regularly spent on production support, when calculating available capacity gives a more realistic picture of how much genuinely new feature work the team can actually take on in a given sprint. Calculating capacity as if the team's entire time were free for new work ignores an overhead that predictably recurs sprint after sprint. This overhead accounting keeps the resulting capacity estimate grounded in the team's actual, observed working pattern rather than an idealized one.
3 / 5
In a code review — or rather, in a sprint retro — a team notices they consistently overcommit relative to what they actually complete, and starts tracking a rolling average of completed capacity from recent sprints to calibrate future planning. What does this represent?
Using historical velocity data, a rolling average of what the team has actually completed in recent sprints, calibrates a future capacity estimate against real, observed performance rather than an optimistic guess made fresh each time. Planning from scratch with no reference to recent completion history risks repeating the same overcommitment pattern sprint after sprint. This historical calibration is a standard, practical way to make a capacity estimate progressively more accurate over time.
4 / 5
An incident report — more precisely, a retrospective — shows the team missed its sprint commitment for the third sprint in a row because capacity planning never accounted for a recurring, fixed on-call support burden each sprint. What practice would prevent this?
Explicitly subtracting a known, recurring overhead like on-call support from the team's calculated available capacity before committing to new work directly addresses the repeated overcommitment this team experienced for three sprints running. Calculating capacity as though the entire time were free for new work ignores a real, predictable drain on that time. This explicit overhead accounting is exactly the missing step that would have made the team's sprint commitments realistic rather than consistently missed.
5 / 5
During a PR review — or rather, during sprint planning — a teammate asks why the team calculates capacity carefully instead of just committing to the same number of story points every single sprint regardless of who's actually available. What is the reasoning?
A team's actually available hours genuinely vary from sprint to sprint due to a planned vacation, a recurring support burden, or another shifting commitment, so committing to a fixed number regardless of that variation produces an unrealistic target more often than not. A careful capacity calculation, refined over time with historical velocity data, produces a far more realistic commitment. The tradeoff is the ongoing discipline of actually tracking available hours and recurring overhead accurately each sprint rather than just picking a convenient round number.