The Story with Story Points

ComplexKeatonI don’t like story points. I think this is part of my crusade against complexity. You can catch a glimpse of  it here.

Story points were invented as supporting beams for the bridge between business and development that would later be called agile.

They started with a very good concept that wasn’t there before: The story.

Remember those hundred page specs, and detailed feature documents? With the Agile Manifesto, we decided we liked customer collaboration over those. In XP, there was a customer on-site, so time would not be wasted on writing those documents, reading them, misinterpreting them and developing the wrong things in them.

And so the story replaced the feature. It was no longer “something that the application allows”, but also had a “Why” element. In XP, that story was translated into tests in TDD. Years later, stories would find themselves replacing specs in BDD. Actual examples of how a user would use the system and why.

Now in the days before agile (and, believe it or not, sometimes even today), once we had a story, the next question would immediately pop: When will it be done?

Developers hate that question. There’s a  whole #NoEstimates discussion built around this question alone. (You can read some of it here, here and here).

The dysfunction with the estimation is that it was considered a commitment. So to make sure they have met that commitment, developers needed to invest more time in getting the estimate accurate.

The story point is an abstraction that solved both problems. It had no units, so it can’t be related to any commitments. And if you asked the right questions (“How is this compared to that thing we did last time”) it would save a bunch of time on the estimation process. You just compare things until they are basically the same, instead of analyzing each story on its own.

It seemed that all our problems were solved!

Well, not really.

The business people still wanted to know how long the story would take. And not only the story, the whole backlog. The answer was very simple: assign hours or days to a story point. So a story point would becomes another unit.

This is like measuring in Celsius and Fahrenheit in the same project.

This conversion could be done the easy way or the hard way. We took the hard way, of course. So we analyzed and measured and estimated what a story point equals, taking away the 2nd advantage of the story point.

We’ve also built separate processes with the new units. In Planning Poker, we used Fibonacci numbers to estimate stories. That was another scale for the unit. Which is like converting Celsius into a non-linear scale.

And then we have velocity that was measured in story points. Because the velocity was calculated based on the estimated effort, not the actual delivery. So now the team is measured according to their estimation, rather than their delivery, in imaginary units, with the incorrect values. And those values are used for the next estimation. That’s like taking the weather forecast from last month and applying it this month, instead of opening the window.

Story points did not save developers from answering the dreaded question “when will it be done?”. It required them to translate between systems twice, and give back an answer in time units. The translation just wasted more time.

We can arrive at the same results with time units.

In the end, we just achieved more work, more confusion, and more complex tools by project management tool vendors who happily gave us yet another way to shoot ourselves in the foot.

Ron Jeffries was quoted recently “I’m not sure if I was the inventor of story points, but if I am, I’m sorry”.

Story points seemed a good idea at the time. They grew more complex and took over our lives, making them harder. If you’re using story points, you’re doing it wrong.



13 comments on “The Story with Story Points”

  1. Neil Reply

    Great post!

    What you’ve described here is pretty much word for word my experience also. In the end we used Story points to keep the “process police” off our backs and happy (because despite being agile, you couldn’t change the process because then you’d stop being agile – doh!), and internally for sprints we’d simply use gut feeling – did we think we could do it. Story points and velocity estimates never really had any predictability/reliability to them (and we really tried!), but it turned out a room full of experienced people’s gut feeling was right more often than not.

    The question of “when will it be done” was usually solved by having a reasonably organised backlog, and again, more often than not, the return question was “how important is it compared to the top things on the backlog”? Typically it wouldnt be that important and the question would just be a backlog item, and if it was genuinely important, then we’d use our guts for a time estimate (because why waste time estimating if its not important?)

    • Gil Zilberfeld Reply

      Thanks for the comment Niel!
      My experience is the same: An experienced team can manage. Time units help alleviate the “when” questions because everybody understands days, and the rest of how we treat estimations is up to us, not to imaginary units.


  2. Juan Pablo Bruno Reply

    I’d like to think that the problem is not story points. It is how engineering organizations communicate commitments.
    I’ve been using story points (even for ROM estimates and planning). To that estimates, using an estimated velocity (from your recent history), and using methods for planning (statistical ones, not a tool) you can manage variation, make a plan, and just then, when you have some plan addressing variation and uncertainty, communicate the commitment. I’m sorry, but I don’t think engineering will solve this fight with sales avoiding the estimates.

    Again, in my experience, you cannot pretend to have accurate estimates, you need to worry to have accurate plans and commitments. To get to that, there are techniques that help.

    • Gil Zilberfeld Reply

      Thanks for the comment Juan Pablo!

      I’m with you all the way. Experience like this has brought me into the #NoEstimates community.
      This post is not about getting better estimates. It’s about better communication with the other side. If you’re not ready for #NoEstimates, I suggest working with common units. It paints a clearer picture and raises visibility.
      An accurate estimate is a contradiction in terms 🙂

  3. Ash Ganatra Reply

    hmmm not sure I 100% agree with this:

    So now the team is measured according to their estimation, rather than their delivery, in imaginary units, with the incorrect values.

    Velocity isn’t an estimate it’s based on actual story points delivered the story point itself may be an estimate but they have real value if used properly with relative estimation.

    • Gil Zilberfeld Reply

      Thank you for the comment Ash!

      But what are “Actual Story Points”? If those are of imaginary unit, they can expand and shrink as we may see fit.
      And what kind of value are we talking about? If it’s for comparison for new tasks, that can be done with time units as well. If it’s capacity planning, we’re talking averages, which will give a clearer (and much more convincing) picture in time units.

  4. Zach Bonaker Reply

    After reading your article, it appears to be describing a scenario of mis-application of relative estimation, questionable management, and misunderstanding of story points.

    Thus, when you say “if you’re using story points, you’re doing it wrong”, the impact on me is a feeling of informal fallacy in your reasoning.

    • Gil Zilberfeld Reply

      Thanks Zach!
      I feel exactly the same way 🙂
      I’m applying the “you’re doing it wrong” to all the dysfunctions.
      Story points are symptoms. If everything else works, I don’t see the added value to story points over time units.

  5. Evan Campbell Reply

    One of the best reasons for preferring story points over absolute estimates is that they address only the size of the work, whereas hours or ideal days conflate size with the productivity of whoever is doing the work. If a team’s productivity changes, items in the backlog must be re-estimated and historical size based metrics of throughput lose utility. One can argue that backlog items shouldn’t be sized at all, (no estimates) but Product Managers make better tradeoff decisions if they know what features cost. In my experience (assuming no managerial abuse) teams quickly learn to use story points effectively, and they can help teams and leadership measure capacity and move from push towards pull.

    • Gil Zilberfeld Reply

      Evan, thanks for the comment!
      Those story points are a nice toy. You need to translate them back to “are we meeting the deadline”. If you’re in a better environment you don’t get any benefit over time units.
      The fact that people quickly learn to use them does not point to their effectiveness. Twitter is very easy to pick up but it’s wasted much of my time these last years. It’s not effective for work.

  6. Ralf Westphal Reply

    The problem are not so much story points but the usual kind of commitment, I guess. However you arrive at “It’s these stories A, B, C we’re going to do until next Friday” is a recipe for disaster. You’re making a result promise; that’s extremely risky (unless you’ve tons of experience in what you’re doing – which we don’t have for new requirements) (see

    Story points are ok if used for comparison (comparative estimation): “Does story A take longer than B?” If story points are used for ordering stories, that’s fine (see WSJF, But what to do then?

    After stories got ordered in some way then start at the beginning and work on them. That’s it. Just sit down and program diligently. Make a behavior promise: “From today on I will devote each day to transforming stories into quality code – until I’m finished.”

    Stories cannot be implemented faster than that. They’ll be finished when they’ll be finished. Not sooner, not later.

    That’s the only commitment you should make: Work on stories in order.

    Why the order looks like it does is essentially none of your business as a developer. If the order stays the same over the course of a day, week, month is of not much importance. Just pick the next story when you finished one.

    And business can ladle code with finished stories from the continuous flow of incrementally growing release candidates whenever it deems them to contain enough value added for a next release.

    So also forget about velocity. It’s not the speed which count, it’s the flow. Don’t let the story transformation pipeline get clogged. Maybe watch a burnup-chart and see how the curve’s steepness changes. But there is hardly an end in sight.

    The obsession with anticipation puts unnecessary stress on software development.


  7. asdasdffasd Reply

    SP == Bad
    I recommend: Pull-To-Capacity (requires really well written requirements – in whatever pbi structure u choose). Measure throughput (Dan North?). Use CFDs (Cumulative Flow Diagrams) to measure throughput against the list of higher level requirements (Epics/Features/Business Capabilities).

    If you do a pull-to-capacity, you no longer need sprints; you take away the wasted time ‘estimating’; and you allow your requirements to be written in a way that value is maximized (vs just making them small)…

Leave A Reply

Your email address will not be published. Required fields are marked *