10 Pines Blog
When someone asks for an estimate I always think of this.
#NoEstimates pic.twitter.com/siZsVxs3D4
— Aaron Griffith (@Aaron_Griffith) March 14, 2014It’s not like estimations are like this, right? This post is a trigger to rethink estimations. To rethink why we do them, how much do we invest on them, what is their ROI. Should we estimate or not? If you think why you estimate in real life, you wouldn’t think there could be something dangerous about them. We all estimate how much it would take us to get to the bus station before going, right?. However, things get much more complicated in software projects and in organizations.
Here’s a few problems I’ve seen lately that may turn estimations into dangerous, deceiving practices and could deviate them from their original purposes:
This means using a story point that is converted to a number of hours (e.g. 4 or 8 hs). You estimate then using these ‘story points’. But are they really story points? I think they aren’t, they are just a broader unit than the hour to perform time estimations. Let’s dig a bit further into the concept of story point. A story point is a relative measure of effort. The idea is really simple. If I have Task A estimated in 1 point and we think Task B would take double the time, we put 2 points to Task B. We don’t know how long it will take A, but we know B would take double the time. Is that simple. The story point is an abstract concept because it amalgamates a few different factors in one, such as the effort, the uncertainty, the risk, etc into a number, the story point. But the most important thing is that this number is relative, it doesn’t represent anything per se. It represents something when compared to the other estimated stories in the same backlog. The rationale behind this way of estimating is that “Humans are actually better at relative estimates, than precise measurements”.
With this relative measurements, the team’s velocity can be calculated over the first few iterations and with this velocity, a more precise schedule can be constructed. The only pre-requisite for it to work is that these estimates are consistent among them. As Mike Cohn says in his “Agile Estimating and Planning” book, velocity is the great equalizer.
{% blockquote %} Velocity Is The Great Equalizer What’s happened here is that velocity is the great equalizer. Because the estimate for each feature is made relative to the estimates for other features, it does not matter if our estimates are correct, a little incorrect, or a lot incorrect. What matters is that they are consistent. We cannot simply roll a die and assign that number as the estimate to a feature. However, as long as we are consistent with our estimates, measuring velocity over the first few iterations will allow us to hone in on a reliable schedule. {% endblockquote %}
But this work for story points that are relative. I am a bit eery of using the same name to identify something that is different in nature because is basically another measure of time. If velocity is measured, it needs to be clear that we are relativizing these numbers, we are converting them into this abstract number which is the story point. A practice that I have been using pretty successfully for a few years is that of relativizing estimations during the progress of the project. Teams that are used to estimate releases in days, they could do so. However, when I measure the velocity, I measure how many of these ‘points’ the team is able to complete (averaging them over the sprints). Same with the sprints estimations. If the team estimates all its tasks in hours, they could keep doing it but measure the actual number they are able to complete and use this number as yesterday’s weather.
When should we re-estimate? In short, re-estimation should only occur when we are certain we gained knowledge about the effort to come. We re-estimate because we understand better what lays ahead. Consider you are working on a Sprint and you realize the story you are working on is bigger than what you originally thought it was. Should you re-estimate it? Let’s look at a couple of examples (from real life!) before answering the question.
Let me tell you something that I’ve seen many times (simplifying the numbers to make it simple): We had a backlog of 100 story points and we committed to deliver 10 story points in the iteration (the projection was we were going to need 10 sprints to finish). Of course things went awfully bad during the iteration and we were able to finish just half of what we committed to, 5 points. Thinking about the reasons, we came to the conclusion that these stories that we completed were much larger that what we originally thought (of course we found things we didn’t foresee. It always happens) and therefore we re-estimated them (the stories we completed) to be 2 times bigger. After this re-estimation, the numbers showed that:
What is the problem with this? We did it without thinking carefully about the remaining stories. In hindsight, we cheated ourselves into believing that these stories were bigger than others we estimated in the same size and therefore we needed, at most, one extra sprint to finish. Of course, this wasn’t true. Most stories that came afterwards contained unforeseen things as well and the number of sprints required to finish was closer to 20, not 11. In other words, our velocity was near 5, not 10 in the first place and we shouldn’t have done any re-estimation at all.
The last story was using story points, but I’ve had my experiences with hours as well. Let me tell you this (imaginary) one: we included 10 20hr stories in our sprint (200 hrs of a total backlog of 2000 hrs). We started working and realized the first stories were bigger than what we thought they were going to be. Twice as big. We re-estimated them in 40hrs instead and we completed 5 stories. So we ‘burned’ 200 hrs out of 2100 hrs. Wait wait.. We burned 200 hrs? And we worked 200 hrs? We knew we were going to work 200 hrs. before starting the sprint anyway, right? But did we get any insight about the remaining work?
Has any of this happened to you? I believe we fall too often into the trap of believing that what we have just completed is bigger than estimated and what lays ahead will not. We, generally, are optimists. Or we just re-estimate without caring about the rest of the backlog. This is a real mistake. So the question is: when should you re-estimate? I believe that you should re-estimate when you are sure you understand how the current work impacted the remaining one. In other words, if you are certain that the feature you built is double than others with the same size, do it. When in doubt, don’t re-estimate. Let the iterations flow. Measure and average your velocity (velocity is the great equalizer, remember?).
Collaboration over contract negotiation. It’s among the 4 agile values. We all know collaboration between the business and the team is of paramount importance in agile development. It doesn’t work without it. We all know that estimations are just another criteria that helps the business prioritize and build plans. We all know as well that estimations are just that… estimations. They can be wrong (the error will be bigger as uncertainty is bigger). People that do plans are used (or they should) to make them with this in mind, playing with probabilities and statistics. So why do so many people try to treat them as commitments? Treating estimations as commitments could trigger a myriad of dysfunctional behaviors that could kill collaboration very easily. Padding estimations to be on the ‘safe side’.. Or ‘refactoring some code, since we are below the estimate and there is time..’. Or the worst of all. The development team unwilling to change things because they will go over their estimations. Those examples are the result of lack of trust & collaboration. And these innocent estimates could be the culprit.
So how should we treat estimations? We should treat them as that, estimations. The development team does estimations as good as they can. Business understands estimations are made with uncertainty and have error margins. The objetive after all is creating value, as a collaborating team and estimations are just another tool that helps us deliver better value.
So please, please: Don’t ever ever treat estimations as commitments!!
Imagine you want to buy a laptop, and you aren’t sure whether to buy the top of the line apple mac book pro or the Dell one that seems to have the same features at a cheaper price. Apple is $2000 and the Dell is $1500. As you aren’t sure if the Mac is worth those $500, you hire a consultant who charges you $500 to give you a consultancy report. There you go! The report says you should buy a Dell. And you just spent $2000!! :P This is really silly, but believe me, it happens much more than we think. Yeah, sometimes we spend more time/money estimating a feature than actually coding it. This happens without us realizing, disguised in endless meetings with many programmers discussing how to implement a tiny bit of functionality (perhaps a couple of guys discussing and the rest looking/sleeping/etc). Just think about this: Imagine there’s a small story, around a day long, and 10 guys estimating it with planning poker. How much does this estimation cost? With a few minutes, it could be near the cost of building it. So always bear in mind how much time you are spending (actually investing) estimating and make sure it’s worthy!! If there’s a lot of people in the room and the story that is about to be estimated is small and doesn’t have much importance, don’t worry that much about it! You think is about a day. Fine. Don’t waste time trying to figure out if it will be 6 hrs or 10 hrs! Invest your money where it’s worth!
There is an interesting wave of thinking that proposes dropping estimations completely (#NoEstimates), focusing on delivering the most important features quickly and measuring the cycle time. If the team knows it’s capacity is to deliver X features weekly, there’s no need to perform any estimations (even better if those X features can be deployed to production). Estimating is waste, after all. It doesn’t add any value to the product. Working this way fits perfectly in pull processes and leads to leaner ways of managing the backlog and a more mature way of working. This fits perfectly in projects with a lot of churn as well. Why trying to predict what is going to happen in 2 months if we can’t predict what will happen in 2 weeks? Probably is better to select the most important features, implement them and then ask again the same question as suggested in this post. After all, “the ideal work planning process should always provide the development team with best thing to work on next, no more and no less. Further planning beyond this does not add value and is therefore waste.”.
To conclude, here’s just a few advices you need to bear in mind when performing estimations:
And finally. Something you should do for every practice and tool you use in your methodology. Evaluate if it’s working. Retrospect. Ask yourself what is the value it is providing and try to improve!.
21 Mar 2014