Stop Using Story Points
I recently read this incredibly interesting post from Industrial Logic by Joshua Kerievsky about his experiences with using story points in the agile development process. I have personally always been a bit wary of story points, since in the end, they just seem to get translated back into hours anyway. I have been witness to this several times, both as a developer and a Scrum Master. When you ask people to estimate in story points, preferably with the standard definition of 1 story point equals one day of productive work, then you invariably get estimates that when you multiply them by 8 are the same as they would have been if you had estimated in hours in the first place.
And then there is velocity. As Kerievsky points out, teams tend to focus a lot on the predictability aspect of agile development. They like to see nice, pretty burndown charts. However, an important question asked by Kerievsky in the post is what the cost of this obsession is in terms of quality. The post mentions TDD and refactoring as the first things to suffer trying to make sure that an estimate holds. What I particularly liked was how Kerievsky returned to the Agile Manifesto and pointed out how people are more important than processes and that a lot of the time, the really agile teams he works with base their estimates on Gut Feel. He states that their focus is on shipping, not working in a fixed timebox or tracking the number of story points completed.
In many ways, this is how we work in our current project. Of course, we are consultants, and in the world of consultants, billable hours are key. Our customer needs estimates up front. They need to make a budget for next year. They need to know how many hours it will take to do this and that. IOn top of that, we need to know how much work there is to do and how many consultants we need. So we deliver the estimates, even if they are almost never correct. Sometimes we overestimate. Sometimes we underestimate. The truth is that it is hard to know how long something will take, especially when working with a system as complex as the one we work with that deals with health care billing costs, until you actually start working with it. Even then, the estimate fluctuates from one day to the next.
So will we stop estimating and just start telling the customer that we will get 8 things done in the next sprint and you can see how many hours it took when you get the bill? No, of course not. We have to live within the constraints of the Consultant’s world, and one of those constraints is that we have to give some kind of indication up front what it will cost to develop new functionality. Sometimes we will be close. Other times, we will be off in one direction or the other. However, I think there is a lot to be gained from not expending too much energy on nailing an estimate and then obsessively trying to keep within that estimate. The important thing is that we see progress, i.e. tasks and stories moving across the board towards the Done column. Sometimes the burndown chart isn’t so pretty, but then again, beauty is in the eye of the beholder and a lot of the time, a successful sprint that produces a working system based on well written code is much more beautiful that a nice even line that stretches in a downward path on a chart.