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.
Subscribe to the RSS feed
9 comments:
Chalk one: I did find it useful.
I think estimates add some value to the product owner to decide which features should come first. They are like price tags for the features.
Having said that, I also try to caution our product owners that estimates are approximations, not promises.
Shameless plug: I've got a blog post here where I talk about some of these ideas
http://hectorcorrea.com/Blog/Estimates-on-Software-Projects.aspx
Hector,
I don't think there is anything wrong with shameless self promotion, as long as you announce it in advance :)
In respect to cautioning Product Owners that the estimates are approximations, we would both probably agree that the Product Owner should be deeply involved in both the estimation process, and daily stand ups where progress is reported, so that they can develop a rich understanding of the level of uncertainty associated with estimating.
The Product Owner and the ScrumMaster (or PM, or whatever name you use) also have the responsibility to educate the larger stakeholder community.
I decided to update the post to include my comments that were spurred by Hector's post, so thank you Hector for reminding me to mention how important the PO is in respect to the estimating process.
I think that's an excellent summary, and provides useful guidelines for just how much (if any) estimation is appropriate for your particular situation. To me, your final bullet is especially telling: that's why I tend to favor estimation.
Since I struggle with how much emphasis to put on estimation, your take on it was helpful.
My only quibble would be regarding high-priority bugs: even if you have to address them all eventually, you can consider the relative level of effort when scheduling them. If you have capacity to cover them all within an iteration, then you're right that the estimates don't really matter.
leftbrainrightmind,
Your point is well taken.
The assumption in the description was that all bugs must be addressed in priority order, which was an oversimplification.
In most real world situations there are other factors, such as clustering of bugs in specific areas of the codebase. In this case, addressing the segment of code which causes the most bugs is an effective approach, and estimates are less valuable unless you want to calculate velocity.
On the other hand, if the bugs are scattered throughout the code base, addressing high priority, easy bugs first, makes complete sense. In fact, assuming there is only a handful of high priority bugs, the easiest approach is to simply rank the high priority bugs in order (i.e. don’t assign any points or hours) and fix them, or use a simple point scheme if you want to be able to calculate velocity.
I think that not estimating is not practical and potentially foolish. I can't see that approach working in most business environments.
As a product owner, the number one question I was asked about a feature/bug is when? If you're far out enough, you might be able to nail it down to a calendar quarter or release, but as you get closer, the need for specificity increases. CEOs, customers, marketers, and sometimes end users all need to know these things.
And from a business perspective, I would want to know if something is worth fixing. What's the return on it? Averages are not a good predictor of specific future outcomes.
Some Kanban purists will tell you that estimating individual sizes is a waste, as you can calculate cycle time instead.
But, I think relative size estimates against user stories are valuable for a number of reasons, such as helping the team think through the issues they will face when they begin work.
Often times you can use these relative size estimates to calculate sprint velocity (assuming you can complete user stories in single Sprint).
If you track start date and end date (i.e. release ready) for a user story, you will also be able to measure cycle time based on size.
Perhaps you will find that it takes 7 days on average to deliver a user story of size one, 12 days on average to deliver a user story of size two, 16 days to deliver a three, etc.
This cycle time information is an especially useful measure when many user stories require more than one sprint to complete (i.e. when velocity works less well) and for many teams, cycle time is more valuable when calculated against relative size.
So, in the end, I agree that it is valuable to create relative size estimates.
I might need a little help here.
From what I've experienced, cycle time works best as a measure when you have similar sized (and hopefully small sized) stories. [Smaller stories also generally lead to faster feedback and a host of other benefits; so its a good team goal in its own right.]
If a team reaches a stage where all stories are broken down to a "small size" then what incremental value is there in knowing if it is a 1 or 3? Just call all of them 2's and use the time saved to deliver something. Or better yet, don't take the time to write "2" just call them either "right sized" or "still needs to be broken down".
There is a distribution of actual results which should be expected of any estimate anyway (we will always have unknowns and common cause variation). To say another way, be aware of the diminishing returns involved in trying to be more accurate.
I mentioned above about how stories don't always start at "small enough". In that case, you can still do rough estimates as appropriate. Just make your unit of measure "right sized stories". (As in "We think this feature is 8 right sized stories. Current cycle time is 4, so...")
If a feature is "8 stories" Product Owners still have a relative cost/duration vs. something that is "2 stories".
In other words maybe you don't "stop estimating". You just "estimate" by forcing a consistent batch size.
Mike,
I was writing another post on estimating so I checked this one out and saw your comment. I apologize for the delay of over a year in responding!
I think you and I are probably of the same mind. All things being equal life is easier when you can have the majority of your backlog equally, or at least approximately equal, sized.
The problem is that getting to approximately equal sized items may take considerable effort and result in chunks of work that are not coherent.
So, yes, if your team can make items equal sized backlog items, that are coherent, great, if not consider the use of traditional point based estimates even when you want to measure cycle time.
Post a Comment