Ah yes, my second favorite topic when it comes to all things agile — story points. My favorite agile topic? Agile project management tools. But that topic is easy to sum up in one sentence: All the agile project management tools I’ve ever used or evaluated tend to suck in their own unique ways. Maybe one day I’ll elaborate on that enlightening thought, but right now I want to focus on story points.
Story points are one way agile software development teams can estimate the size of user stories. For example, the product detail page for an ecommerce app is estimated to be 8 story points, while the report showing overall ecommerce sales vs. in-store sales is estimated to be 16 story points. We’re not equating story points to how long it will take. Take an experienced, cross-functional agile ecommerce software development team. They say the product detail page is an 8, but the newly formed team consisting mostly of COBOL and FORTRAN software developers estimates the product details page is a 128. Who is right? They both are.
This leads me to an email posted by “macdonald1976” yesterday to the Scrum Development Yahoo! Group with the subject line of “Why points are lame…”
First of all, anything you can make up your own definition for is lame and suspect to say the least. My CTO doesn’t care to hear that my dev team has 150 story points left. He wants to know how many hours they have left. Hours are not subject to opinion. There are 60 minutes in a hour and 24 hours in a day. My CTO can relate to this. My CTO cannot relate to some story point with weights assigned arbitrarily assigned. Sure, some of you will argue that it is not arbitrary and you are entitled to your opinion just like you are entitled to your opinion as to what constitutes a point. This opinion on a unit of measure and the unscientific approach to defining it, no matter how scientific you contend it is, is the reason it has no value in defining remaining effort. Points = opinion and like the old saying goes, ‘opinions are like butt holes, everyone has one’.
Oh no he didn’t. Sending an email like this to the Scrum Development list is like crashing a Star Wars party wearing a Spock costume and talking smack about Yoda in Klingon. I’m happy old macdonald1976 wrote this email because it reflects the opinion of many who don’t quite grasp the concept behind story points. Even better though, it caused Andreas Axelsson to give this spot on response (with my comments in between paragraphs):
Points are intended to give a relative measure of size for stories, not a valid estimate of duration. Mike Cohn (author of Agile Estimating and Planning) says: “Estimate Size; Derive Duration”. The rationale is that it’s much more likely that a team can agree on the relative amount of work for a story compare to another, than on how many hours it’ll take to implement it.
Straightforward definition that gets right to the point.
Compare with two people running a track; The first person will insist it’s a ten minute track, the other a five minute one. Who’s right? They are much more likely to agree that it’s a one mile track (or whatever one can run in five minutes, I honestly have no clue), and that a two mile track is twice as long. Any two people running the track are likely to get a different time, but it’s still the same size.
The most popular explanation for story points that I know of. It’s popular for a reason. It makes sense.
So, estimate in points, validate how many points you can complete in an iteration, using an average over a number of iterations, or historical numbers if you’ve got them, and use that to derive the total project duration. I.e. our velocity of the last three iterations was 27, then the remaining 189 points could be finished in 7 iterations. You do need to add a range though. Or to quote “It’s better to be roughly right, than precisely wrong”. If you’ve got an experienced team on a known domain, you may want to adjust the estimate -10/+5%, if it’s a fresh team learning a new domain the figure might be -50/+25%. (Values from Mike’s book) Using the first figure that gives us a velocity of between 24-28 meaning our 189 points could be done in between 7 and 8 iterations. The inexperienced newbie team would get an initial estimate of between 6 and 14 iterations. (It’s probably not likely that an inexperienced team would average the same initial velocity as the experienced team but let’s ignore that for this exercise, the issue here is the range) There’s really no way to know very early in a project. Experience will tighten the range as the project moves along. So your estimate may narrow from “1st quarter” to “February” to “Last week of February”, all the time giving the Product Owner an accurate estimate just not a precise one.
Practical and concise advice on how story points should be used within a project.
Something you shouldn’t do, however, is to try to transform the hours of your completed iterations back onto the remaining stories. Estimates are pretty much bound to follow the normal distribution and thus you’ll end up with “easy” fives and “hard” fives. Imagine the disappointment if you end up spending 76 hours on an “easy” five from your first iteration and then apply it to every five point story in the backlog. It just won’t work and you’re back at trying to estimate duration directly.
Man, Andreas is hitting a key issue here. Equating story points back to actual hours is particularly tempting for teams to do. Do not do it!
Also, there’s no promise that ten points for one team can be related to ten points for another. It’s just a number, that makes sense to that particular team, and the CEO should not care about its meaning in relation to duration or any other unit. It’s a unit-less relative measure of size for a given team. Period.
So, you give your boss the date range, derived above, not the points themselves. The points are to be used by the PO to prioritize stories along with estimated ROI and any other factors that may contribute.
And the final rebuttal to macdonald1976’s original statement that story points are just opinions puts the executive’s focus where it should be: on the value being delivered. The CXO doesn’t care about points, nor should she care about hours. The CXO should care about what value is being delivered and when the rest of the value is likely to be completed by. We fall back on bean counting hours when we take our eyes off what matters most in the project. We can still do budgets with story points. We can still estimate when our project will likely be completed. We can still know how our teams are performing. We can still determine if the project is on track to deliver the goods. The bonus is that we don’t get caught up in spreadsheet hell, calculating every hour down to the penny. Instead, we can focus on making sure our businesses are delighting customers.
I absolutely recommend Mike’s book if you’re interested in a more in-depth explanation of the above thoughts.
Cheers,
Andreas Axelsson
Cheers is right Andreas. Cheers indeed. A full round of applause goes out to you for that excellent reply! It made my day.