The Attitude of Estimation
Over the past three or four blog posts, I tried to challenge our thinking on estimation by sharing some specific ideas on why padding an estimate is evil or how a SWAG can actually be fairly accurate.
Now I want to take a step back and share the biggest obstacle any organization has to getting consistent estimates. By that I mean estimates that drive confidence for the team and it’s stakeholders. That obstacle is our attitude towards estimates.
To clearly share what I mean by our attitude, let me share a typical estimation experience:
Experiencing the Attitudes of Estimation…
I am working with a new team and walking them through some standard use cases or agile stories. I present the first feature, the team evaluates it, and give me their initial estimates.
One person on our team, let’s call her Ann, quickly throws out “This should be about two days”. Another senior member of the team, let’s call him Jerry, says: “I can’t imagine that taking more than a couple of hours”.
I ask Ann, “Why do you think this is two days”? She responds: “Well if I say a day and there are defects etc, it’s going to take longer. The truth is I don’t know whether this is one day or three days – but this is only an estimate. No matter what I say it’s going to be off, and you’ll be unhappy”.
After defending myself and saying “That’s not true, yada yada yada”, I then turn to Jerry asking why he thinks this is only a couple of hours. He responds, “How hard can this one be? It’s a straight forward screen. I just have to get a new table built with the reference codes and we are good to go. I don’t see any challenges”.
One of Jerry’s teammates asks: “Isn’t it going to take some time to download the reference codes, clean them up and get them in the table? And shouldn’t we create some quick automated tests to make sure this works?” Jerry pauses and says: “Well I guess. If you want to include all that then I need a full half day”.
Finally Ann jumps in and shares: “If you ask me, I think you should estimate a full day. We’re going to need the QA team to sign off and by the time you do any adjustments, it might take you all day”.
Jerry doesn’t necessarily agree, but the team agrees it’s better to be safe then be sorry.
Why These Attitudes Make Sense…
I regularly find both attitudes on the same team across companies, sectors and experience levels. I understand both approaches. I can defend them!
Ann is right. No matter what we estimate, it’s going to be wrong. That is why we are estimating and not “predicting”. In fact, I’d even argue “weather forecasting” should be called “weather estimating”. Forecasting suggests we are truly predicting. Estimation suggests based on what we know and the models we are using, here is our best guess.
And Jerry also isn’t wrong in saying he knows that it will take two hours. He genuinely believes for the feature at hand, he can get this out quickly. However, the team quickly reminds him that there are other “tasks” and “team members” that need to be included in his estimate.
Commitment Based Estimates
Having different attitudes and approaches to estimation is a clear obstacle to getting consistent estimates that can be managed and adjusted. To remove this obstacle, I suggest having a standard approach or attitude to estimation. I call this approach: Commitment Based Estimates.
When asking for estimates, I want the team to understand, I am not asking for the smallest, leanest, quickest estimate for each task. If I did, this optimistic plan would simply be impossible to deliver on. It won’t take one small thing into account: LIFE.
I also don’t want them to pad estimates and not be realistic.
So I ask them to think about it from the point of view of “commitments”. When can you commit that this feature will be “done/done/done”? When do you believe it will be ready for deployment to our integration test environment?
I then clarify: That means you have to take into consideration any “clarification” of requirements, obtaining resources such as a tables, test data, web services, tools, conversion scripts, documentation and so forth. It also means you have done your testing and are comfortable that this actually works. You are proud of the result.
In our previous example, the team compromised and said this would take a full day to finish our feature. I might test this by asking the team: “Would you bet your paycheck on this? In other words, are you truly committing to that one day estimate”?
In the real word, if we are working on something that we said takes a day, and it ends up taking an extra 45 minutes, we would typically do what it takes to get it done on schedule. That is the nature of development teams. We truly want to deliver on expectations if “we own them”.
I could write another page or two on Commitment Based Estimation, but I won’t (yay)! I will leave you with these other thoughts:
- Never force an estimate on the team. If you are doing Commitment Based Estimation, the team needs to feel full ownership for the creation and development of their commitment.
- I highly recommend all estimates be in ½ day increments. More specifically, NOT in hours. If I say I am going to be done in 6.5 hours, am I actually going to get another .5 or 1.5 hours worth of work on my next task done? Stick with ½ day, full day, three days or five days etc…
- If your estimate is longer than a week or so, I’d challenge the team to split the work into two tasks and estimate them separately. (There may be some exceptions to this one.)
The Goal: Consistency
Regardless of whether you agree with Commitment Based Estimates, it’s important to get the team to have a common attitude to estimating as much as a common approach. I hope you give Commitment Based Estimating a try. I have found a great deal of success with it.
I’d be very interested in hearing your experiences with “attitudes” towards estimation and why you believe this approach will or will not work with your team. Please leave your comments below!
As always, please feel free to share this post with anyone you think might benefit.
Category: Defining Success, For Practitioners, Team Performance
Nice article. I typically say that estimation has two purposes, to spark conversation and to give us forecasting tool. However, estimates are only estimates…. some are going to be low and some are going to be high. We get better at them the more we do. Consequently, estimates should not be used for measuring the team…. only what is produced counts.
Question: I understand the half day measure. It’s comfortable. But why not use Story Points for relative size? Ultimately, Story Points are more flexible and tend to remove some of the angst about getting them right, since a story point can’t be measured definitively by the clock.
Karen,
Great question (about Story points). I believe the 1/2 day measure is just another flavor. I’ll explain my thought. When I was Agile teams using Story Points, we used them to create comparative sizing of stories or features… Something that was 4 story points was twice as big as something that was 2 story points.
The way the team came up with that sizing was by thinking through something like “how many 1/2 days or full days would that feature take. It actually “reverse engineered” into story points.
I found that up front, it was easier for the team to work with these “1/2” day buckets to make the plan more real and get an estimate early on.
I hope this makes sense. Do you see a strong reason to move back to story points?
[…] we’ve introduced Commitment Based Estimation to a couple of our software teams. Typically, this helps a team provide highly-accurate […]