Agile estimation is an important part of the planning process in an Agile project. Well, thought out estimates help product owners to manage time schedules better, maximizing efficiency and product value. Agile estimation is a collective effort, and the entire team takes part in the process.
In this article, we will talk about estimation using story points. You will learn how it’s done, what are the challenges you might face with time estimates and with story points, and why story points are considered to work well as compared to estimates using man hours.
Let us start by understanding the basics: what is a story point?
In traditional projects, time estimates are usually calculated in terms of days, weeks, or months. If you have worked on an Agile project, you are more than likely to be familiar with the term ‘Story Points’. Agile and Scrum teams prefer to use story points as a measure of calculating the effort (not the time itself, as such) involved to fully implement a particular piece of work.
Mike Cohn, Agile expert and founding member of the Agile Alliance and Scrum Alliance, defines story points as ‘estimates of effort as influenced by the amount of work, complexity, risk and uncertainty’.
Using story points, we can measure the effort required to fully complete a Product Backlog item—and based on this, the time schedules for a sprint or for a product release can be fully worked out.
Story points are assigned based on the complexity of the work involved, the amount of work needed, and the risk involved in implementing that feature or user story. A team that has worked together earlier will be in a better position to judge how much they can achieve in a particular duration, but even new teams will get the hang of the estimation process pretty quickly.
When calculating the story point, the estimate is based on three things:
When estimating the story points, a point value is given to each item. What is important is the relative values assigned to two items, for instance assume that item 1 is assigned 2 points. It should have twice the effort involved (in terms of complexity, risk or quantity of work) as a story which is assigned one point. This is an abstract estimate that could be hard to comprehend at first.
Story point estimation is done by the entire team as part of the Backlog grooming session.
Every user story is assigned a point value for estimation, which is, as we have seen, called the story point. To begin with, the team must find a baseline story to use as a reference. It could be a simple story, and one that everyone on the team is familiar with. Let’s assume that this story is assigned a value of 1 story point.
The next story that is picked up with be compared to this baseline story. If the team feels that it requires twice the effort, then it can be given the story point value of 2. No story point should be greater than 21, and if this value is reached then the user story should be split again. It is generally considered that 8 should be the highest value assigned, and most teams like to stick to this rule for ease of working.
Many teams use a simple exercise called Planning Poker to assign and to come into concurrence on the story points. This is a technique that builds consensus and uses a set of Planning Poker cards with values printed on the back; usually 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100. These will represent the number of story points and are dealt to all the team members.
One person will describe the user story and will discuss it in detail with the Product Owner so that the team members get clarity on what exactly it entails. Once it is discussed fully, each team member selects one card that indicates his or her own personal estimate.
All the cards are revealed, and the team then discusses the values on the cards and arrives at an agreement. The highest and lowest values may be discussed, to find out the reason behind such an estimate, and there may be one or several more rounds of card selection after this.
This process of selection and discussion is repeated till a consensus is arrived at.
The traditional and most common approach to measuring teamwork is by using man hours or calculating in terms of days or weeks. This is an easily measured metric but comes with many drawbacks.
While story points might seem a plausible alternative to using time estimates, they are not without their own associated challenges.
Teams that find that story points do not work for them can use other measures of calculating throughput and scheduling sprints. They can use time estimates in hours, or even work with high-level estimates only or no estimates at all. Each to his or her own!
Story points offer several significant advantages over hours.
Story points are the easiest metric to use when performing initial rough estimates. At the earliest stage, precise requirements may not be available. At least on a high level we can easily understand and estimate the scope of work using story points, without getting into minute details.
In many a case, the estimator of a task may be different from the implementer. Their skills and experience may be quite different, and they will take different number of hours to finish the task. When using story points, this problem does not arise as a story point is a relative value. The whole team works together to get an idea of the story size, complexity and risks involved, and it does not depend on who is implementing the story.
The velocity of a team is calculated as the amount of product backlog effort that is completed in one sprint. Teams with a higher velocity are more efficient and can make progress quickly. When the velocity is calculated using story points, since both are relative values, you will not need to re-estimate the project when the velocity changes. Teams that calculate effort in man hours will have to recalculate the velocity, as hours are not relative.
Quite often, the team members might have to move to a different project in the interim. Using story points, product release deadlines can be re-planned easily, without the need to re-estimate each and every task if team members change during the progress of the project.
Ready to get started?
As is the case with anything in Agile, the art of estimation using story points is something that will get better with practice. Once you have worked on a few Agile projects, you will be able to assign accurate story point values very easily. As the project progresses, the team can learn from the accuracy of their own past estimates and incorporate insights from the completed iterations into the estimation for the next sprint.
Your email address will not be published. Required fields are marked *
Systems thinking is a popular buzzword today. We h... Read More