Answers on Ron Jeffries' Thoughts on estimation
Ron Jeffries wrote a great article sharing his thoughts on estimation. I agree on his thoughts and shared some of my experience with him. Our team got rid of most estimations for over a year now. And we'll never go back.
Ron asks in his article to answer some questions about estimation and I replied with the following answers.
Where have small-scale estimates actually been useful to your team?
I'm the product owner of knowNow, a social knowledge management platform. We only use small-scale estimate for high risk proof-of-concepts. Maybe this sounds as a contradiction, to estimate for an uncertain period. We rank other features by customer value. Just like you wrote in your article. For me as a Product owner it's easy to determine the priority and to track value. But for technical opportunities, new tools and high risk features, it's harder to rely on just common sense. In such cases we try to breakdown the proof-of-concept in the smallest parts possible. Each part should give a result which we can validate on value, risk and better understanding of the amount of work still needed. The first part get a small-scaled estimate. This stimulates design thinking and extremely scoping the proof-of-concept. Based on this estimate, I can decide if we're going to do the experiment and if so when.
We did a limited number of these estimates last year and about 3 out of 8 gave me a reason to skip or delay the experiment. When we start the experiment it will be like a regular task and starts with a budget. Based on the progress and the results we can decide to continue or stop the experiment.
What have you done to get rid of estimates if you found them troublesome?
After repeatedly failed to meet sprint estimates, we just skipped them. Sprint reviews left the team disappointed most of the times, because estimates were not met. I, as the product owner, was quite happy most of the time. We did not meet estimates, but delivered enough customer value. Sprint plans got disrupted all the time due to bug fixes, weird problems or other unforeseen activities. With every sprint we spend a lot of effort in improving estimates, without significant results. Even worse, the team focused merely on meeting estimates than on creating customer value. Instead of getting more control we lost sight of the most important part: creating customer value.
The moment I realized this problem, we skipped the estimates for good. The sprint is like a budget, the priority of backlog items is clear and the team is highly motivated. For me it's a myth that better estimates makes people more productive. Everyone is giving their best and knows which features to develop.
Instead of estimates we put our effort in breaking down features in very, very small deliverable features. These features are straightforward, easy to understand and relatively simple. We do not need estimates for these features. The time we are saving with not estimating the sprint is spend on measuring customer value. By releasing small (sub)features, we stop developing on the feature as soon as it stops adding customer value.
At first we were afraid to lose discussion over the features if we didn't estimate them. And what if we run into trouble during development? What if it takes too long? What is too long? The answer is simple: communicate. We agreed that the team contacts me as soon as something disturbs developement. When a feature stops being straightforward, easy to understand or stops being simple. But what are the boundaries of easy, simple, too long, etc? Just by starting this communication it's calibrated soon.
We're skipping estimates for more than a year. And I can say we increased productivity, team motivation, quality and customer value.