I do not understand why the burndown is looking like it is. Remaining work is higher than capacity - but in the details remaining work is lower than remaining capacity.

Can anyone help?

Burndown

Work details

Analysis

I'm not sure where this data is coming from, so this is only an educated guess. However, it looks like your burn-down is correctly showing that you have more development work than originally planned. Depending on your system, this can happen if:

  • New work is discovered during the iteration, and added to the Sprint Backlog.
  • You're tracking hours spent rather than tasks/stories done, and hours spent exceed the original estimate.

In this case, it looks like the latter. Your team estimated 39 hours for "development" (whatever that means to them), but has expended 41 hours on those activities so far.

Potential Next Steps

First of all, this may or may not be a problem. If your implementation provides sufficient slack to handle minor perturbations, then a few hours one way or another won't really matter. However, if enough work is being added that the Sprint Goal is in jeopardy, or if the projection shows that essential work will no longer fit within the current iteration, then a discussion with the team (including the Product Owner) should take place as soon as possible.

You might also consider that tracking task time consumed may be an anti-pattern, especially if it's not yielding useful information for your team. A related answer discusses the use of Trello to track story points consumed, which looks quite similar to your current time-based approach. Another answer provides a different take on why time-based tracking may be a poor measure of work remaining, and some options for addressing that.

In any case, remember that your goal in Scrum is not to make pretty graphs that follow an ideal trendline. The burn-down chart is an information-gathering and information-radiating tool, not a core deliverable. Instead, the team should use the burn-down data as a means to surface unexpected impediments within the current process, and as a conversation-starter for the whole team (including developers, Scrum Master, and Product Owner) to communicate more effectively with each other about what's really going on within the Sprint.

  • I know how do do Scrum, But thanks. We do not track work done, only remaining work - that's not an antipattern. I am just trying to understand why the numbers and the graph don't match - or what i don't understand. – stulster Oct 22 at 12:23

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.