How we're using story points
A couple of weeks ago Joshua Kerievsky wrote a post describing how he and his teams don’t use story points anymore because of the problems they’d had with them which included:
Story Point Inflation - inflating estimates of stories so that the velocity for an iteration is higher
Comparing teams by points - judging comparative performance of teams by how many points they’re able to complete
On the team I’m currently working on we still estimate the relative size of stories using points but we don’t use velocity per iteration to keep score - most of the time it’s barely even mentioned.
Instead for the past couple of months we’ve just been using the velocity to see whether or not we were going to achieve the minimum viable infrastructure (MVI) that we needed to have done before launch.
The nice thing on this occasion was that the MVI was actually reasonably flexible and there were bits of it which were 'nice to have' if we had the time and would make our life easier but didn’t have to be there to launch.
As it turned out we ended up finishing the cards required for the MVI a couple of weeks early which left us some flexibility/time to do things which had been forgotten or cropped up late on because something else didn’t work.
We did have a few weeks where our velocity fluctuated massively but an interesting observation which Phil made at the time was that despite the points totals being different we’d actually completed roughly the same number of cards.
Joshua describes the same thing in his post when detailing an email sent to the Extreme Programming list by Don Wells:
We have been counting items done. Each week we just choose the most important items and sign up for them up to the number from last week. It turns out that we get about the same number of them done regardless of estimated effort
This approach was described to me a few years ago by Julio Maia but as I understand it works on the assumption that we can break the work down into chunks which are roughly the same size which in my experience is very difficult to do.
Whatever approach we end up using I think it’s important that we don’t praise or criticise the team based on the velocity achieved that week.
I’ve worked on numerous teams where the project manager will praise the team in the standup for achieving a velocity higher than normal even though nothing has changed which would account for the increase.
In fact the change in velocity can probably be accounted for by normal variance.
If we don’t do that and just use the story points as a tool for roughly judging how much work we can complete in a time period then they’re not so horrendous.
Easier said than done of course!
About the author
I'm currently working on real-time user-facing analytics with Apache Pinot at StarTree. I publish short 5 minute videos showing how to solve data problems on YouTube @LearnDataWithMark. I previously worked on graph analytics at Neo4j, where I also I co-authored the O'Reilly Graph Algorithms Book with Amy Hodler.