(This was written as a response to a Product Owner joking about the “agile religion” when discussing Fibonacci-based estimating with an agile team.)
A lot of this agile stuff seems to be a set of buzzwords. Fibonacci Series estimating is an example. It was snapped up as the preferred methods by some agile frameworks, and then became an “everyone must do it all the time method.” Now many people do it because they are told to, without learning why. Some industry pundits lament that Scrum is turning IT into Fibonacci simpletons. That’s unfortunate, because such techniques have value.
Some of the popular methods now associated with agile are like training wheels for new teams. Sometimes these cute methods and agile buzzwords are a way of getting people to re-discover old, core, sound practices without falling into the common abuses of those methods. Fibonacci series estimating is an example of both views.
I’ve worked with many teams worldwide, and one universal problem was super-techies saying, “I can solve that problem in two hours.” The problem is, Super Techie can’t single-handedly solve all of the problems, and rarely is a development problem merely writing the lines of code. The resulting estimating conversations usually involved Super Techie telling the less-talented people, “you’re an idiot”, people clamming up, and all dissenting opinions dying on the vine.
In this scenario one gets chronic under-estimating, and enraged sponsors wanting to know why everything is two years late and 300% over budget.
The most well-known form of Fibonacci estimating is Planning Poker©, which is copyrighted by Mountain Goat Software.
Scott Ambler points out, "There are some common estimating heuristics that seem to hold true:
- small things are easier to estimate than large things;
- the people doing the work are motivated to get the estimates right;
- you're more motivated to estimate things nearby in time than far away;
- several estimates are better than one;
- someone who as done it before is likely to give a better guesstimate than someone who hasn't.
Planning poker tends to leverage most of these heuristics."
Since inception, ISPI (and the models its founders helped create) has encouraged teams to size the problems they’re going to solve. At first, many people used Source Lines of Code as their “sizing” unit, which was a minimal improvement. Later, other methods emerged such as Function Points, Cyclomatic Complexity, COCOMO, SLIM tools, and Feature Points.
The later methods were an improvement, but often ran into the problem of bloating into overly complex estimates, or driving for insane precision. Both extremes are a waste of time. The core idea, however, is sound: teams should not just be asking how long it would take to just write code, they should be asking such questions as:
· “how many logical steps are we developing here?”
· “how many data elements are we trying to manage?”
· “how simple or complex is the evolving data model?”
· “how many interfaces do we have to create and manage? How vulnerable are we to external groups when working with interfaces?”
· “how much control do we have over the infrastructure? How likely is it to change?”
· “how many questions, answers, prototypes, and refactors are probable when dealing with external group XYZ?”
Some of the above elements of complexity make razor-precise sizing and estimating difficult, and it wasn’t necessary anyway in most cases. Post-waterfall industry wanted “just in time, just enough” estimating techniques that didn’t tempt teams back into old bad habits. Fibonacci series estimating was one method that emerged.
Fibonacci estimating’s view is that just enough precision is superior to extreme precision. Having a team estimate the relative complexity of a story, discussing the ins-and-outs of what make it complex, and then estimating the size (points) quickly gets reasonable answers on size. From there, the team can start tracking how many of those story points it can manage in an iteration. And that’s good enough for starters.
Some teams evolve past that (and some teams don’t feel the need to). Not only can some teams estimate more precisely than with Fibonacci sequences, they may have real reasons to do so. Such teams move beyond the “training wheels” of Fibonacci estimating to do more parametric estimating. That’s why we’re seeing techniques such as simplified function points renewing their popularity.
The risk with higher-precision techniques is (of course) is falling back into the trap of believing everyone, everywhere, must strive for more accuracy and stability in our estimates than we reasonably should. That can lead to obsessing over estimating, and taking hours to refine estimates that would be better spent designing and coding. Eventually it can lead to fiercely defending our wonderful estimates, complete with spreadsheets and graphs – and loaded with assumptions.
When we treat all changes as evil in defense our complex estimates, we are right back to rigid Waterfall thinking. Twisting all work to justify the plan, rather than periodically tweaking the plan, creates wasted effort propping up PM egos. It’s foolish.
But it’s equally foolish to follow Fibonacci estimating and other Church of Agile* liturgy without the team understanding why. Ensure such practices are performed with understanding, not by rote.
**************************************************************************************
* I once spent a good amount of effort helping set up a team room, complete with Kanban Boards, User Story format posters, posters on scaling agile, parking posters, Ishikawa category prompts, and so on. One Subject Matter Expert dryly referred to the whole setup as my “agile church.”