At a recent sprint planning session with a new Agile team, one of our team members asked why wouldn’t we use time estimates, as opposed to story points? The answer is they serve different purposes. Story points aren’t time estimates. They are actually relative measures of complexity between pieces of work.
What are Story Points
They help team team members with different skillsets and experiences agree on the complexity of a piece of work. We use story points to efficiently agree on the complexity of a piece of work during sprint planning. They are useful in teasing out differences in understanding, and in doing so identify some risks and dependencies early.
Delivering the Highest Value
Time estimates can actually complement story point estimates.
However, it’s hard to know everything about a business solution upfront. For example, you can’t discover all the dependencies until you actually start the work (or invest time prior with investigations or “spikes”). You discover more about each piece of work as you approach the work. Hence actual estimates fall out of date quickly.
Agile teams are focused on delivering the highest pieces of value (top items in the product backlog). If something finishes early, you move on to the next piece of value.
Having said all that, Scrum is an empirical “inspect and adapt” framework. Agile teams like to keep track of their “Velocity” (number of story points delivered per sprint), which is a useful metric for predicting when you’d start/finish a certain user story further down the line.
Here are some useful slides that discuss the topic of Story Points and Planning Poker.
Slides – Story Points and Planning Poker