Fibonacci scale project estimates: how is it not vulnerable to misunderstanding by management?

Question

The Fibonacci sequence is to assist developers with project estimates. The concern is that we consistently see management use the points derived from Fibonacci sequence estimates to determine project velocity, or more importantly - developer efficiency. Which makes obvious sense to do considering that the point of any given project estimate methodology is to, well, estimate the velocity and remark on the trends.

The problem here becomes evident when you consider that a developer could easily demonstrate in one two-week sprint that they crushed 16 points worth of 1-to-2 point backlogs/tasks and then reasonably take two sprints on a single 8-point task. Now that developer has to defend herself as to why her velocity has dropped 400%.

Well she should get better at project estimates.

That's irrelevant. Considering the whole point of the Fibonacci scale is to provide some sense of exponential effort between tasks, a 1-point task vs an 8-point tasks is an 800% difference. In the case above, the developer actually underestimated but management quantitatively sees a dip in performance.

Then the team needs to define what the different points mean.

The only concrete definition a team could come to a consensus on is how much time a 1-point tasks takes vs an 8-point task but if we start trying to put time frames on it, we're defeating the purpose of this agile project estimate methodology; we might as well refer back to flat time estimates.

Well then management needs to understand that the points are exponential and that 16 points achieved in one sprint compared to 8 points in another sprint doesn't necessarily mean velocity went down.

Then why are we going through the trouble of measuring velocity if it's so relative anyways? If we're going to make management understand the complexity of each task that happened in the sprints, then why even use a point system that is consistently used to measure velocity? To be safe, why wont developers start overestimating their points so they cash in more points per sprint? All of these what-ifs and "it depends" doesn't sound very agile.

Answer 1

Velocity was never intended as a performance measure. It is designed specifically to help teams to estimate their capacity in future sprints. If it is being used to criticise the performance of teams then you have a problem.

What this highlights is not that there is an issue with the Fibonacci scale, but how important it is that everyone involved is educated about the agile approach that is being used.

Agile has never been just about the development teams. It is something that the whole organisation needs to understand and adapt to.

Answer 2

Now that developer has to defend herself as to why her velocity has dropped 400%.

If the developer is having to defend velocity changes on sprint by sprint stats alone, that is completely wrong. The team will know if someone isn't putting in the effort needed.

It might be that a three, or five, sprint rolling average might be a more realistic measure.

However, here's another idea I like to encourage. Points are a rough estimate of complexity, relative to each other. If the team end up with a high points estimate, then it's an indication that the story is probably too big.

If a story get a points estimate that's something like 50% of a sprint's typical velocity, then that should be a flag. If it ends up taking more than 50% of the sprint to develop, then are you actually going to have time to complete it in the sprint if defects are found, or some other blocker emerges?

Therefore, try to break that story down in refinement if it gets that sort of estimate.

However, it's not always the case that this things can be foreseen, perhaps the issues emerge after development has started. I'd always encourage my teams to fail fast here, abandon the story and take that knowledge to the BA to create further stories, don't plough on trying to sort everything out on the first story. Treat the original one as a spike.

Basically, you'll get a good consistent flow of stories, and therefore a pretty regular velocity, when you are always dealing with stories of 1, 2 or 3 points, maybe the odd 5. This should also resolve your last point about the temptation to overstate the points.