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

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 gets 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!

Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com

Comments

[Micha van Haaren]

Great post! I have tried to introduce this way of estimating in our projects, yet the other members are somewhat skeptic about this approach. They are willing to try this method, but are not quite sure how to start with relative estimation. So I was wondering if you could give some practical advice on how to get started? I also recommended the book “Agile estimating and planning” by Mike Cohn to the other team members.

[Jack Milunsky]

Hi Micha,

Great question. There are a couple ways to get started. One practical way I find really works is to start with 1 Story Point equal to 1 Ideal Hour (most agile thought leaders will say this is a bad idea as you're really trying to get away from time as much as possible - many reasons for this - but I find this works quickly and well).

Take a couple user stories so that there are some really small one's = 1 hour and some medium and really long stories

estimate those in ideal hours, so you'll have some 1 or 2 pointers and some 5 or 8's. Once you have a few, you can start comparing new stories to the ones you just estimated. So if a story if a story is twice as complex as the 1 pointer, give it a 2. Once you have got a few done in ideal hours, you no longer need to think in ideal hours ... you will have made the shift to points.

Hope this helps
jack

[Micha van Haaren]

Thanks for the quick reply Jack, we will give it a shot in our next sprint planning session!

[Mauro Botelho]

Even though in most cases looking only at Story Points for iteration planning is sufficient, our teams still go thru the process of tasking stories and estimating the hours for the tasks.

The main reason I suggest this is to make sure that the point estimates are still valid and to account for things like Vacations, etc.

At the time of the point estimation, the knowledge of the feature at hand might be imperfect. With 2 weeks before delivery the team probably knows a lot more then they did then. It also should help with accounting for the small things that might get forgotten otherwise.

[Jack milunsky]

Hi Micha,

You're welcome. Let me know how it goes.

And yes Mauro is 100% correct. Story points is good for planning. Once you have planned the stories into a sprint, you still need to do the task breakdown and estimate the tasks in hours which you then track on the burndown.

Let me know how it goes. Don't hesitate to contact me should you require it.

jack

[Raja K]

Hello Jack,

I might be very junior for this model and I have couple of questions. sorry being very ignorant!

1. I am following Fibonacci numbering for providing points to the stories. Basically I will provide points compared with previous story. Let say if I have 40 stories and at 35th story the point is say 2 then it will make me to revisit / review all of the estimates. Isn't tedious job? or pl let me know alternative to this or correct me if i am wrong.

2. Can you please explain what is the significance and benefits of assigning points to stories? Where I could see, feel the relevance?

3. Is there any standard execution template to share?

Thank You
Best Regards,
Raja K

[Jack Milunsky]

I am not sure if I understand your question correctly however based on what I think here's an answer which I hope will help you.

It really doesn't matter in what order you do the estimating. The idea is that you take a look at a user story and based on comparison to other similar sized stories you can predict it's size.

So one way to go about doing things if it's your first time is as follows (note there are many ways to tackle this .. this is just one way) to take all your user stories and divide them up into buckets e.g. small medium and large sized stories

Small stories would be in the rand 1 ... 5 say
medium stories would be in the range of 5 - 13 say

And large stories would be 21 40 100

Then take all the small sized stories and divide those into small smaller smallest. give the smallest stories a point of "1". After that you can look at the others and say ok if this story is double the effort of the "1" pointer then give that story a 2 point. and use your guide of small in the range of 1 - 5 points.

Don't worry about "100 accuracy" or going back and making changes unnecessarily. as long as you do this in a consistent way. Remember you are trying to get a relative sizing of user stories as quickly as possible. Then once you have completed a number of sprints, you'll know how many story points your team is able to complete in a given sprint.

[Vish Agashe]

Nice article. Other way to look at why story points work is because it is best way to normalize estimate. It becomes single unit of work for entire team in estimating effort. And everyone is talking estimates in terms of one unit (this allows for apple for apple comparison across stories). Also, estimating in story points helps team do gross estimates (rather than really fine tuned estimate which tend to be aggressive), accounting for team dynamics (skill sets, speed variations amongst team members, accounting for effective time rather than full 8 hours etc....)

[Jack Milunsky]

Glad you liked it. And thanks for your comments. Much appreciated.