A Practical Approach to Agility and Product Management

The Art and Waste of Estimation and Structure

There has been a fair amount of noise and chatter around “estimation” in the Agile community lately and some of this debate is turning heated and sometimes almost religious. I certainly don’t want to get dragged into that, but at the same time this discussion has helped me see a few things clearer that I wanted to share.

I’m going to widen the term from “estimation” a little bit and call it “structure”. Structure can mean a number of things, all of which are somewhat elective in Agile:

  • Story estimates (in story points, ideal days, t-shirt sizes, etc.)
  • Story decomposition into tasks
  • Task level estimates (most often in hours)
  • Capturing of actual hours at the task level

Sometimes the structure is extended to include things like

  • Iterations themselves
  • Sprint burndown charts
  • Planning conversations and exercises

Some of the voices in this debate quickly judge the above structural elements as waste or in Japanese “muda” (although – as Scott Ambler pointed out – using a Japanese term for something we have a perfectly good term in English for is waste in itself; why waste brain power on translation? But I digress…).

A number of these structural elements are mechanisms to help create team predictability. Predictability in itself has taken a hit in the community and some argue it’s pushing us back to waterfall. I’ll make the argument that despite business model at a minimum an Agile team should have some level of short-term predictability, i.e. the ability to make a commitment / forecast for the next 1-2 weeks and be consistent in meeting it (I’m not talking about defect/break-fix teams here).

At the end of the day, a high-performing, stable Agile team is characterized by being able to produce a significant amount of high-quality output (working, deployable software) in a consistent manner. Despite what Agile maturity model you subscribe to, this always seems to be a big part of it.

I postulate that the less mature a team is, the more structure and with that “data” and visibility into what’s going on it needs.

Having iterations, tasks, task-level estimates, a burndown and the ability to compare estimates and actuals will help a team get better and become more predictable and ultimately high-performing. These structural elements are like training wheels to help the team mature and build some important disciplines.

Once the team approaches high performance, one might consider selectively removing some of these structural elements, assuming the team is mature enough to where those don’t add any value and aren’t required for other reasons. But one shouldn’t have to get rid of any elements, especially if removing them actually negatively affected team performance (which could happen if critical or too many elements are taken away).

On the flip side, doing away with all or most these practices and artefacts right away or never implementing them in the first place (because they’re perceived as wasteful), before a team is high performing, is dangerous and will prevent them from reaching their full potential.

Interestingly, I’ve recently had the chance to see teams that never used to have these structural elements and when they were introduced for the first time, they served as quite an eye opener for them and the additional visibility seems to help them greatly in fine-tuning themselves and reaching higher levels of predictability and performance.

In certain situation data captured by the team may not always directly benefit the team, but serve a purpose outside the team in other parts of the organization. The team may not care about story points, but maybe the Product organization finds them beneficial in understanding relative size of and progress against various epics that – without story points – wouldn’t have a tangible size. Capitalization rules may requires actual effort spent on a project to be captured. In those cases the team should probably not remove those structural elements.

In summary, instead of calling structure wasteful right off the bat and quickly judging it as bad, I think a more deliberate approach might be in order. Maybe the conversation should shift away from “if” and focus more on “when”. It’s not all good or bad; it’s about what things make sense and adds value under what circumstances, during which part of a team’s maturity curve. New and immature teams will require more guidance, data and visibility. Mature, high performing teams will require much less structure.


  1. rrosendahl

    I’m using the y-axis for both maturity and structure (low/medium/high), i.e. I’m showing multiple variables. The x axis is time.

  2. kostas chairopoulos

    In both diagrams, the x-axis is time, what is on y-axis?


Leave a Reply

Your email address will not be published. Required fields are marked *

Discover more from Agile & Lean Product Development

Subscribe now to keep reading and get access to the full archive.

Continue reading