CST Agile Estimation Techniques & User Stories 1 — Questions and Answers
Question 1: What is the primary advantage of using story points rather than hours for estimating in Scrum?
- They satisfy stakeholder reporting requirements more efficiently
- They enable relative estimation that is team-specific and avoids time-pressure anchoring (Correct answer)
- They align with PMI estimation standards for project management
- They allow the Product Owner to assign work to individual developers
Correct answer: They enable relative estimation that is team-specific and avoids time-pressure anchoring
Story points enable relative estimation that remains internally consistent within a team while avoiding the psychological pressure and anchoring that comes with hour-based estimates.
Question 2: Why does Planning Poker typically use a Fibonacci-like sequence (1, 2, 3, 5, 8, 13) rather than a linear scale?
- The Scrum Guide mandates this sequence for all estimation activities
- The sequence ensures no single story can exceed one Sprint in duration
- The increasing gaps reflect growing uncertainty in larger estimates (Correct answer)
- It was chosen because all Agile coaches agreed it produces the most accurate results
Correct answer: The increasing gaps reflect growing uncertainty in larger estimates
The exponentially increasing gaps in the Fibonacci sequence reflect the reality that larger items carry more uncertainty, making fine-grained distinctions (e.g., 11 vs. 12 points) meaningless.
Question 3: During Planning Poker, two team members consistently submit very different estimates. What is the BEST action for the Scrum Master to take?
- Average the two estimates and record the result to keep the session moving
- Ask the higher estimator to lower their card to avoid inflating velocity
- Facilitate a discussion so both team members share their reasoning (Correct answer)
- Escalate to the Product Owner to cast the deciding vote
Correct answer: Facilitate a discussion so both team members share their reasoning
Divergent estimates signal different assumptions or hidden complexity; facilitating a discussion surfaces these differences, leading to shared understanding and better estimates.
Question 4: Which of the following best describes a well-formed User Story?
- A detailed specification document reviewed and approved by the Product Owner
- A short, simple description of a feature from the perspective of the person who desires it (Correct answer)
- A technical task assigned to a specific developer in the Sprint Backlog
- A Scrum artifact that replaces the traditional requirements document
Correct answer: A short, simple description of a feature from the perspective of the person who desires it
A User Story is a short, simple description written from the end user's perspective, capturing what they want and why, to facilitate conversation and collaborative refinement.
Question 5: What does the 'I' in the INVEST acronym for well-formed User Stories stand for?
- Integrated
- Important
- Independent (Correct answer)
- Incremental
Correct answer: Independent
Independent in INVEST means user stories should be self-contained and avoid dependencies on other stories, enabling flexible scheduling and prioritization.
Question 6: What is the recommended action when a User Story is too large to complete within a single Sprint?
- Extend the Sprint length to accommodate the larger story
- Assign the story to multiple team members working in parallel without splitting it
- Split it into smaller stories that each individually deliver value (Correct answer)
- Convert it to an Epic and defer it to a future Program Increment
Correct answer: Split it into smaller stories that each individually deliver value
Stories too large for a Sprint should be split into smaller, independently valuable stories so each can be completed and potentially released within a single Sprint.
Question 7: A team consistently over-commits in Sprint Planning and fails to complete all selected items. What is the most likely root cause?
- The Product Owner is violating Scrum by adding items to the Sprint mid-cycle
- The team's velocity calculation is not accounting for overhead, meetings, and interruptions (Correct answer)
- The Scrum Guide recommends teams take on slightly more work than they can complete
- Story points are an inherently inaccurate estimation technique that should be replaced
Correct answer: The team's velocity calculation is not accounting for overhead, meetings, and interruptions
Teams often over-commit because their velocity calculation doesn't account for non-development activities like ceremonies, support requests, and unexpected interruptions that reduce actual capacity.
What is the primary advantage of using story points rather than hours for estimating in Scrum?