Velocity & Capacity Vocabulary | Agile & Scrum Exercises

1 / 5

A new Scrum team member who came from a waterfall background says:

"Why don't we just estimate in hours? I can say this feature will take me 3 days. Why do we need 'story points'? It seems like extra complexity."

Which explanation most accurately describes why Agile practitioners use story points instead of hours?

The core argument for story points over hours rests on three insights:

Problem with hours	How story points address it
False precision — "3 days" implies certainty that doesn't exist	Relative sizing (this story is twice as complex as that one) is more honest about uncertainty
Individual accountability — "you said 3 days, it took 5"	Team estimates; velocity is a team metric — no individual is blamed for variance
Skill-level variance — 3 days for a senior ≠ 3 days for a junior	Complexity is the same regardless of who does the work; the team velocity accounts for the mix

Note: the Scrum Guide (2020) does not mandate story points at all — it only requires that the Development Team selects an estimation approach. Many modern Agile teams use "#NoEstimates" flow-based approaches instead. Option D is incorrect: story points deliberately do not map to calendar time.

2 / 5

The Scrum Master is presenting velocity data to business stakeholders in a quarterly planning meeting. The team's 6-sprint rolling average velocity is 42 story points.

Which statement should the Scrum Master NOT make when presenting this velocity data?

Option D contains a critical misconception: story points are not units of business value. Equating them destroys trust with stakeholders once they realise the statement is misleading:

Incorrect framing	Why it's wrong	Better phrasing
"42 points = 42 value units"	Story points measure relative effort and complexity, not business outcomes or value delivered	"42 points tells us our capacity for work; value delivered depends on what stories we choose"

Other things Scrum Masters should not say when presenting velocity:

Comparing velocity across different teams (team-relative measure)
"We must hit 42 points every sprint" (velocity is a guide, not a floor)
"Higher velocity = better team" (inflating estimates raises velocity artificially)

The safest framing: "Velocity is our historical planning input. It helps us forecast, not judge team performance."

3 / 5

For the upcoming sprint (10 working days), Developer A is on holiday for 3 days and Developer B for 2 days. The remaining 3 developers are fully available. All 5 developers average 6 focus hours per day. The team's normal velocity is 42 story points.

How should the Scrum Master communicate the adjusted capacity and sprint forecast?

Communicating capacity as a percentage of normal is the clearest way to convey the impact to both the team and stakeholders:

Calculation step	Values
Normal capacity (5 devs × 10 days)	50 developer-days
Lost capacity (3 + 2 holiday days)	5 developer-days
Available capacity	45 developer-days = 90% of normal
Adjusted forecast	42 × 0.90 ≈ 38 points (some teams round down for safety margin)

Option B (raw focus hours) is too technical for stakeholder communication and doesn't map to story points. Option C is incorrect — velocity reflects past completions and does not automatically adjust for future absences. Option D is a non-starter in Agile; partial-capacity sprints are normal and expected.

4 / 5

A product manager sends the Scrum Master a message before sprint planning:

"The next sprint is critical for our Q3 roadmap. I need the team to commit to 60 story points instead of your usual 42. This is not negotiable."

Which response from the Scrum Master is most appropriate?

Artificially inflating sprint commitments to satisfy external pressure is one of the most damaging anti-patterns in Scrum:

What happens when teams over-commit	Impact
Stories rushed to hit the number	Acceptance criteria not fully met; bugs increase next sprint
Tests skipped or cut short	Technical debt accumulates; future velocity drops
Velocity data becomes inflated	Future forecasts are unreliable; planning trust erodes
Team morale drops	Sustainable pace principle is violated; burnout risk rises

The Scrum Master's role includes protecting the team's process from external pressure. The correct response is to explain — with data — why the request undermines the very reliability the product manager depends on, and to offer a transparent conversation about priorities instead of a velocity number change.

5 / 5

During sprint planning, the team debates which wording to use when communicating the sprint plan to stakeholders. One developer says: "We always say we're 'committing' to these points." The Scrum Master replies: "Modern Scrum actually prefers different language."

Which wording does modern Scrum encourage, and why?

The shift from "commitment" to "forecast" in the 2020 Scrum Guide update was deliberate:

Term	Implication	Problem
Commit	A binding promise — failure to deliver = breach	Encourages scope protection over collaboration; punishes honest re-planning
Forecast	A data-based prediction — subject to revision as learning occurs	None — aligns with empirical process control (inspect and adapt)

Forecast language aligns with Scrum's empirical foundation: the team plans based on what they know now and adapts as they learn more. Saying "we forecast 38 points" opens a healthy conversation about risk and uncertainty, whereas "we commit to 38 points" creates contractual pressure that incentivises cutting corners to avoid the appearance of failure.