Estimates

There has been a lot of discussion in the agile community over the years around estimation. And it never seems to find a common agreeable approach. Points, Ideal Programming Days, Throughput, No Estimates etc.., I am not going to propose a universal solution as I do not believe at this time that there is one. But here go some thoughts on estimates.

I had originally planned on a large post about different types of estimation techniques ranging from Ideal Programming Days, Hours, Points, T-Shirt Sizes, and even No Estimates, and maybe I will do that in another post. But I decided for this one to keep it short.

STOP FOCUSING ON THE OUTPUTS AND START FOCUSING ON THE OUTCOMES.

The metrics of a team are not nearly as important as what the team produces. If the team is producing working tested software, early and often, that people use and don’t hate, then that is where the value is.

Having a team with a fully estimated Product Backlog doesn’t have the value we think it does. Does it allow us to “Estimate” how long it will take to complete the Product Backlog? Sure, it does that today, and maybe even for a single Sprint iteration or two. But once we start getting feedback on the product, then the Product Backlog changes. The Product Backlog will grow, and shrink, items will be re-prioritized, trashed, and the estimates on the PBI’s won’t be accurate over time.

I am going to address this in another post, but for a quick example, let’s say we have a PBI with an estimate of 3 on it. But it isn’t prioritized to be worked on for what looks to be 2-3 or more Sprints away. So the team builds out multiple other PBI’s before finally getting to that 3 point PBI. Well is it still 3 Points of effort based on what we have built over the last few Sprints? Is this PBI still needed? Has the story of this PBI changed? More times than not, one, if not all, of those answers are not what you expected. So how valuable was that estimate a few weeks ago. What if not only what we’ve built but also feedback we’ve received leading up to this PBI have made this PBI more complex and now the team says that 3 point PBI is actually closer to 8 or 13? No matter if you decide to split it up, or focus on it as a whole, the work still needs to be done, and the Sprint that 3 point PBI was going to be in, may now be the majority of the Sprint.

Estimates are troublesome due to how they are treated. People take an estimate of a large feature or project and use that as the guarantee. It isn’t. Stop doing that. But they won’t and probably never will.

The reality is that we will always be asked to provide estimates, so how do we do that better. We don’t focus on getting better at estimating, we focus on continuous delivery of small batches of work that people like and use.

Recently there was an email that went out congratulating a team for “On-Time Delivery” of functionality. Everyone was happy, except for a few people. They thought, “Wow, we don’t even know for certain how well this will work yet.” This is a prime example of a culture that rewards “More Faster” but reserves the right to be mad later if it doesn’t function as expected. This celebration of on-time delivery emphasizes the value of estimates and down plays the functionality of the product.

My point in all of this is, while estimating does provide metric data for velocity, cycle time, throughput, and even projected completion date, it should not be the focus of the team, and it only becomes the focus of the team when leadership puts greater emphasis on the reporting metrics then they do on the Outcomes and Impacts of the product.