5 Reasons to Estimate Agile Development with Story Points

I have a few posts on agile estimation. Here's one on why estimating is important, another one on how to do one-week agile planning sprint, and a more detailed one on how to conduct an agile sizing meeting. Does agile poker help? Yes. If that's how the team wants to self organize and come to consensus on an estimate.

I am often confronted with the question on whether to estimate in hours or in story points. The debate over whether to estimate at all and what measure to use is extensive, so I'm going to share some points why I always endorse software and application development teams to use story points to estimate.

Why using Story Points Drives More Reliable Estimates and Consistent Velocity

  1. Estimating with points is easier for developers and aligns with how they interpret requirements and develop solutions. When reading the story and acceptance criteria, developers typically ask themselves a few questions. Do I understand the requirement? Do I believe it's important and understand why it was prioritized? Most importantly, do I have an idea of how to implement it and is the solution similar to other things that I have already implemented? Developers will assign higher story points for vague requirements or for unknown implementations accounting for both the effort required to solution and the potential complexities in the implementation.

  2. Estimating high story points drives more questions and dialogue. Since story points expresses both effort and complexity, a higher estimate will often draw questions and dialogue on how to simplify the requirement or the implementation. Ask the developer why the estimate is high. If it was estimated in hours, you're more likely to get a list of implementation and refactoring steps that is hard for product owners and technical leaders without a deep understanding of the application architecture and code to interpret. If the estimate is in story points, more questions can be asked as to whether the developer is interpreting the requirement correctly, what makes the implementation complex, and whether there are alternative solutions that are easier to implement.

  3. It's easier to normalize story points across developers of different skills.  An advanced developer may estimate a story is only a couple of hours to implement while an inexperienced one is more likely to estimate greater effort to account for the learning curve and making mistakes. Now let's say teams are using the Fibonacci series for standardizing sizes and craft some definition of what three vs. five vs thirteen story points mean. Maybe a story size of three means that the implementation requires a single change to the user interface without any changes to the business logic or data model. When you define it that way, you're more likely to get both the advanced and inexperienced developer to estimate the same or similar number of points for the story.

    So what accounts for the inexperienced developer's added effort to complete this story? You'll see it in the team's commitment and the stories assigned to the novice developer versus the advanced one. The novice developer is more likely to commit to fewer stories (and fewer total points) than the advanced developer. As the novice developer gains more experience and knowledge of the application architecture, you're likely to see a higher commitment.

    Here is a great post by Mike Cohn that elaborates on why estimating with story points helps teams with different skill and experience levels. 

  4. For those looking to capture development costs, measuring actual hours provides an easier to implement and more accurate solution. Most agile tools allow developers to log their work in hours so if required, at the end of a sprint you can get a full cost accounting. See time tracking in JiraRally and VersionOne. What's more interesting is that you'll have better data correlating estimated story points to actual hours and asking questions on the variance. For example, a high point story with low effort implies a complex story or an overestimated one. 

  5. Estimating and committing to story points more often leads to a consistent velocity. Development teams will not only consider the total points of prioritized stories but the mix of them. So for example, they may commit to three 5-point stories and one 13-point story for a total of 28 points but may not commit to six 3-point stories and two 5-point ones even though they add up to the same 28 points. When committing, the developers take many other variables into context beyond size, complexity, and effort hours and are more likely to commit to a blending of story sizes that fit the skills and expertise of the team. The added context in the decision making often leads to a more consistent velocity.
Want to read more? Here are some more points on using story points. Also, remember that estimation is hard and what leaders should focus on is on getting the culture, practice, and requirements right that enables teams to deliver well designed and performing applications. 

No comments:

Post a Comment