I work on a small Agile development team which is part of a large, non-agile thinking corporation. Currently, we practise Scrum and occasionally, we exceed our sprint commitment.
My question is, how do you handle burn down charts when you have exceeded your sprint commitment? I can think of two options:
- Extend the y-axis in the negative direction and keep counting down
- Add more cards/stories/work and have the burn down value increase by that amount, burning down when that work is finished.
The ultimate solution for my team is one which is clear to the business and adds real value for the developers. So far, neither of these solutions has worked out perfectly.
In my opinion, burndown charts can’t go negative. If you’re done with your work you either keep on sitting in your chairs doing nothing which means that the burndown will stay at zero.
If you indeed do something, then that should be added to your list of tasks, meaning that the burndown will go up and then down again when you’re done with tasks you added to your sprint’s workload.
A sprint where the original workload has been completed before the sprint ends should show a little spike when new tasks (either single tasks, e.g. bug fixes or whatever, or one or more new user stories) have been added again once it became clear that there’s room for more.
However, if this happens frequently with your team you seem to be constantly underestimating your velocity and should start committing to more tasks from the beginning. I’m not saying that it’s a bad thing to be able to finish early and take on more tasks, but if this happens in a lot of sprint it is a sign that the team is undercommitting right from start, either by accident or to make absolutely sure that there’s no way they will fail the sprint.
If that’s okay with your product owner, so be it. If I were the product owner and I would see one team always finishing early I would try to get them to commit to more tasks right from the start. This might sound a bit harsher than it’s intended to sound.