« BDD in a Nutshell | Main | Guiding New Retrospective Facilitators »

16 March 2012


Feed You can follow this conversation by subscribing to the comment feed for this post.


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.


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.

The comments to this entry are closed.