Track Done

You want the Sprint Burndown Chart not to elevate false hopes of a successful Sprint.

… you have a Sprint Burndown Chart that you are using to track remaining work. The Sprint Burndown Chart is a visible picture of the project state, and serves as a team motivator and sanity check. Work has been broken into tasks, none of which requires more than two days’ work individually.

✥ ✥ ✥

It is easy to interpret the Sprint Burndown Chart as a good portrayal of estimated remaining time, and to use that portrayal to develop confidence in meeting the SprintGoal of Done functionality.

Usually, team members update the Sprint Burndown Chart daily to reflect adjustments to the amount of remaining work. Such updates reflect a desire to have as good knowledge as is possible about the effort remaining. These estimates are made in mid-stream and reflect increases that arise from emergent requirements. However, given that one emergent requirement has been discovered in a task doesn’t imply that no others remain. While the confidence in an estimate usually improves with each revision and with continued work on the task, unusually wicked problems seem never to converge.

On the other hand the Product Owner is not centrally interested in partially completed work, only in PBIs that are Done and potentially shippable. Emergent requirements, even those discovered by the team, increase risk, and the Product Owner is certainly interested if estimates expand. Because there may always be emergent requirements, any estimate of remaining time based on work mid-stream in a task has a higher degree of uncertainty than the relatively risk-free estimate of zero remaining time for Done items.

In theory, it is possible for the remaining time on a Sprint Burndown Chart to be quite near zero, yet to have few (or perhaps zero!) tasks in the Done state. Stronger even, if the Development Team focusses on tasks done only instead of getting PBIs to done, then at the end of the Sprint there can be a whole lot of tasks done but no single PBI completed.

Therefore:

Update the Sprint Burndown Chart in only two cases: reducing the amount of remaining known work if the task is Done; and increasing the amount of known work if the task grows in size due to emergent requirements or other insights gained during the Sprint. Do not reduce the amount of remaining work if a task is only partially completed.

It looks like we’re going to make it! But of course, we don’t:

With the pattern, the graph is more telling of the risk ahead:

✥ ✥ ✥

The Development Team and Product Owner together have a better picture of the state of the Sprint with respect to the Sprint’s business goals of delivering Done functionality. The team can revise estimations in the middle of a Sprint with more confidence because they are not dependent on the unknown remaining time for partially completed tasks. Yet, the risks incurred by the “surprises” of emergent requirements are embraced and made visible.

This technique makes the Sprint Burndown Chart a much better Information Radiator that visualizes progress towards success than if the team instead tracks finer-grained work. The focus is on the deliverable. It is impossible, using this approach, to come near the end of a Sprint with a Sprint Burndown Chart that projects success even if the Sprint ends with 90% of the tasks only 90% done, without being able "to see it coming" on the Burndown Chart. In many ways, Track Done only removes a symptom; the deeper problem is a failure to focus on end value. See the pattern Swarming as a simpler and more powerful alternative.

There is a chance that a completed task can become “un-completed” by emerging requirements in some other task during the Sprint. For such cases, re-plan in the Daily Scrum and bring the item to Done.

This pattern was suggested by Jeff Sutherland, co-creator of Scrum, and he reports that it is widely used by numerous clients.