Its 2021 — Why are we still trying to get perfect estimates for user stories?

Surbhi Bhati
3 min readFeb 17, 2021
Photo by Kelly Sikkema on Unsplash

Humankind has been developing software for over 25 years. That’s quarter of a century. The Agile manifesto was first published in 2001. Thats 20 years from today. You’d think that after all this time we would have learned the nature of this work. We would have learned that in a large-scheme of things, the estimates assigned to a body of work; mostly user stories, don’t matter. They are only and always, the means to an end. Seth Godin (not an agile coach but a marketing guru and big advocate of ‘ship-it!’) has been telling it for years. Despite this, despite the expensive certifications and extensive ‘agile-transformations’, the chasing of perfect estimates is all too common in the enterprise-agile world.

Why do the enterprises adopt Agile? In most cases they do this because they think it will enable them to deliver faster

What they usually do not think about is that Agile has a cost. I am not talking about the financials here. The cost I am referring to is the comfort zone. The cost is the traditional management ideas of predictability that can be measured in numbers. Business leaders want predictability. They want to know exactly what will be delivered and exactly when.

The problem is, in today’s world, building software doesn’t work that way. The bigger an organisation is, the more complicated it gets to figure out the business needs. Most of the time, those loosely defined, unverified needs are shared with a development team to estimate and deliver within a certain period of time. Because of the business’s archaic need of predictability, the development teams end up being held to ransom by their estimates. This shifts the focus from delivering value to delivering a version of value that justifies the estimates.

Now this may work really well for the ‘predictability’ but does it help deliver value to the business/customers? What defines the success of your product/service? If it is the predictability of the #of features that can be delivered within a quarter, then you’d be most happy with this setup. But we all know it’s not true. Won’t it be a better idea instead to encourage and incentivise your development teams to work on a set of problems and identify solutions? If your business/product is struggling to get more customers, getting perfect estimates from your development teams is not going to resolve that.

When I hear the word perfect, I can only think of the Taj Mahal. Taj was built in the 1650s by the Mughal emperor Shah Jahan in memory of his wife Mumtaz. I don’t think I can say anything about the beauty of the Taj that has not been said before. The proportions, the carvings, the stop-you-in-your-tracks magnificence, there is really nothing else in the world like it and it really is perfect. Shah Jahan wanted something perfect to honour the memory of his wife so he built the Taj over a period of 40 years, bankrupting his treasury in-process and eventually losing control of his empire. His obsession with chasing the perfect resulted in him being dethroned and imprisoned by his own son. Oh, and by the way, he still couldn’t finish the building to his desire.

We don’t have the luxury of time and resources of a medieval Mughal emperor and quite frankly we can’t bear to pay the prices that he paid. So why not learn from the history and please stop chasing the perfect?

--

--

Surbhi Bhati

My ability to see different perspectives is my biggest strength and weakness. I work in software development and like to talk about it among other things.