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?
What is a Story Point and its role in Scrum?
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.
How to use Story Points to estimate the project
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:
- The amount of work
- How complex the work is?
- The amount of risk involved
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.
Story Points and Planning Poker
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.
Challenges with time estimations
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.
- It is not always possible to estimate some tasks with precision, as they may not be defined well or could have dependencies.
- If one developer starts a task and someone else finishes it, the estimate is not valid as each developer will take a different time for completion, based on his or her experience and expertise level.
- Obstacles are not factored into the time estimate.
- Team members tend to over commit, based on the best-case scenarios.
Challenges with Story Points
While story points might seem a plausible alternative to using time estimates, they are not without their own associated challenges.
- Many people don’t understand them, as they represent an abstract value. There are team members who like the definitions of estimates to be more precise and tangible. Story points simply aren’t that.
- Team velocity and story points cannot be compared against similar values mapped out by a different team, as they are relative metrics. Managers who do not really get what an agile metric is, could end up comparing the velocity of different teams, or not following the whole purpose behind story points. They could be misused, since they are so frequently misunderstood.
- Story points lay focus on the wrong things, and can inculcate bad habits. When teams are asked to benchmark their numbers and output, they might rush through the work— marking tasks as done even when they are not completely finished. This reduces the quality of work and increases technical debt.
- Story point estimation is a very tedious process and takes away from the fun of working on an Agile project.
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!
Unleash your potential with our project management training course and elevate your career to new heights. Join now and become a master of organization!
How are Story Points considered to be better than Hours in 2021?
Story points offer several significant advantages over hours.
High-level estimates are simplified:
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.
Different skill levels and experience across the team will not matter:
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.
Ability to track velocity:
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.
Story points allow greater flexibility:
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.
