#NoEstimates

At my current project we have been doing the standard thing of going to planning sessions and estimating with using planning poker. As of late the project has been running full steam ahead to achieve a tight goal that we have. In doing this, we have been so focused on getting the end goal achieved and that we have ignored the estimates, and to be frank I haven't missed them, which lead me to actually question their value.

Epic Fail

As humans we are usually fail miserably when it comes to estimation, and when you really think about it, it really is just a guess. Even an educated or informed guess is still a guess at the end of the day. If you take a step back and look at it, what we are actually doing is playing guessing games with large sums of companies money and the value that estimates provide are almost negligible, as they are almost always wrong. If this is the case, and we are on a path of eliminating waste, then surely estimates would be a candidate to eliminate?

A Better Approach?

If you look at the broad picture, estimates don't provide any business value, working software does. I have seen this story played out countless of times, where the estimate was missed due to various factors that we didn't know about or weren't accounted for. In almost all cases, estimates are taken as the absolute answer, even if you tell people that it will most probably change. That estimate date becomes solidified and concrete in peoples mind.

So how do we go about without any estimates? I recently heard an analogy that I resonated with me quite a bit. The way that we currently do estimates is like the farmers almanac, which tries to predict the weather a year and a half in advance, so that farmers know when to plant crops etc. However, past analysis of this has shown that it is no more effective than flipping a coin randomly. Instead, a better approach would be to get real-time information via a Doppler radar, which provides real-time information of what is happening. By using this up-to-date information, you can learn and update your forecast as you go.

The same process could be applied to software development, whereby we keep a pulse on the project in real-time and inform the business about any changes as they happen. Essentially, we can see how our prospects look, as new information surfaces, in real-time.

What About Planning?

If we don't estimate, is there really a need for the planning session to take place where we estimate the work? The short answer is yes. Instead of doing the typical planning, what you would do is break down the tasks into small batches of work that are around 1 to 3 days each. From what I have seen, people find it easier to estimate work in days as opposed to story points, so this should make it easier for the team. This doesn't mean that you don't discuss the work as a team and everyone provides input into what the task at hand involves. That is still valuable in itself.

One thing to note is that a cumulative flow diagram is very useful in tracking the stories as they progress through the various states in the workflow.

What About Business?

You may run into the scenario where business has some projects that they want to be estimated so that can decide which one is the most viable. In this circumstance, the better approach would be is to identify 2-3 that they think will be the best and as quick as possible validate which one actually works. The leads to validated learning, where the business makes decisions based on actual findings, and what users want, as opposed to which one would be the cheapest, as if you optimize for cost you typically have mediocre results. At the end of the day, you don't know if anything will work out until you experiment and try it out. You could be saving the business millions of dollars by just trying something out and validating your assumptions as opposed to developing a full blown solution.

To put my cards on the table here, I am no expert in this and I have never tried this before, but I do plan to try it out once we have got through this tight goal to see how it works for both the business and the team. Let's experiment and see how it goes.

Until next time...keep learning.