The Case for Story Points

Written by pete

Topics: Software Development

Scrum Masters embarking on a project or converting a team from conventional development to Scrum often run into one big roadblock: convincing the stakeholders to use Agile Estimation techniques. One of the most important and success-inducing things you can do when estimating an Agile project is to abandon the “hour” as the unit of estimation in favor of “story points”.

The idea is, instead of using “hours” to estimate how long a story will take to complete, you instead have the team use an arbitrary figure called a “story point”. So, a new input field on a web page might be “1 point”. A new login screen is probably “3 points”. And adding a new payment gateway may be “8 points”.

Each iteration will then have a point value assigned to it. For example, Iteration 6 may be “23 points”. When your team completes all of the functionality, the team’s velocity is “23 story points per iteration”. Savvy Scrum Masters will calculate Velocity as the moving average of the last 4 iterations.

Why bother ditching the “hour”? Here’s why:

  1. It eliminates preconceived notions about how much code can be written in a day.
  2. It eliminates the “Day” as an important unit of measure.
  3. It forces you to forecast completion of your project based on evidence. If you estimate in hours, you’re already forecasting. If you estimate in points, you’re simply measuring complexity in relative terms and relying on past performance to predict future results. In software, that’s a good thing.
  4. It helps to gel the team. If Joe can do a feature in 8 hours, and Eric can do that same feature in 12 hours, there’s going to be a disagreement on how much to estimate. Instead, shouldn’t Joe and Eric agree that “Two new fields on the screen is twice as big as one new field on the screen?” Over time, the difference in coding productivity between your team members will be abstracted away by the estimation technique, which allows each team member to play to their own strengths without being measures in widgets-per-hour.
  5. It ends up being more accurate after 2 or 3 iterations.
  6. It avoids the mythical man month problem. By insisting that you forecast based on evidence, a manager cannot offer to double the team size and cut the deadline in half.

There are lots more benefits. There are books full of the benefits. Read them.

In convincing stakeholders to allow the engineering team to use Story Points, I have run into several objections. Here they are, along with the answers that I use.

Objection: But if your numbers don’t map to hours, how do I know how long something will take?

Answer: You use Velocity, as calculated by the evidence of progress your team produces, and map target dates based on what actually happened instead of a gut feeling.

Objection: But then how do you know how much more you can get done by adding more resources to the project?

Answer: Again, you use the evidence. Adding a new team member doesn’t immediately produce a faster tempo on a project. There is no way to know how a new team member will contribute to a self-organizing team until you see them perform. As that team member ramps up, the team will eventually start producing more story points per iteration. You will only take on work in a sprint that you historically could complete, and as you start completing all of the committed work faster, your velocity increases. The team is continually winning instead of lagging. If you instead use “hours” to estimate, you’d be tempted to just add “40 hours” to the velocity. That’s a guess, and it’ll be wrong every time.

Objection: But then how do I calculate what a project costs me?

Answer: If you have all of the members of a Scrum team properly allocated, and you have an accurate forecast of the completion date, then you can easily calculate the project labor cost using very simple math. If you use hours instead, you use the same simple math, it’ll just be inaccurate.

Objection: But then how do I know how much overtime to ask the developers to work in order to meet my deadlines?

Answer: Forcing overtime to meet deadlines is a Scrum Smell. It means you are planning poorly, sticking to unreasonable deadlines, sacrificing quality, or the team is failing because of some organizational, process, or performance issue. That said, it is sometimes necessary to work overtime. Rather than tell everyone they need to work 10 extra hours this week to make the deliverable, it’s actually BETTER to say to your team: “We have 10 more story points to complete in 2 days, and we’re only burning 3 points per day.” If the Scrum Master is good, the team will know what to do. And they’ll do it as a team.

Good luck! Let me know how it goes.

  • http://www.enlightsolutions.com dpickett

    Awesome article. What are your thoughts about Ideal Developer Days? I still don't think it's as effective as story points estimated on a Fibonacci scale.

    As a contractor, I use story points for determining durations of projects. IE, I know I can burn 38-45 points a week (my velocity). I find it's the most accurate way to put together a scope of work.

    Where it proves most effective, though, is in re-prioritizing and evaluating the impact of changes with the client. My clients and I find it really helpful when we're shifting stories around based on their point cost when new ideas come into play.

  • http://blog.peteonrails.com peteonrails

    Hi Dan,

    Thanks for the feedback!

    I dislike Ideal Developer Days. I think they're a compromise on the “estimating in hours” argument. While they do have a nice name that leaves a little hedge for the developer to say, “Well, you keep interrupting me, so this isn't an ideal developer day,” I also think it keeps the focus on gut checking rather than on evidence.

    Joel Spolsky did a great article on Evidence Based Scheduling here: http://www.joelonsoftware.com/items/2007/10/26….

    While I disagree with Joel on BDUF and his approach to planning out projects, he is absolutely, positively, irrefutably correct about scheduling based on the evidence (IMHO). :)

    Once I noticed that story points and velocity were a way to implement EBS in the agile process, I was hooked and haven't looked back.

    –Pete

  • http://www.lalchronicles.com/vf Cecile

    Pete,
    I am not an agile specialist at all, but your article is really helpful in clarifying the productivity measurement question. Thank you!

  • http://blog.peteonrails.com peteonrails

    Thanks Cecile! I appreciate the feedback.

  • http://www.mysecuremovers.com/ boston moving help

    nice post

  • http://www.mysecuremovers.com/ moving labor boston

    This is such an awesome article and I love it. Keep on posting for I really like your article

  • graceglmcooke

    This is a good example of how mysterious finds can be solved with a little effort.
    Note that the Capital of Vermont hrsaccount is Montpelier, not Burlington. Burlington is Vermont's largest city.

  • http://www.extremerestraints.com/butt-plugs_1/ butt plug

    Thanks for clearing that up Grace, it almost got me lost.

  • http://www.evokedesign.com miami website design

    This is wonderful Pete! You have eased my mind on the productivity measurement question.

  • http://www.zoombits.de/spiele Spiele

    I dislike Ideal Developer Days. I think they're a compromise on the “estimating in hours” argument. While they do have a nice name that leaves a little hedge for the developer to say,

  • http://www.adamwride.com Adam Wride

    Peter – could you give some examples of how you can (semi) accurately estimate expenses in a given iteration or period? All this sounds good – it's just not clear how you translate story points into $.

  • http://www.digmydata.com/ Adam Wride

    Peter – could you give some examples of how you can (semi) accurately estimate expenses in a given iteration or period? All this sounds good – it's just not clear how you translate story points into $.