5 Reasons Why Estimating in Story Points is a Superior Method
I get a little resistance from teams to start using Story Points for estimating, but it really is a superior way to estimate over hour based estimates.
Story Points should be used to estimate User Stories and quickly provide estimates to the Product Owner so that they can prioritize the product backlog. I recommend using the Planning Poker technique to get everyone on the team involved and timebox the estimating process.
What are Story Points?
Story Points are a relative measure of complexity, i.e. How big a feature is compared to other features. This type of estimating removes the notion of time from the estimate as team productivity is measured separately as Velocity.
Advantages:
- Quicker to Estimate
- Keeps Things Relative – Two team members can agree quicker that one feature is twice as complex as another compared to agreeing on how long it will take to implement. A senior developer may argue that it takes 2 days while it will take 4 days for a junior developer.
- Stay out of the Weeds – If the team has to think about every little thing to build a bottoms-up hours estimate then they will tend to try and understand every requirement detail and think through the design too much. When estimating in points you only have to think about comparative complexity, as opposed to trying to think about everything required to implement the feature.
- Do Not Get Stale – As team productivity changes there is no need to re-estimate. Velocity will change but the comparative complexity will still be valid.
- Better Metrics – Since the scope is isolated from productivity I can now report on how the scope is changing. If I had my estimate in hours it is difficult to determine if the change was from a scope or productivity change. For a release I like to report two main things to my stakeholders: scope (total points recorded at each sprint) and work completed/ velocity. This gives me clear visibility to both scope and velocity compared to the plan.
- Inaccurate Estimates get Resolved – If up front the team made overly optimistic or pessimistic estimates we will gain quick visibility to this as the team records Velocity in the first couple iterations.We will then be able to adjust the plan accordingly without having to re-estimate.
This post will tell you how to get started.
Articles of Reference:
The Case for Story Points – Peteon Rails
How Do Story Points Relate to Hours? – Mike Cohn
Agile Estimating Presentation – Mike Cohn
To add the the point of keeping things relative:
It’s not just the junior/senior division. I try to tell my teams that there’s benefit in doing it across role, too. You may have a feature that takes a developer 4 hours to do, but your QA engineer might need to take 8 hours to test it because of some need, perhaps the creation of a complex dataset or accommodating a new schema. A developer may not have insight into the QA viewpoint for the amount of work and vice versa. Story points steps in and allows them both to speak a common language about the amount of effort a story would require to complete.
Further, it can also help promote teamwork (in deed if not in word). Take my point about sizing something across role. Traditionally, your dev would say something like “*I* will take 3 hours to complete this” and your QA Engineer would say “*I* will take 2 hours to complete this”. If you’re sizing by story point, the size assigned to a story says, “*WE* will take this amount of effort to complete this.”