Marek Blotny's Blog

There are scenarios where story points can be very handy and using them is beneficial. But before I move to that, one thing has to be clear:

Like it was stated in my previous post “all that business care are man-days and how many is needed to get things done”.

So it’s essential to establish mapping between story points and time, something like this:

1 SP = less then 4h
2 SP = 4 hours to 1 day
3 SP = 1 to 2 days
5 SP = 2 to 4 days
8 SP = 4 to 8 days

It’s important to remember that points are estimates so mapping story point to a single integer is like chasing rainbows. Estimates should be represented by ranges and the same goes for story points.

As a result of this approach engineering team should be able to say for instance that they need 10 to 20 weeks to deliver a project.

Of course at this point range is quite wide. There are a few options to do something about it:

• use historical data for similar projects to compare estimates and the actual time which was needed.
• ask experienced members for an opinion – they might tell you straight away that there is no chance to deliver in 10 weeks.
• simply assume that optimistic scenario (10 weeks) is not very likely

The best part is that after each sprint you will be able to predict more accurately how much more time your team needs to deliver. Even after first 2-3 sprints you should be able to say if you are close to optimistic scenario (10 weeks) or pessimistic (20 weeks).

Story points are about relative size of work

In one of the comments under Mike Cohn’s post I have found great example for usefulness of story points:

One of the most compelling reasons to prefer story points even though it is another way of estimating effort is because it allows individuals of different skills to discuss the relative size of work. My favorite example is of two runners at the start of a trail–one says it will take 5 minutes to run, the other says 10 minutes. Both are right. Those are the amounts of time it will take each to run. There is no time-based argument they can have to settle on the “right number.” However, both can agree that some other trail is twice as long—one runner will be thinking “Yep, 20 minutes” and the other will be thinking “Yep, 10 minutes.” But both can agree “twice as long.”

Using story points to estimate enforces team members to focus on discussing relative size of stories. They just need to define some reference story (for instance worth 2 story points) and other stories compare to it. This way team members don’t wast time arguing about exact number of hours. Story points are not so fain-grained. For mature teams this approach should be much more efficient then estimating directly in hours/days.

One final thought … it’s probably good idea to use story points to estimate user stories but be aware that people might have very different view on what story points represent. Make sure that all members of your team understand story points in the same way.

If you liked this post, you might like these, too:

1. Story Points – What Does It Mean To You?