Agile User Stories and Estimation Questions and Answers 1 — Questions and Answers
Question 1: Which of the following best describes the primary purpose of using story points for estimation?
- To provide a precise measure of the development time in hours for a user story.
- To create a relative measure of the effort, complexity, and uncertainty of a user story. (Correct answer)
- To track the business value delivered to the customer at the end of each sprint.
- To measure the individual performance of each developer on the team.
Correct answer: To create a relative measure of the effort, complexity, and uncertainty of a user story.
Story points are an abstract, relative unit of measure used in Agile. They are not tied to specific hours but instead encapsulate the overall effort required for a task, including complexity, risks, and the volume of work. This relative sizing helps teams make forecasts and plan sprints more effectively without the false precision of time-based estimates.
Question 2: A team is using the Planning Poker technique to estimate a user story. The initial estimates from the developers are 3, 5, 5, 8, and 13. What is the most valuable next step for the team to take?
- Take the average of the numbers to determine the final estimate.
- Ask the two developers who gave the highest and lowest estimates (3 and 13) to discuss their reasoning. (Correct answer)
- Remove the highest and lowest estimates and use the most common number, 5.
- Ask the Product Owner to break the tie and choose the correct estimate.
Correct answer: Ask the two developers who gave the highest and lowest estimates (3 and 13) to discuss their reasoning.
The primary goal of Planning Poker is not just to produce a number, but to foster conversation and create a shared understanding. A wide divergence in estimates, like a 3 and a 13, indicates that team members have different assumptions or information about the work. The discussion between the high and low estimators is crucial for uncovering these differences and clarifying the story's scope.
Question 3: A team completes 20, 25, and 23 story points in its first three sprints. What is the team's calculated average velocity, and how should it primarily be used?
- 22.67; to commit to delivering exactly 23 points in the next sprint.
- 22.67; to compare the team's performance with other teams in the organization.
- 22.67; to help with forecasting how much work the team can likely complete in future sprints. (Correct answer)
- 25; to use the highest number for planning to push the team to improve.
Correct answer: 22.67; to help with forecasting how much work the team can likely complete in future sprints.
The average velocity is (20+25+23)/3 = 22.67. Its primary purpose is to serve as a data-driven guide for long-term planning and forecasting. It helps predict how many sprints might be needed to complete a backlog, but it is not a performance metric for comparison between teams or a rigid commitment for a single sprint.
Question 4: A Product Owner presents a user story that reads, "As a shopper, I want a search bar." The development team states that the story isn't ready to be worked on because it lacks the 'Confirmation' aspect of the 3 Cs. What is missing?
- A detailed technical design document.
- The estimated number of story points.
- A discussion about the story's business value.
- Clear, testable acceptance criteria. (Correct answer)
Correct answer: Clear, testable acceptance criteria.
The '3 Cs' of a user story are Card, Conversation, and Confirmation. The Confirmation refers to the acceptance criteria, which are the conditions that must be met for the story to be considered complete. Without acceptance criteria, the team does not have a clear, shared understanding of what 'done' looks like for the search bar.
Question 5: A user story is considered too large to be completed within a single sprint. Which of the following is the best course of action?
- Lengthen the sprint duration to accommodate the large story.
- Work with the Product Owner to split the story into smaller, independently valuable stories. (Correct answer)
- Keep the story as is and plan to have it span across two sprints.
- Assign the entire story to the most senior developer on the team.
Correct answer: Work with the Product Owner to split the story into smaller, independently valuable stories.
Large user stories (epics) should be broken down into smaller stories that each deliver a valuable increment and can be completed within a sprint. This allows for faster feedback, reduces risk, and provides more flexibility in prioritization. Simply extending the sprint or carrying work over violates Agile principles.
Question 6: According to the INVEST mnemonic, a good user story should be 'Negotiable'. What does this characteristic imply?
- The story's priority can be changed at any time by the stakeholders.
- The story is a placeholder for a conversation about the solution, not a rigid contract. (Correct answer)
- The number of story points assigned to the story can be bargained down by the Product Owner.
- The development team can choose not to work on the story if they disagree with it.
Correct answer: The story is a placeholder for a conversation about the solution, not a rigid contract.
The 'N' in INVEST stands for Negotiable, meaning the user story is not a detailed specification. It's an invitation for the development team and Product Owner to collaborate and discuss the best way to implement the solution. The details are meant to be fleshed out in conversation, allowing for flexibility and leveraging the team's expertise.
Which of the following best describes the primary purpose of using story points for estimation?