Estimation is a critical part of any project process, regardless of the methodology used. In an Agile project, where the requirements keep evolving, estimation assumes even greater importance. It serves as a baseline for creating project schedules, planning upcoming work and release dates, and getting all the team members on the same page at the very outset. Without a properly planned estimation process, it’s very easy for any project to get out of hand and overshoot on time, budget and scope.
Story points are the most popular method of estimating an Agile project. In this blog, you will learn what story points are, how they are estimated and how they compare to the traditional methods of estimating using hours.
Quite often, we find ourselves in a situation where we need to carry out a rough and ready calculation of something. Say you’ve woken up late and need to get to work on time as you have an important meeting in the morning. You could take route A, which is longer but has less traffic, or you could choose route B, where the traffic is much more but it is several miles shorter. Or there’s route C, the middle path. Factor in the day of the week, time of day, and the weather—and you have any number of variable parameters that will contribute to whether you make it to that meeting on time or not!
Agile planning is a bit like this. When you're planning is off the mark, it can lead to stretched deadlines, over-expenditure, scope creep, or the need for team members needing to move to another project because this one took too long. Improper planning can even, in extreme situations, lead to the complete breakdown of the project itself.
So, when we have so many variables to think of, which is the best method of planning? Story points, a method of relative estimation, have been proven to work well as an estimation method in Agile projects.
A story point can be defined as an abstract measure of the effort involved in fully implementing a piece of work. This could be a backlog item, a feature, or a user story. It is important to note here that there are no half measures; a story (or feature or backlog item) is said to be completed only when it is entirely done, according to the Definition of Done set by the team.
Traditional projects would usually base estimates on hours, days or weeks, as requirements were fixed, and schedules and budgets were rigid. There were usually no variable parameters to be kept in mind as till the end there was no change expected.
Agile, however, is all about adapting to change, and it could be expected that requirements, resources and even the end goals could change over the progress of the project. Calculation in hours will simply not work for a project which could undergo considerable transformation along the way.
Teams allocate story points to work items factoring in the amount of work involved, the complexity of the work and the risk involved in implementing it. These are some of the reasons why story points work better for agile projects than hours:
Story point estimation considers three factors:
There are several ways of estimating story points, and the two most common ways are by using the Fibonacci sequence, and by using the planning Poker method. Let’s understand each of these in detail.
Fibonacci sequence numbers offer a simple scale for estimating agile story points. As we have learnt in Math, in this sequence, each number is the sum of the previous two and the series looks like this: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89… etc.
Using this series, it becomes far easier to calculate the relative measure of two tasks. As an example, let’s assume you are holding two weights: a one-pound weight in one hand and a two-pound weight in the other. Without any problem at all, you will be able to judge the one which is heavier. However, let’s suppose you are holding a 10-pound weight in one hand and a 10.5-pound weight in the other. It’s now not as easy to judge which is heavier, is it?
When using a Fibonacci sequence, the numbers jump along the series, and we can still perceive the difference when each number is much larger than the previous one.
The team first identifies the smallest story and assigns 1 story point to it. This becomes the baseline for reference. All other stories are compared to this one, and story points are assigned to the remaining stories in line with the numbers in the Fibonacci sequence.
Along the way, a method called triangulation is used to check whether the story points assigned are roughly accurate. If an item is an 8, for example, check the items that are on either side - marked 5 and 13 - and see whether it really deserves to be labelled an 8.
A gamified exercise called Planning Poker, carried out during the sprint planning meeting, helps team members to arrive at an understanding of the correct story point approximation for each item.
Here’s how Planning Poker works:
The Last Word
As we have seen, using story points helps to keep the planning process transparent, faster and more honest. However, since it’s such an abstract measure, a story point can be a difficult concept to grasp, especially for the newbie.
During the first sprint, it can be expected that the estimation will not only take time but will also be less accurate; and this is only natural. As agile team members gain experience, they will be able to arrive at more accurate story point estimates. By laying more emphasis on the effort involved rather than the time, the team will be better organized and prepared to complete tasks on time and to the highest quality.
Over time, using story points will result in better collaboration and improved efficiency, which ultimately results in a better product. In the end, this is what Agile is all about!
Your email address will not be published. Required fields are marked *
85 percent of respondents say Scrum continues to... Read More