We had an issue in a new environment we were building out. For some reason branded images were not being found on one of the websites. At one time there were 6 developers focusing on this one problem for about a couple hours with no results (that’s 12 hours of effort). How would we estimate this beforehand? How would we account for those lost 12 hours, because they are not in the estimate? Those 12 hours have to come from somewhere.

I have been involved in hundreds of planning and estimation sessions. Some resulted in dead on estimates, but most were over or under. Projects ended up with nothing to do near the end or skimping on quality and increasing technical debt to meet the estimated deadline. Estimates are contextual. They can change every moment we understand something new about context. What we know regardless of context is that we want to deliver value to our customers. We want to deliver and maintain a quality product. We want to deliver often.

The business management wants to make sure the cost to deliver does not exceed the return on the value we deliver. Business wants to deliver to generate revenue and manage costs to increase profits. I am not a business major so I may have a naïve simplistic view, but this is what I have experienced. Business wants to control costs so they ask for estimates. When a project is delivered over the estimate people get upset. So how do we provide the business with what they need while not relying on our inability as humans to predict the future.

The lean or agile practitioners give some clues to what is a viable solution.

• Break down deliverables into bite sized pieces. Bite sized meaning what ever makes sense for your team.
• Provide an estimate on each piece based on current understanding of the context. Take no more than 10-15 minutes doing an estimate on each piece. You can use hours, days, team weeks, story points…doesn’t matter how hard you try you can’t accurately predict the future 100% of the time.
• Deliver in small iterations. You can commit to delivering a set number of pieces per iteration with floating release date. You can commit to a release date and deliver the pieces you have ready on the release date.
• At the end of each iteration re-estimate the pieces in the back log and break down new deliverables to replace the ones that have been promoted to an iteration.

What does this mean for the business? They still get their estimates from the mystic developers and their sprint tarot card readings, but the business has to understand that adjustments will be made iteratively to those estimates to match the reality we live in. The business has to be willing to loose an investment in a first iteration. If developers promise a working product at the end of the iteration, the product should be worth the investment. If developers don’t deliver, the business can opt not to continue based on the re-estimate or be willing to loose until they get a something shippable. First iteration deliver a working prototype, demo it to the business, get their feedback, adjust scope, and re-estimate what it will take to deliver the next iterations based on current understanding of the context.

If you believe that developers can give perfect estimates and deadlines, I have a bridge you can buy for a steal.

If the business needs to forecast the future, deliver in small, fast, continuous increments. This builds predictability in the system with increasing level of probability, until the system changes and the cycle starts again.

In the end, estimates are bullshit! 

What do you think?