Are burndown charts the best way to track an Agile project or are there other methods?
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
Though burndown charts are one way of tracking projects, in my experience, high-functioning Agile teams often dispense with burndown charts, as they find other ways of tracking are more effective. Burndown charts tell you pure numbers, but don’t point to any particular problem area. A story or task board provides more information, which can still be absorbed with a quick glance. Each row on the board is a story, and the board has several columns: “To do,” “WIP,” “Verify,” “Done.” The board may be a physical board on the wall, or a virtual one in an online tracking tool.
It’s extremely helpful to also include a column for anything blocking the team, to make that constantly visible and remind the team to discuss it every day at the stand-up meeting. For example, if we need a mock-up from our product owner, we write a card for it and put it in the “blocker” column. Color-coding task cards provides another level of information. For example, if you look at the board and see that most of the white “coding” cards are in the “done” column, but there are many green “testing” cards in the “to do” column, it’s obvious that testing has fallen behind, and the team needs to get more people helping with the testing. If too many stories have cards in “WIP,” it’s clear that the team is not focusing on finishing one story at a time, and team members need to adjust their priorities.
Continuous integration is another effective way to track progress. If regression tests fail, the team will know right away, and can (and should) take immediate action to correct the problem. If the number of tests isn’t going up as the iteration progresses, the team must not be checking in much code, so they need to find out what’s going on and take action to fix it. Our business managers get reports from the continuous integration, and they notice if a build is broken for two or more days, or if the number of tests at any level goes down. They’ll come ask us if there’s a problem and if we need help.
This was first published in April 2011