Yesterday, I attended a daily standup meeting run by a Scrum Master/Project Manager. He was holding a red marker pen and, as he went around the circle, he'd ask the developers what time was left as he wanted to be able to "burn down" each development tasks by crossing out the original estimate and putting time left. His focus was on whether the tasks each of them was working on would be finished rather than whether features were actually Done. If a developer said "Yes" then he'd say "Great!" When he got to the last developer, she said boldly "I told you it would be 2 days at about 3:30pm yesterday afternoon so I haven't even had a full day on it yet."
After the development tasks were burned down, it was the testers turn to speak - of course their tasks were not on the board. There were half a dozen feature cards that had been moved over into QA column because the developers had just made a build available. No questions were asked about time left here. Even though testers raised some blockers, such as needing test kit and wanting to understand what scenarios were completed in previous sprints, they were left to resolve these with developers.
The focus of this meeting seems all wrong. The whiteboard that this team was standing around was very cluttered and I don't think anyone could tell from it what would be done at the end of the week. There was a Blockers area on the board but it seemed unused. The system seemed to have been put together in a hurry and left to get untidy, serving only as a prompt in standup meetings rather than an information radiator of sprint progress.
As getting to Done didn't seem to matter, why burn down tasks at all? My guess is that the Scrum Master wanted to make sure everyone knew they had work to do but surely the team already knew that. Instead of gathering progress and making sure everyone is busy, a Scrum Master should be listening out for blockers that are slowing down the team. Being busy is not the goal, delivering working features is.
Where does this idea of burning down tasks come from? Well, Scrum does indeed encourage teams to be aware of time left by creating a Sprint Burndown chart. But a sprint burndown chart should contain all the work remaining on the sprint backlog not just development tasks. Even when constructed correctly a sprint burndown doesn't really tell you much about where the work is, in my opinion these trend lines are pretty useless. A sprint burndown can mask a team working waterfall-style with nothing made available to test until the end of the sprint. A sprint burndown can also mask a team that is spread widely across a number of features rather than swarming to get a few features complete before starting on the next. It's for these reasons that sprint burndowns have largely dropped out of use across the industry. They take time to maintain and don't give you a lot of information. Nowadays, most teams visualize their work by moving cards across a team board to Done.
To get a richer picture of what is going on I recommend establishing swimlanes so it's easier to see features move across the board. You can also generate a Cumulative Flow chart, basically a tally of the number of items in each column, see below. This can give you a view of where the bottlenecks are and understand cycle times. It's also simpler to update because you total the number of items in each column rather than adding up estimates.
For example, table below shows a list of the number of items in each column from the team board, recorded on a weekly basis.
This table can be used to generate this chart:
One last point is that, once teams get good at slicing backlog items, they often stop doing task breakdown in sprint planning. Consider bringing tasks back into these meetings, if there are misunderstandings about what needs to be done.
I'd be interested to hear if you've seen similar misunderstandings of burning down tasks in sprints and look forward to your comments. I aim to write a separate blog on product backlog burndown charts and velocity soon so please save comments about product/release burndown or burnup charts for that. Thanks!