In this third and concluding part on the blog series on estimation, we focus on Agile estimation. In the first part of the series (*Project estimation challenges), we looked at the challenges frequently faced in estimation. In the second part (*Project estimation techniques), we understood the various estimation techniques.
The reason we look at Agile estimation in detail is that not only does it offer an interesting and a unique approach to estimation, it also plugs one of the most common loopholes in estimation which is to ignore an individual and/or a team’s capacity that is determined by skillset, experience and speed or performance.
In Agile project management, every feature to be implemented is narrowed down and called a story. For e.g., if you are looking at a retail portal, a single ‘Buy product’ page could be the source of hundreds of stories.
Story point approach in agile estimation
A story point is an estimate for a story which is collectively agreed upon by developers, testers, project managers, product owners and others involved. So, one of the first benefits of a story point approach is that it is a collective, collaborative one where the focus is shifted away from an individual.
But, perhaps the most important detail about a story point is that it does not refer to a single estimate measure such as time, effort or complexity. It is an abstracted unit, one which is a relative measure and it signifies the size of the story.
So, you could use T-shirt sizes like XS, S, M, L, XL, XXL, etc. to signify story points. Else, it could be traditional numeric sizes such as 1, 2, 3..
However, the most commonly used method in scrums is Fibonacci sequence. A typical sequence goes 1-1-2-3-5-8-13-21-34-55-89 and so on where every number is the sum of the previous two numbers. Teams use a more convenient 1-2-3-5-8-13-21-40-100 scheme for assigning story points. This is because when you say a number like 34 or 89, it is not only vague but also creates the illusion that you are providing an accurate figure. This is hardly true because there is a lot of rounding off of figures in estimation and the latter sequencing does a good job of representing that. Especially, when it goes towards larger numbers, the numbers are spread out a lot more giving an idea how difficult it is to estimate bigger chunks of work.
Story point is not hours
This cannot be stressed enough! Coming from a traditional project management background, it is difficult for many practitioners to see story point as just a representative number. It is important to remember that this is a relative measure to signify how one story point stands with respect to another. So, the first thing a team does is to choose a baseline story with a story point that everyone agrees. It does not have to be 1. It could be just any story (with a point) that people are comfortable assigning a measure for. From there, every other story is estimated relative to the baseline story.
Velocity
Okay, so we have now come up with all these numbers. What did we really achieve now? How is this going to help us with estimating the time that is required to complete our tasks?
Story point as a stand-alone measure does not give you an idea. But combined with the velocity of a team, it is a useful predictor tool.
Let us take an example. So, for the first sprint (a duration in which stories are implemented and completed), we identify 4 stories with points of 2, 5, 8 and 13. Cumulatively, that is a 28. At the end of the sprint, let’s say, we manage to only finish 26. So, that becomes the velocity of the team. What we are saying is that this team has the capacity of finishing 26 story points in 1 sprint.
Inherently, that measure takes care of the team’s strengths and weaknesses and the integrative dynamics. So, when you plan for the next sprint, you can pick your stories so they add up to 26, because you know that this team can deliver that many.
This creates an unambiguous setting for the entire team.
Tips on using Velocity values
One thing to remember is that velocities should never be compared across teams because of the abstract nature of a story point. Every team has its own way of setting a measure, so a story point of 3 for one team does not mean the same for another.
Secondly, teams usually get better with time as they pick up the technologies or learn how to work with each other. This does not mean, you start assigning a more aggressive story point. Instead, you will notice that the velocity gets better and you start planning your sprints accordingly. This is a significantly different approach from that of effort based estimation.
Ultimately, like any other method, a tool is only as effective as the people practicing it. For people shifting from traditional estimation methods to Agile, there is definitely some unlearning required as the focus is on realistic capacity based estimate, instead of hours based estimate. Also, the spotlight is on the team rather than the individual. With training and experience, you can certainly go Agile (*How to make Agile work for you), the complete way.
Related links you will like:
Comments