Relative Sizing and Story Points
One of the ideas many people seem to struggle with in Agile projects is that of Story Points. In an agile project, the time to implement a story (a feature), is deliberately estimated in a weird unit called story points, rather than in number of hours / days.
What are Story Points
The most important thing to remember is that story points do NOT equal units of time. Initially you will naturally find yourself trying to convert story points to days, or estimating in days or hours, and then trying to convert that to story points.
RESIST this temptation! There is a method behind the madness.
- Research has shown that people are better at estimating relative sizes (A – C is twice as far as A – B, Basket X is about 1/3 the weight of Basket Y) than coming up with absolute estimates (A to B is 15km, Basket X is 7.5kg)
- Days are a very subjective unit of measure. Depending on other commitments, your ideal days are very different from mine.
- Estimating relative size is much quicker; and you need less information to get started (you don’t actually have to know how long anything will actually take, just the relative comparisons between different stories)
With a new project its impossible to know how quickly features will be produced. There are just too many variables – learning of the domain & tool set, agreement within the team, stabilizing of work patterns.
What you do is complete a couple of iterations, and then measure how many story points you delivered on average. This then becomes your velocity, which you can use to derive an estimated completion range based on the story points.
Note that with this technique your story points are still valid; as they are just measures of relative size/complexity. The only time you really need to re-estimate story points is when you got the relative size of a story wrong – perhaps it turns out to be much easier to send emails than you thought, or much harder to draw graphs.
Story Points are Relative
Story points are a unit of measure for expressing the overall size of a user story, feature, or other piece of work. When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values. A story that is assigned a two should be twice as much as a story that is assigned a one. It should also be two-thirds of a story that is estimated as three story points.
The number of story points associated with a story represents the overall size of the story. There is no set formula for defining the size of a story. Rather, a story-point estimate is an amalgamation of the amount of effort involved in developing the feature, the complexity of developing it, the risk inherent in it, and so on.
There are two common ways to get started. The first approach is to select a story that you expect to be one of the smallest stories you’ll work with and say that story is estimated at one story point. The second approach is instead to select a story that seems somewhat medium and give it a number somewhere in the middle of the range you expect to use. This means look for a medium-size story and call it five story points. Once you’ve fairly arbitrarily assigned a story-point value to the first story, each additional story is estimated by comparing it with the first story or with any others that have been estimated.
Significance of Story Points
Expecting your teams to estimate in Story Points can be quite a leap of faith. When I first introduced the concept of Story Points at my previous company no-one could wrap their heads around the concept. When it comes to estimating, we’re so accustomed to thinking in days or hours that making the leap to some obscure, seemingly illogical measurement is quite the expectation – especially a bunch of engineers.
Once you start using Story Points, it usually only takes a couple of sprints before teams start to understand the magic in this new practice. Many companies I talk to, who have adopted Agile, generally practice a modified Scrum/XP process. Many do not estimate in story points and from my point of view, this is a big mistake. In my opinion, Story Points are the fuel for the Agile machine. If you get the Story Point estimation working well, the rest of the Agile/Scrum process is a breeze.
So what makes Story point estimation so important, so good…
It’s the only mechanism that I know of for universally, determining the size of a user story. What I mean by this is that it’s the same measurement for any member on the team. In other words, if you rate a user story as a 5 story pointer; whether a senior developer or a junior developer on the team is implementing it, it’s still a 5 story pointer. The reason is that this is the relative size of this task compared to other tasks estimated by the same team – it has nothing to do with who is implementing it and how long it's going to take. If on the other hand, you rather choose to estimate in hours or days, it might be a 2 day task for a Senior developer and a 1 week task for a junior developer. Once the team has had some experience with estimating this way, Story Point estimation becomes quite accurate and can be done very quickly in comparison with traditional estimating techniques.
The real magic in Story Point estimation is when a team reaches what I call their steady state velocity. Generally this happens after 3 –5th sprint. Assuming all your Sprints are of the same duration (which I highly recommend – subject for another blog), then if the team is averaging lets say 40 story points per sprint then that represents their velocity, no ifs ands or buts. What’s great about this is that scheduling future sprints becomes a no brainer. i.e. the Product Owner get’s to fill the tank with, in this example 40 Story Points, nothing more, nothing less. As a result no unrealistic expectations are placed on the team and since the team is generally able to deliver 40 Story Points per sprint (because they’ve done this before already), the team is setup to succeed rather than fail.
In the zone
Story point estimating helps teams reach a sustainable pace. And hitting your targets sprint after sprint is an incredibly powerful and wonderful thing. The team feels really good about their abilities and this encourages them to do better. The business starts to believe in the team and this sets the team up in Zone. When you get into the Zone, the team can generally sustain it’s steady state velocity month after month without burning out. And better yet, they get to enjoy doing it.