Busy Burning Down Sprint Tasks

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!

Comments

[Ruud]

For every new project/customer I start with making Sprint burn-up charts, and almost everywhere I quit doing it after a while, since indeed they do not offer enough information. A Sprint of two weeks is usually too short to see some trend going on. Plus teams always seem to have a hard time to get rid of a hockeystick-shape burn-up, where they start slowly and suddenly start delivering at the end. This last is telling something about what you write already: not swarming but doing more things in parallel.

More info on how to swarm would be interesting indeed. I understand the issues that devs tell me they have with 'work all on the same user story': they are only in each other's way. Do you have good pointers on that?

[Rachel Davies]

It is often possible for more than one developer to work on the same story, they just need to collaborate more on how to divide it up and work in baby steps checking each chunk in before moving onto the next. Pairing helps.

[Persillie]

I experienced in one project at a customer, that burn down charts started to come handy for PMs to track the remaining effort (we are talking waterfall with 4 releases/year here). Especially since tools like JIRA show these nice plugins. They wanted all kinds of burndowns - one for the whole release, one for each feature, one for a two weeks period (with a replanning meeting but no review/retrospectives).

The whole thing was totally useless, because we didn't agree on any done criterias, we didn't focus on one feature (despite my warnings that there might be nothing complete to deliver at the end). And that visualization on the board like you mentioned would be more helpful (we used to have board for exactly this purpose, but we were forced to change everything after they started this "lean IT initiative").

[Rachel Davies]

Thanks for sharing your experience, Persillie. All too often managers get sucked into the illusion that they're seeing progress towards a date by the slope of a line but these lines can hide the true picture. We need to ask what's stopping us delivering working features rather than is everyone busy working on a separate piece.

[Allan Kelly]

I just don't see the point of Sprint burndown charts. The board (should) tell you what you need to know. Burndown charts spanning several sprints, now they are damn useful.

Nor do I like the idea of someone leading a stand-up meeting by asking people how long it will be before its done. People might volunteer this information and I'd hope the way of tracking work would make people feel good about completing things but hours left? Pointless in my view.

[Paul Thompson]

I agree with your sentiments about a messy board. It has to radiate information or its pretty useless. The chart you presented looks like you can clearly see the number of items in each of the states over a time period.

Aren't Sprint Burndown Charts useful to see person effort remaining (in days though).

With this chart, if you have 30 simple 1 day tasks released and 10 complex 3 day tasks in Analysis then the chart wouldn't be very helpful as it would show equal bands of pink and green. Or have I misunderstood what you are getting at?

[Rachel Davies]

Thanks for your comments, Paul.

I don't think that tracking person effort remaining is that useful. I believe that a board representing the stories and tasks in the current sprint makes it easier to see what's going on. I also notice that many teams burn down a bit too optimistically so the sprint burndown chart often doesn't tell the real story.

Regarding your question, the items counted on the chart are product backlog items rather than tasks. The chart doesn't distinguish between large and small items but over time the bands would get wider if items were stuck in a particular state.