Story Points are Hard
About a month ago I was sitting in a meeting with a development team who were being asked to provide story point estimates for stories which they were going to work on. I was lucky enough to be in one of the meetings where a new developer had been added to the team, and questioned what the value of story points was. His argument was simple – if you are eventually going to ask me to report in hours, and use some sort of formula for converting story points to hours, then why don’t I just tell you how many hours it is going to take me?
The Scrum Guru for the organization was in the room, and he ultimately couldn’t convince the developer of the importance of Story Points. He hit the usual key points – but ended up going into a tangent about how the team might not be Agile enough, and that it might need some review etc. Ultimately the developer gave up, and picked the same number which his peers had suggested he should in the first place.
This post isn’t about the value of story points. There are certainly many others who make the case. What stood out to me was how well this developer highlighted something which most people ignore about Story Points – they only work when your organization has bought into the importance of Story Points. If you end up doing some sort of secret calculation to track in hours, or use the hourly estimate from your task breakdown to track your velocity – then Story points dont mean a whole lot.
I’ve been in plenty of groups where the arbitrary nature of Story Points had transformed them into something meaningless. There is almost always some sort of conversion/translation method which the Lead Developer has. “1 Story point equals 1 Ideal Day of work…” or “1 Story point means about 4 hours”, etc. As long as your engineering organization has been trained to deliver estimates in hours, story points always seem to have this translation accompanying them.
A lot of the Scrum books I have read make it sound like Story Points are mandatory. You use them, or you aren’t doing Scrum. Personally, I am of the opinion that this is an “Advanced” Scrum concept, and one which you might want to put on hold if you are implementing Scrum in an environment which has a lengthy and established history of waterfall development. If you are starting fresh, at a startup or something like that, then start with story points and you should be fine. But if you are at a company which pays an outsourced development team based on the number of hours spent on a project; maybe Story Points is something you should tackle a few months after you have developed some stability in your Scrum Processes.