Agile Planning and Estimation Flashcards

An agile team has completed three two-week sprints. The story points completed for each sprint were 18, 24, and 21 respectively. A crucial user story in the current sprint was only partially completed. The total estimated points for the current sprint's completed stories is 20, and the partially completed story is estimated at 8 points. What is the team's velocity that should be used for planning the next sprint?

Answer: 21 points

Velocity is calculated as the average number of story points completed in previous sprints. Only fully completed stories are counted. Therefore, the points for the partially completed story (8 points) are not included. The velocity is the average of the last three completed sprints: (18 + 24 + 21) / 3 = 21 points. This historical average is the most reliable predictor of the team's capacity for the next sprint.

During an iteration planning meeting, the team is discussing a large, complex feature. They are struggling to assign a single story point value due to the high degree of uncertainty and multiple components involved. What is the BEST immediate course of action?

Answer: Break the feature down into smaller, more manageable user stories that can be estimated individually.

Large, complex features, often called Epics, are difficult to estimate accurately. The best agile practice is to disaggregate or split the epic into smaller, independent user stories. These smaller stories are easier for the team to understand, discuss, and assign a more reliable relative estimate, reducing uncertainty and improving the accuracy of the plan.

Which of the following BEST describes the primary purpose of Agile Release Planning?

Answer: To provide a high-level forecast that aligns the team and stakeholders on the product direction and sequence of releases.

Agile Release Planning is not about creating a rigid, unchangeable plan. Instead, it serves as a strategic, high-level forecast that maps out the intended sequence of releases and the features they will contain. It aligns the product vision with the team's capacity, providing direction and managing stakeholder expectations while remaining flexible to adapt to change.

A development team is using Planning Poker® for estimation. During a round, the estimates for a user story are 3, 5, 5, 8, and 13. What should the team do next?

Answer: Have the team members who voted 3 and 13 explain the reasoning behind their estimates.

The goal of Planning Poker® is to reach a consensus through discussion. A wide variance in votes, like in this scenario, indicates different understandings of the user story's complexity or scope. The next step is for the individuals with the highest and lowest estimates to share their perspectives. This discussion uncovers assumptions, clarifies requirements, and allows the team to converge on a more accurate, shared understanding before re-voting.

When comparing Story Points to 'Ideal Days' as estimation units, what is a primary advantage of using Story Points?

Answer: They are a relative measure of effort, complexity, and uncertainty, which does not decay over time as team skills improve.

Story points are a relative, abstract measure. A 5-point story is roughly half the effort of a 10-point story. This relative sizing is not tied to specific hours or days and remains consistent even if the team becomes more productive. An 'Ideal Day' estimate, being tied to time, can decay; what takes one ideal day for a junior developer might take less for a senior developer, and the whole team's 'ideal day' capacity can change as they get faster, making it a less stable unit of measure over the long term.

The main inputs for an Iteration (Sprint) Planning meeting typically include the team's historical velocity and which other key artifact?

Answer: The prioritized Product Backlog.

Iteration Planning begins with the Product Owner presenting the highest priority items from the Product Backlog. The development team then discusses these items and pulls work into the sprint based on their capacity, which is understood from their historical velocity. Therefore, the prioritized Product Backlog is the essential input that defines the 'what' to be built in the upcoming iteration.