The significance of Story points

March 20, 2009 by Jack Milunsky

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.

Getting used to it
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…

Since this topic is near and dear to my heart, I have lots to say. So in an effort to keep this blog post short, I will present only the first 3 most important aspects of story points this week.

1. Universal measurement
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.

2. Steady state
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.

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

If you’re not estimating in story points, start now. You won’t look back!

Permalink