Story points: A mystery story

I really don’t get some Agilists’ attitude towards story points.


That we should evolve a local unit for quantifying the size of stories makes pretty good sense to me. What I don’t get is why this private meaning is treated as sacrosanct. It’s certainly true that attempts to quantify estimates objectively (in terms of days effort, typically) seems to lead almost instantaneously to developers being held over a barrel. But that’s not really a problem with objective quantities, it’s more an issue with the traditional culture of project management – contractual, and like all contractual relationships, ultimately punitive. Why, if you have succeeded in breaking this cycle – as, with a successful implementation of Agile, you surely must – the resistance to objective estimates persists is beyond me.

And it’s not as though we really use story points in this entirely localised way. Almost the first thing we do once we have estimated a story is to add up the story points and work out whether there are too many to fit into the release timescale. But the release timescale is inherently objective – allowing for a realistic working day, it’s the number of days effort available between the release’s start and end dates.

So, if we are a team of 6 and there are 50 working days in a five-iteration release, then that gives us 300 days effort. If at the same time we are saying that the story points add up to 600, and we agree we can fit it all into the release, then one story point equals half a day’s work. In other words, we have already started to objectify our story points as soon as we start trying to align them with the iteration plan.

Of course, another team may have decided that the same release could fit in 900 story points, and that would be perfectly OK. But again, as soon as they make this claim they are telling me that a story point equates, on average, to a third of a day’s work.

The same thing arises with burn charts – as soon as you draw that line telling you (roughly) how many points you need to complete each day, you’re deciding what the objective value of a story point is. Likewise with velocity. As soon as you say how many story points you completed in the last iteration, you are implicitly saying how many story points each member of the team delivered per working day. In fact you can only use velocity if you compare like with (objective) like.To do that you must:

  1. fix iteration durations and team size (not realistic and really quite silly), or
  2. (implicitly or explicitly) calculate how many story points you deliver per team member per day – which is to say, turn story points in an objective quantity.

I appreciate the need to break free from the coercive, even predatory approach to estimating and planning many traditional organisations have, but surely a securely Agile organisation can drop this additional protection? By all means have local units of measurement (i.e., locally defined story points), but please let’s not pretend that this is the last word in Agile estimating. It’s not ‘bureaucratic’ to want to know what is going on, and it’s not wrong to want to know whether the objective cost of delivering a story is worth it – especially when Agile itself trashes the whole idea of localised story points pretty quickly.

By |2018-04-17T10:24:33+00:00Friday, August 14 2015|Categories: Agile, All, Bureaucracy, Business case, Project management, Stories, Story points|0 Comments

About the Author:

Chief Architect,

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?             
error: Agile201 is wholly copyright and copy-protected.