No Estimation in Small And Large Scale Agile Projects

Agile focuses on delivering value. Do estimates add some value in delivering project? So do we really need the estimates? Ron Jeffries, one of the founders of the Extreme Programming (XP), recommends not estimating all the user stories, be it in points or hours, in his recent blog on Thoughts on Estimation.

Known benefit of small-scale estimate is that it causes the developers to better understand user stories, resulting in better implementations, fewer mistakes, and so on. It is because of the conversation happens while estimation. ? Ron Jeffries said that it's not clear that estimates are an ideal way to do that.

David Lowe, Agile Coach at ustwo, in his blog mentioned that:

Using estimates to decide if we understand work is okay, but surely there’s a better way to get to that place. Shouldn’t we be striving towards that?

Olga Kouzina, in her blog on Why Agile Estimates Don’t Work, mentioned about the situations where estimation is not valuable.

Teams and companies start playing around and messing with estimate rituals when they have some extra fat to burn. There’s no room for activities that are waste in a bootstrapped, mission-oriented, do-or-die start-up squad of several people. If you are in such a team, and tempted to start a planning poker session, don’t do this. Rather than waste your time on playing with probabilities, get some real work done.

David said that teams should focus more on value instead of estimation.

Agile and estimates don’t actually sit well together. Agile encourages you to deliver value regularly and in small chunks. Deliver early and often. Collaboration and regular evaluation helps us make decisions based on working software (allowing the right path to emerge as we progress). We are encouraged to accept change willingly and benefit from our learning. Shouldn’t the starting point be to decide what will deliver the most value?

Ron Jeffries, explained value is what you want. Maybe you want revenue. Maybe your product saves lives. Maybe it organizes meetings. Whatever the point of your product is, it is almost certainly not "let's make our actual match our estimates".

Management comments that estimates are required because customer demands estimate. In this case David recommends educating customers on the benefits of agile. With agile, your customers will get more of what they want, on a regular basis, for as little money as possible.

Ron Jeffries said that in large scale projects budgeting is more important than estimation.

At the overall project level, I favour a quick estimate if you must, and prefer a budget. Not a multi-million dollar ten year budget but a week, a month, maybe three months for a small team to get a real handle on what the product is and how long it will take until we can have something of use. We build high-value items first, and continue that so long as the product shows itself to be worth investing in.