Travel Points not Story Points

Travel Points not Story Points

Story points as a term has always worried me. To customers who have not had involvement in Agile projects it can seem as if it’s a way of scoring the value of a story. Points as we know mean prizes or at least a positive connotation. Admittedly it also has a synergy with scoring which is it’s correct usage here but why are we scoring a story and what are we scoring for? Well luckily for me it’s not spelling, punctuation or grammar. It’s also not related to the plot or if it’s got an exciting twist at the end although user stories do sometimes fit into these categories. What we’re really measuring is the effort to deliver that story however it’s not really a time effort.

We measure in relation to some small known and agreed effort expenditure that the entire team understands. This can form our baseline of one story point. Everything else is then scored according to the teams agreement of effort in relation to the baseline. For a great description of this effort take a look at Mike Cohn’s post on Mountain goat software’s site ( Here he relates story points to distance which to me is a great description and fits perfectly with the other Agile term “Velocity – distance over time”.

Distance or Travel not Story

So for example I know that when I get onto the M3 for the drive to work I have to drive for about a mile before I get to the next junction. This is a small enough distance to reasonably estimate and is a known quantity to the other people in my team, let’s say my team is made up of work colleges who travel the same route. We can therefore estimate that it’s about 15 miles of M3 joy until we get to the junction for work.


Now although we can agree that it’s 15 miles we will all cover that distance at different velocities. We as a team have moved away from a time measurement, it takes me 10 minutes because I drive too quickly where as I know some conscientious team members who take 18 minutes. Regardless the distance is still the same and still something we can agree upon. We can even agree to skew the figure as we all know that there are average speed restrictions on the first 5 miles. Thus our score is now based on distance adjusted for difficulties/risks. We’ve moved from a straight distance point score (miles) to a travel score that accounts for distance and difficulty. As a team we can also agree on the amount of travel we are happy to attempt in a set time period. This should take into account the varying velocities with-in the team to come out with some unified figure.

Distractions and Risks

For example given a day I’d not assume I can keep a constant speed of 90mph, there will be traffic jams, accidents, fuel/refreshment stops and potentially difficult road conditions which I’d want to slow down for. There may even be speed limits. Therefore I’d adjust this estimate and guess that I can happily do maybe 400 miles in a day or 4000 in a two week sprint. My classic car driving comrade would potentially only be happy to do 120 miles/day or 1200 per sprint. As a team (do two people make a team?) we may be happy to commit to 5200 miles per sprint although it’s never usually that simple a calculation. What’s even more useful is that we can measure our velocity or the distance we actually travel over this period and then base future travel plans on realistic figures.

 In software terms

So in software terms I understand how long it will take me to create web page with a grid of dynamic data on it, my colleges also understand this. We can agree this is our baseline of 1 story point. As my development skills are somewhat stale let’s say it will take me a day of fiddling and refactoring until I’m happy with the result where as my super skilled team of developers will take 2 hours. Neither of these times matter at the moment as we’re only looking to agree on a baseline. We can now sensibly talk about and score how much more difficult it will be to put up an interactive shopping basket and ensure its mobile responsive. We can all agree the additional factor of complexity over our baseline. We can agree a velocity we feel fits with the story points we feel as a team we can commit to and we can measure that and adjust our future sprint commitments as well as our release plans to these more realistic figures. The best thing is that the longer we do these things as a team the better we will understand each other’s capabilities and our total team throughput.

Originally Published 27th April 2016 – LinkedIn

Leave a Reply

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