The question often put before Lean-Agile coaches or consultants is – what does Lean-Agile say about Estimation? Good, bad… or ugly?
In general, the Lean-Agile community is negative about Estimation. Martin Fowler said: “Estimation is neither good nor bad.” Ron Jeffries said “Estimation is Evil.” Two months later he corrected himself: “Estimation is a necessary evil.” IMHO, Ron’s view is very charitable. I will explain later why! Before that, let us also understand how Lean thinking views Estimation.
Image Courtesy: Jonathan Rasmusson (agilenutshell.com)
Lean thinking tells us that any activity that does not add value to the final product is non-value. Non-value activities need to be gradually reduced and eventually, eliminated, through Continuous Improvement initiatives. So, does your user care whether a feature will take 2 days or 20 days? Do they care whether you size it as 2 Points or 20 Points? If your answer is negative (and at least, my user does not give a damn!), then you have the answer – Estimation is Waste (Muda) and any time spent on estimation should be reduced over time.
Is it necessary?
In some instances, yes. Some level of estimation might be needed for planning human and financial capital. So, the intent should be – do estimation but spend as little time/effort as possible to meet your objective.
One argument I have heard is – would the end user not be interested in the cost of building that Feature? Usually, it is an IT concern – not of the end user. Even if they are, an order of magnitude would suffice. T-shirt sizing is adequate for the purpose. For example, from your past data, you could conclude that a small Feature will cost $10000, a Medium Feature will cost $25000, a Large Feature will cost $50000, etc. Anything more accurate is not needed – it will have so many assumptions that it’s sanctity for planning will always be a suspect.
Estimation is also the root cause of many problems. No matter how many caveats you put, an Estimation given is generally viewed as a Commitment. If you cannot deliver within the estimate, you would be asked – “What happened – didn’t you estimate this?” Your credibility will be at stake! So, the reaction of the developer is to bump up the estimate. The Manager then bumps up that estimate. The Group Head then bumps up that estimate… by the time it reaches the Business, it’s perhaps 2-3 times of the original estimate. Then, the reverse cycle starts! Business questions the credibility of such an inflated number and then, the countless hours of negotiation to bring down the estimate starts. It leaves a bad taste with everyone in the process.
Last but not the least, quite often, the person who is going to build the Feature is asked to deliver based on someone else’s estimate. This whole process lacks trust and generates frustration between both IT and business. Development teams feel business does not appreciate their concerns. Business feels that they are not getting reasonable/fair estimates.
So, how do we plan without an Estimate?
The answer lies in Throughput/ Velocity based planning. A lower level maturity would be to do Story Point based Throughput/ Velocity tracking. A higher level maturity would be Throughput/ Velocity planning based on count of Stories. That would remove even Story Point estimation and take away all ambiguity.
A follow-up question is: how do we handle the complexity of the User Story? All Stories are not of the same size! Thankfully, this problem isn’t a big one if you follow Agile Requirements. Applying INVEST criteria helps define small, independent and testable stories. Guidance (not a rule and sometimes, not possible) is that DCUT – Design, Coding and Unit Testing – should be less than 40hrs. Further, every Sprint has a distribution of User Stories of different size. On a long term basis, if you plan based on Throughput/Velocity, this averages out.
In summary, I hope this blog helps you appreciate why you need to gradually move away from Estimation. If you do Kanban, just because it is evolutionary and it says that you start with what you are doing today, does not mean that you would not seek out ways to reduce all identifiable sources of waste. The journey of Lean-Agile adoption will always be about how to keep continuously improving.
