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.
- 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.