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!