Someone recently told me that they believe “[backlog item] estimates are useful for junior teams.”

I heard a similar claim a few weeks ago, in the context of #NoEstimates techniques, like simple counting backlog items, rather than story-pointing. “No Estimates is an advanced technique. First you need to learn to do proper estimation.”

Hmm. I’m trying to understand this.

A key premise of the No Estimates ideology is that estimates are often a waste of time. They don’t provide much decision-making power, and often require a lot of effort and toil to produce.

If we agree that this is true, that estimates are imprecise, and labor-intensive, and that No Estimates approaches are therefore easier and more accurate, why on earth would we insist that “junior teams” learn the slow, difficult way first?

It’s not like the slow, difficult process is easier than the item-count approach. If it were, it might make sense to train new teams on the easy process first, then on the more complicated, but more accurate, process later.

So what gives?

My theory is that the people making these claims that new teams need to learn estimating techniques are only repeating their own experience. They learned estimating techniques first, then later learned no-estimates techniques. It was a progression in their own careers and knowledge and understanding. So it seems like others should learn things in the same order.

I don’t think this really makes sense. We stopped teaching that all matter is made of earth, wind, and fire, when we discovered it was an inaccurate model. We didn’t insist that “new physists need to learn about earth, wind, and fire first… then we’ll teach them about the periodic table.”

Will Button and I had a conversation about the broader topic of team maturity, which touched on this exact example, in a recent episode of the Adventures in DevOps Podcast. Have a listen.