User Stories and Estimation Flashcards
6 cards from real Agile Project Management practice questions. Tap to flip, then mark Knew It or Still Learning — missed cards come back until you master them.
Read the first 6 User Stories and Estimation flashcards as text
Which of the following best describes the primary purpose of using story points for estimation?
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.
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?
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.
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?
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.
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?
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.
A user story is considered too large to be completed within a single sprint. Which of the following is the best course of action?
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.
According to the INVEST mnemonic, a good user story should be 'Negotiable'. What does this characteristic imply?
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.