Story Points Explained - Part 2: Usage
This is the second of 8 posts. In these post series I'll try to tackle one of the more "mystical" topics of Agility: story points. In this post I will look deeper into uses of story points within an iteration/sprint.
So the big question here is: "What are story points?"
My personal definition would be: In software development, story points are an abstract unit of measuring effort, which varies in relation to team, reference stories, tools & technology, amount of work, complexity and risk.
This may sound pretty academic, I know. So let's take it apart and see what this definition would tell us.
The first thing is that story points actually only measure effort. I know that a lot of material in agility talks about "business value". Yet I've only seen them used as a measure of individual/team effort. They are also variable. In this definition I gave a list of possible causes for variation in story point value.
To ease story point adoption and usage in your team I recommend taking into consideration:
Reference stories
Reference stories are essential. They are also one of the hardest steps when adopting story points. In practice good reference stories will make team members effective estimators. Bad ones will bring only pain & chaos to your meetings.
I encourage you to have several reference stories. It makes it easier for people to estimate. You can have a list of 5 weights to compare a story to, or a table like this:
-------------------------------------------------------------------------------------------------------------------------------------------------------
| XS(1) S(2) M (3) L(5) XL (8)
|Webservice Small change Multiple small changes Complex change Complex change Multiple complex changes
| single service multiple services in multiple webservices
|Backend Small change ….
|Frontend
|Full Stack
--------------------------------------------------------------------------------------------------------------------------------------------------------
Try it out, experiment and find a solution that fits your team.
Variating unit of measure
Story points variate in time value from sprint to sprint. For example:
Our team did 23, 31, 28 SP during the last 3 sprints. Our availability was 140, 125, 160 hours. This leaves us with 140/23, 125/31 and 160/28 or 6h/SP, 4h/SP and 5.7h/SP.
As you can see variation is built in. This synergizes well with changing plans and receiving immediate feedback from business.
As business gets a better understanding of a topic, they will tend to have new ideas. Of course the team will have to monitor the potential of scope creep. One nice solution I've seen implemented is a rule: if a feedback takes more than 4 hours to build, we create a new story for it.
Velocity and Sprint Planning
