It’s never been done before. Can you deliver it in 30 days?
That’s not too far from the truth with some of the development challenges we face. When you deal with innovation, and you’re a provider in the industry, you naturally deal with estimation. Can you deliver on time and on budget when you deal with the unknown, and how did you estimate that upfront?
Estimation in Hours
I’m continually reviewing what I’m most comfortable with. I like hourly estimation because it’s the currency we all deal with and yet it skews ranges in the wrong direction. If one story takes 10 – 15 hours and another takes 40 – 50, the bigger task provides less margin of error.
But at least it’s a common language. I like how Dan North, in his post The Perils of Estimation, describes it as we simply want a rough idea of size and an understanding of certainty. “There is uncertainty in everything, so the purpose… is to understand the potential landscape we are delivering in.” Its purpose is to convey to our stakeholders and ourselves a sense of size and to present the risk landscape in which to understand that estimate.
Estimation in Story Points
Brian de Haaff makes some excellent points about concerns over story points in his discussion about Why Do Scrum Fanatics Hate Time?
The argument that stood out for me is that story points force developers to ignore their experience. “Experienced professionals use pattern matching to recognize problems or stories that are similar to ones they have done before. This allows them to also draw on their experience of how long those stories actually took to complete.” I like this approach. Pattern recognition is an important skill on so many levels.
Though I’m less endorsing of the comment that “If a team uses an estimation metric other than time, then it is harder to use that prior experience to estimate the new task. Especially if the estimation metric has no linear relationship to time.” Some things are hard and unpredictable. I think story points lend themselves to the uncertainty. Story points of 1, 2, 3 and 5 lend themselves to confidence. When you’re reaching 8 and beyond, confidence starts to wane and business should recognize the risk.
The point to keep in mind, is innovation by nature is new and brings some unknowns. The business wants accuracy. Communicating estimates in hours implies precision. Story points may be better at capturing the uncertainty around the project, but help less in the situation where a quantity is needed.
For my own purposes, I assume 2.5 – 3 hours for a story point. It allows me to quantify that unknown variable of a story point, while giving some wiggle room on the exact number. And for those larger story point estimates, I fall back on the teams experience to help put that into the right ballpark – something that Mr. de Haaff can appreciate.
What are the methods you find most useful? Share your thoughts in the comments.