Burning down tasks(hours)- Is it worth it?

It is important for the team to have a shared understanding of what work needs to be done to achieve the Sprint Goal. Sprint Burn-down Chart is one of the tools used by the Team, during the Sprint, to manage themselves to achieve the Sprint Goal. A while ago I wrote about the . One of the repeated questions which come up during my Certified Scrum Master class is “Who should update the burn-down chart?” It is usually easy to answer that, but many a times, these questions are symptoms of other underlying problem. A little bit of digging helps me understand why students will ask me a question like that. Some of the reasons given by their respective Development Teams include

1. They don’t like it, the work remaining is unintentionally compared against the “ideal line”
2. It is cumbersome to add up all the numbers everyday and keep updating it, it is simple, but is also boring and takes time away from actual development efforts
3. Team members usually get into discussions on who should be doing the task and depending on who will be doing it, the number of hours that it will take to complete the task will be different. This discussion is of very little value.
4. Management/Product Owner wants to know how much work is remaining and so we are told to update it everyday, the Dev. Team don’t like going through this tedious process (and so they cook up numbers anyways to maintain actual “time remaining” to be close to the “ideal line”)
5. Good teams and good Scrum Masters understand that “burning down tasks” gives everyone an illusion of progress (as against actual progress), but are told to do it anyway because that is what their Management/Scrum Coaches can understand.

Einstein once said, “Make things as simple as possible, but no simpler”. So what alternatives do Teams have to manage themselves instead of using a “task (hours) burn-down” chart?

1. Story Point Burn-down – Story-point burn down shows the remaining story points left as of a particular date. If there is too much work in progress (no limited WIP), the line is quite flat for a long time. If the stories are too big, the drops (in the burn down) are huge. Ideally, the stories should be small enough to be completed in a couple of days. If stories are written as thin-vertical features, using a story-burn down shows actual progress (or remaining stories) and it also encourages good behavior like (a) Team members swarming on stories to complete stories and (b) doing Product Backlog Refinement regularly so that the stories are small.
   
2. Story Count Burn down – Some times teams spend too much time on estimating stories using story points. An alternative is to slice stories to just about the same size. So Product Backlog Refinement is all about refining the backlog item such that it is well understood and that the team agrees that this story is “small” or “too big .. we need to slice it further to multiple smaller stories”. If this approach is used, a story count burn down would correspond to “number of small stories left to be completed” at the end of a particular day. This type of burn down also encourages swarming and encourages splitting stories to “small” stories
3. Burning down Running Tested Features: It is a good practice to write Product Backlog Items as User Stories with Acceptance Criteria. If an ATDD tool like jBehave/NSpec is used, it is customary to write Acceptance Criteria in Gherkin format (Given … When … Then.. ) Each of these “Acceptance Tests” may be considered as a “feature”. If an Acceptance Test is coded and it passes the test, it is considered done. Whatever is not coded is not considered complete. This can be “burned down”. It is possible to have varying number of acceptance tests per User Story.
4. Burning down the number of tasks: During Sprint Planning (and Sprint execution) teams can choose to break down their work to tasks, but not estimate these tasks in hours. Breaking down work into tasks may enable team members to have a shared understanding of what needs to be done (and not forget some crucial tasks that may have come up during the discussion), but avoids the non-productive discussion around who will be doing it and how much time it will take to complete the task if they do it (or if someone else does it). The trade-off here is that tasks should be broken down in such a way that it is a meaningful task to the team and that everyone understands it (e.g. “fetch customers who have been active in the past 90 days from the DB instead” of “code stored procedure”). These task “count” can be “burned down” every day (i.e. plotting the number of tasks remaining against the specific day). This burn-down is simpler than a task (hours) burn down, but the caveat is that this burn-down also gives an “illusion of progress”, does not necessarily encourage swarming (of stories) by limiting WIP. Nevertheless, this is one other option available for teams.

I am not recommending one type of burn down over another. The core principle behind Scrum is “empiricism” i.e. make things transparent, then inspect and adapt. My suggestion to teams that are finding it hard to maintain their burn-down is to experiment with different types of burn-down, inspect and then adapt.