Agile FAQs
  About   Slides   Home  

Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
RSS Feed
Recent Thoughts
Recent Comments

Story Points and Velocity: Recipe for Disaster

Every day I hear horror stories of how developers are harassed by managers and customers for not having predictable/stable velocity. Developers are penalized when their estimates don’t match their actuals.

If I understand correctly, the reason we moved to story points was to avoid this public humiliation of developers by their managers and customers.

Its probably helped some teams but vast majority of teams today are no better off than before, except that now they have this one extract level of indirection because of story points and then velocity.

We can certainly blame the developers and managers for not understanding story points in the first place. But will that really solve the problem teams are faced with today?

Please consider reading my blog on Story Points are Relative Complexity Estimation techniques. It will help you understand what story points are.

Assuming you know what story point estimates are. Let’s consider that we have some user stories with different story points which help us understand relative complexity estimate.

Then we pick up the most important stories (with different relative complexities) and try to do those stories in our next iteration/sprint.

Let’s say we end up finishing 6 user stories at the end of this iteration/sprint. We add up all the story points for each user story which was completed and we say that’s our velocity.

Next iteration/sprint, we say we can roughly pick up same amount of total story points based on our velocity. And we plan our iterations/sprints this way. We find an oscillating velocity each iteration/sprint, which in theory should normalize over a period of time.

But do you see a fundamental error in this approach?

First we said, 2-story points does not mean 2 times bigger than 1-story point. Let’s say to implement a 1-point story it might take 6 hrs, while to implement a 2-point story it takes 9 hrs. Hence we assigned random numbers (Fibonacci series) to story points in the first place. But then we go and add them all up.

If you still don’t get it, let me explain with an example.

In the nth iteration/sprint, we implemented 6 stories:

  • Two 1-point story
  • Two 3-point stories
  • One 5-point story
  • One 8-point story

So our total velocity is ( 2*1 + 2*3 + 5 + 8 ) = 21 points. In 2 weeks we got 21 points done, hence our velocity is 21.

Next iteration/sprit, we’ll take:

* Twenty One 1-point stories

Take a wild guess what would happen?

Yeah I know, hence we don’t take just one iteration/sprint’s velocity, we take an average across many iterations/sprints.

But its a real big stretch to take something which was inherently not meant to be mathematical or statistical in nature and calculate velocity based on it.

If velocity anyway averages out over a period of time, then why not just count the number of stories and use them as your velocity instead of doing story-points?

Over a period of time stories will roughly be broken down to similar size stories and even if they don’t, they will average out.

Isn’t that much simpler (with about the same amount of error) than doing all the story point business?

I used this approach for few years and did certainly benefit from it. No doubt its better than effort estimation upfront. But is this the best we can do?

I know many teams who don’t do effort estimation or relative complexity estimation and moved to a flow model instead of trying to fit thing into the box.

Consider reading my blog on Estimations Considered Harmful.

  • Nice write up Naresh. But I did not get if you just talking about not using the average story points for velocity or not using story points all together.

    I feel there is a need for some measure. Days dont really cut it as software writing is not a predictable task .

    Where i find value to to a rough degree of planning and plan only for what was done last sprint.

    In the end I assume that if you have teams that are committed and you have right set of folks they care less about story points but more about what value they are adding to the software.

    Trying to predict exact hours is a disaster that we have been doing for years. Compared to that story points – which i take is a measure of complexity , effort and doubt does make things a bit easier.

    But as teams get really good at the software they are building, we can simply look at taking features , breaking them and let the team get to whatever best they can get to. In the end we only have 40 hours a week.


    • In my blog, I was suggesting using Story points AND Velocity together is fundamentally flawed.

      You said: “I feel there is a need for some measure”.

      Can you help me understand what is that need and how does story-points fullfil that need.

      Also you are saying that Story points help you get a rough degree of plan. My questions is can’t number of stories give you the same rough plan?

      You said, “In the end we only have 40 hrs a week”.

      I don’t know about 40 hrs, certainly we have limited time & the worst thing we can do is waste it on useless ceremony.

      Also in your comments you said that “once teams get good at it, they can use just number of features for planning”. If you think that’s a better way, then why not coach teams to do that instead of doing things that are sub-optimal?

      In other words, would you force someone to fail few time with badly run waterfall projects before you teach them Agile?

  • Hmm, i don’t get the point why you say story points are a non-relative scale. For me story points definitely ARE a relative scale, a 2-point story is about twice the “complexity” of a 1-point story.
    (if you don’t take that assumption i am with you that a velocity is pointless and a kanban-like flow model of approximately equal size stories is an alternative)

    The reason for Fibonacci is not creating “random” buckets, but making clear that uncertainty gets larger with larget stories (we might be able to distinguish 1 and 2, but not 13 and 14).

    my 2 cents…

    • My understanding is a 2-point Story is more complex than 1-point story, but less complex than a 4-point story.

      IMHO it’s wrong to say 2-point story is 2 times more complex than 1-point story and 4-point story is 2 times more complex than 2-point story.

      How do you know its 2 times more complex?

      Let’s say we assume that something is 2 times more complex. Does that mean it will take 2 times more effort to implement? I don’t think so.

      Which means the effort required to implement 5 1-point stories is NOT EQUAL to the effort required to implement 1 5-point story.

      Hence Velocity does not make sense.

  • rakesh

    Hi Naresh,

    does this view of yours have any support amongst the agile fraternity? Mike Cohn for instance?

    I’m quite disappointed by what you say. Sure, 5 1point stories are not the same as 1 1point story. But iterations are not that small.

    Its certainly a better approach than what came before (traditional time estimates given by developers for insertion into MS Project).

    The management has a need, rightly or wrongly, to know how things are going and some idea of when things will be done.

    I’ve found this approach of estimating relative complexity using Fibonacci and then working a few iterations to see what the average velocity is very beneficial.

    Please, if you have a better way, what is it? This post just says what we are doing is wrong.

    • >> does this view of yours have any support amongst the agile fraternity? Mike Cohn for instance?

      I care a less. I share what works for me. I’ve seen many thought-leaders in Agile space doing something similar. There is certainly a pattern here.

      >> I’m quite disappointed by what you say. Sure, 5 1point stories are not the same as 1 5point story. But iterations are not that small.

      You are missing the point. Size of the iteration does not matter. Instead of 5 stories, you would pick up 50 stories, but the problem still exists.

      >> Its certainly a better approach than what came before (traditional time estimates given by developers for insertion into MS Project).

      Why do we keep comparing with hopeless things and saying what we have is great. In my blog I said that this approach is better than the traditional estimation model. But its not good enough.

      >> Please, if you have a better way, what is it? This post just says what we are doing is wrong.

      Please read my blog on Estimations Considered Harmful.

  • F3935c


    I wish I lived in your world. A world where managers and clients were happy to sign up to work with no idea how long it will take and therefore how much it will cost.

    The company I work for now is hopeless at pretty much the whole lifecycle (and they are not agile) but try telling them that their sales people should sell the product without committing to how much it will cost to the client.

    Bottom line, estimation is a very rough guide to work out how long it will take to do some work, but it needs to be done. The best we can do is to try and improve how good we are at it.

    The waterfall techniques suck, the relative complexity works, at the macro-level, quite well in my experience. Sure, if you take it the edge like 50 1point stories it doesn’t work but thats fine.

    I did read your other blog about estimates considered harmful and I don’t disagree with the problem of estimating. I just don’t think you realise that by saying lets not do them at all, is an answer in the real world.

    • I hear you F3935c.

      In the last 4 years I’ve asked many Sr. Executives (those asking for the estimates) “How successful has this approach of estimating worked for them? Please say the truth” and guess what their answer is?

      RARELY, yet they feel its a necessary evil.

      When I’ve highlighted some of the problems with estimations, esp.
      * creating silos & encouraging non-collaboration,
      * if you give me a small window of time upfront during which I need to tell you all the requirements, I would fantasize, tell you everything and anything that comes to my mind (because I don’t really know at this point). This woud mix up priorities, dilute the vision and confuse the heck out of people.
      * buffering at every level
      * encouraging wrong behavior in many cases
      * and so on…

      The big question is how can I really estimate with fair amount of confidence at the beginning of the project when I have least knowledge about it?

      Some people get it, they embrace collaborative, adaptive, flow based approach OVER estimation driven, phased/silo-ed approach.

      Again I’m not saying this is the only way to do stuff. Context is King.

  • intellectual banking

    this kind of story attributes are necessary to story writings.

    Licensed under
Creative Commons License