To Estimate or Not, that is the Question?

One popular debate today is whether estimating is worth the effort. To those experienced with Scrum, this question seems silly, how can you prioritize the Product Backlog, or identify what can fit in a Sprint, without an estimate? Aren't you just rolling the dice if you don't estimate?

This is actually a misunderstanding. If you apply kanban without fixed iterations, the focus is not on how big an effort is, but when it will be complete. As such, instead of estimating size, kanban estimates cycle time, which, in the end, is still an estimate.

The common example given is joining a line. Do you care how long (i.e. big) the line is, or do you care how long you will have to wait (i.e. the cycle time)?

The Corey Ladas Take

Corey Ladas explains the latter view in a posting on his blog, a portion of which is quoted below. I added the boldface to the last sentence:

"Rather than go through the trouble of estimating a scope of work for every iteration, just make the backlog a fixed size that will occasionally run to zero before the planning interval ends. That’s a simple calculation. It’s just the average number of things released per iteration, which in turn is just a multiple of average cycle time. So if you have 5 things in process, on average, and it takes 5 days to complete something, on average, then you’ll finish 1 thing per day, on average. If your iteration interval is two work weeks, or 10 work days, then the iteration backlog should be 10. You can add one or two for padding if you worry about running out. This might be a point that’s been lost on the Scrum community: it’s never necessary to estimate the particular sizes of things in the backlog. It’s only necessary to estimate the average size of things in the backlog."

Now, since I took the quote out of context, you may want to read his entire blog posting, or attend his upcoming class on June 11th in Atlanta, to find out more.

The Cases for and Against Estimating

Many reasons are cited against creating estimates; just a few are listed:

• The estimates are never accurate, so they don’t add value.
• Even if the estimates are relatively accurate, we know we have to do the work, so why waste the time.
• The process of creating an estimate creates resentment when everyone is forced to chime in, and reach consensus, even when they don’t agree.
• The estimate itself causes people to modify their behavior in destructive ways, typically pressuring them to finish, causing low quality. In those instances where they are ahead, the estimate causes them to relax and waste time.

There are also many reasons cited for creating estimates, once again, just a few are listed:

• Determining business value depends upon an understanding of both return and cost, so you can’t determine value unless you estimate effort.
• You can’t plan a Sprint without estimates, or, if you are doing waterfall, you can’t build your schedule without estimates.
• Without estimates the team will lack discipline and will waste large blocks of time, potentially overbuilding a simple feature.

Simple Scenarios

As with most questions in respect to process, the answer is, “it depends”. But, here are some extreme examples to guide the decision on whether or not to estimate.

If you are fixing bugs in a mission critical system, and these bugs are prioritized by severity, and all high severity bugs must be fixed, then it is clear that estimating adds little value. Simply work on the highest priority bugs, and get the fixes released as quickly as possible.

On the other hand, if you are working on new development, or adding a large new feature set, and you must present a complete business case, including expected return and cost, then you will need to create some form of estimates.

Guidance for the Rest of Us

If you are somewhere in the middle of these two extremes, you need further help in deciding how to proceed.

• Remember the difference between size and effort. When you are estimating features, you are estimating size, so use a relative point scale and let the velocity calculation convert size to time. When you are estimating tasks, use an absolute measure like hours/days to represent the time required to complete a task.


• Create your estimates quickly and don’t get paralyzed by precision. Being quick may be the middle ground between estimating and not estimating.


• If you don’t have enough confidence to estimate, don't! Either execute a research spike to find out more, or simply delay creating an estimate until work on related stories or tasks give you an increased level of confidence.

• If technical uncertainty is high, and you must proceed now, allocate instead of estimate. With an allocation the business can limit the maximum effort and the team can monitor real world progress to cut short efforts that won't be finished in the time allocated.
  

• Use either a simple estimation scale, like T-Shirt sizes (S, M, L, XL), or a more complex scale that has increasingly larger gaps. Doubles (2, 4, 8, 16, 32) and fibonacci sequences (1, 2, 3, 5, 8, 13, 21) are both examples of scales with increasingly larger gaps that demonstrate that uncertainly increases along with size.


• Adjust estimates based on actual experience. The counterpoint to this is to bury your head in the sand.
  


• Involve the Product Owner and the business at large.
  • Although it should go without saying, the Product Owner should be deeply involved in the estimation process, providing insight and guidance.
  • The Product Owner should also be involved in the daily stand up meetings where progress is discussed so that he/she can gain an appreciation for the uncertainty inherent in the estimation process.
  • The Product Owner and the ScrumMaster should continually remind the business community at large about the limitations inherent in the estimation process.
  
  
• Most importantly, focus on the journey, not the destination. Sounds abstract, but instead of worrying about the exact estimate (is it 5 Story Points or 8), focus on why people vary on their opinions so that you can better understand the story and the work that will need to be done to deliver it. If you engage the whole team in the estimation process the context gained from can be more valuable than the estimate itself.

In Closing

I estimate that at least 10% of the people reading this post would find it useful, so please send an email or comment on the post so I can see how accurate my estimate was.