What's wrong with this picture?

This chart is the task hours estimate remaining for the sprint for the team I am working on. This has been a consistent trend, despite attempts to curb adding stories to the sprint backlog.

There are several factors that contribute to charts like this. If you begin to notice these kinds of trends, here are some things to look for.

• Outside Influences / Randomizations
• Team members are working on things that are not on the backlog
• Unplanned things (fire-drills, ad-hoc customer support, management asking for "emergency" things)

These kinds of things can be mitigated with a strong scrum master, who is empowered to negotiate with outside influences. Sometimes issues come up that require team resources to complete them, this is just the nature of the business in some cases. However, for unplanned work, we do two things. First, we plan a buffer of time in sprint planning that we assign to these kinds of things. It is encouraged to limit this buffer to a specific period of time, and should be treated as a spike. Second, we ADD all tasks that were actually worked on, so that we have visibility to the actual work that got done.

• Under-estimation

Many times, there is simply no interest in digging into the nitty-gritty of the tasks during sprint planning. If each story is clearly understood by the team, the entire team should spend some time tasking out each story in sprint planning. I have seen teams that don't put in enough effort to the planning session. When tasks are better understood in planning, they allow for much better estimation. The "we'll figure it out later" attitude simply doesn't work in this kind of environment. It works much better to spend the time in sprint planning to understand fully what all the tasks are for each story. At least task breakdown should be done in sprint planning, and estimation as well if possible.

• Lack of testing

Un-tested (speaking of unit-testing now) code typically takes longer to get working. Code that is developed within a unit-testing framework (whether or not TDD is used) tends to function better, and requires less "try-it and fix-it" cycles. Unit testing the code does take more time than just writing the code alone, however there are so many benefits and reductions in the amount of time spent on rework and accuracy assurance, that it is usually an easy sell even in an organization that has a heavy work load.


If you see this kind of chart appear in your organization, take it as a yellow flag warning sign, and try to employ these tactics above to improve the estimation process. Don't let your burn-down BURN UP your team!

After some training in the estimation technique of Wideband Delphi, I have tried it out in a real project/team environment. I think it was an interesting result, but as a single data point so far, I would hesitate to assess the tool as a success or failure. I will be curious to see how the estimate tracks to actuals for the feature... The use of Wideband Delphi in the initial stages of a project may be a good tool for rough sizing of features or whole feature areas. I am a bit leery of assigning "hours" [ideal hours] to estimates at this very high level of granularity though. Sometimes hours find their way to get turned in to schedules... and ideal hours are even more dangerous as they aren't fully loaded.

The cone of uncertainty is a nice principle that I think might perhaps need more airtime. (Not being a project manager, its a new one on me...) It states that at the beginning of a project, when the least is known, the estimation error can vary from .25X to 4X (not sure where these numbers came from). And as we move toward project completion, the estimation curve shrinks on both sides exponentially to approach 1 at project completion. For more information see the cone of uncertainty link.

However, as the "cone" narrows and we are a bit more certain of what it is we need to deliver, I still think the planning poker type of consensus estimation is more appropriate. It seems a bit lighter weight and much quicker for estimation. Granted, however that planning poker is a tool to be used at the story level (and estimates in points NOT hours), it might not do as well as the WD estimation at earlier stages. It is a similar process, but seems to be a faster implementation.

WD could be a useful tool for backlog prioritization and even perhaps story generation. I am not sure how valuable estimates from WD might be other than to help prioritize (in size and cost) less-well-known things in the product backlog. I still think that the planning poker is appropriate at the sprint and story level though, rather than WD. Another thing that strikes me as different is that WD doesn't necessarily engage the whole team doing the work - only "experts." I like to have the entire team exposed to the information and the planning, even if team members don't have much value to add to estimation at that phase. In my opinion, it helps with information sharing, project background, and overall depth of understanding.

Use the right tool for the right job I always say. I carry four screwdrivers in my toolbelt, two sizes of flat blades, and two sizes of phillips... Use a tool for its intended purpose. Watch out for trying to get too much out of estimation at an early phase, and definitely involve the team - they are going to be the ones who help the project actually come to fruition.