As the instructor walked us through the exercise, he made it clear that “it depends” was not an acceptable answer. I asked if we could say “I don’t know”. And that was unacceptable as well.
It seemed that his only view of a viable answer to leadership was to provide a historical, trended data forecast. To give them as specific a timeframe as possible and lightly couch the risks associated with the estimate.
His primary driver for this position seemed to be that:
If we didn’t give them a specific forecast, they would go to someone (another team, another organization, offshore firm, nearshore firm, outsourced, etc.) that would make a more specific commitment.
I.e., that because we’re afraid of losing the “bid”, we have to provide something to win their confidence and win the work. No matter the level of confidence or runway we have in our historical “velocity-based” data.
As an agile coach, it seems one of the areas that teams struggle with the most is in estimation. And by estimation I’m implying some of the following:
- When do you “task out” the story? Who provides estimates for the tasks? And in what units?
- How do you breakdown, estimate, and re-estimate user stories? When are you “done” estimating them?
- Story points are relative and high level – should we convert them to hours or time?
- At scale, let’s say 10-20 teams, the estimates are interconnected across some teams. How do we handle dependencies and integration?
Mishkin Berteig has published a nice overview of 9 estimation techniques. As part of this article, I will review each one from my own perspective. Some I’ve used and others I’ve not. I’ll share my own stories to compliment the techniques.
This is a guest blog post by my colleague: Chris Waggoner. Enjoy!
Estimation of time and effort until you’re done is one of those things that every inquiring manager wants to know. In an effort to provide “accurate” estimates, companies and people spend countless hours generating list of task and debating the duration of each task. When it comes to developing software these estimates are rarely correct and often grossly wrong. The estimates are wrong because in building software that we are often building something that has never been built before. When we find ourselves being pressured to estimate something we’ve never done we tend to SWAG (PMI for Sophisticated Wild Ass Guess) the answer in man-days and/or hours without understanding or knowing all the potential variables in play. Here in lies the problem with traditional software estimation methodologies: within a short amount of time spent there are diminishing returns on effort versus value. That is to say, early in the traditional process the value of spending more time estimating doesn’t provide a higher certainty of when we will be done.
