Problem solve Get help with specific problems with your technologies, process and projects.

Agile project management: Burndown charts, story boards and continuous integration

High-functioning Agile teams realize the importance of the appropriate requirements tracking tools. Read this expert response from Lisa Crispin to learn alternatives to burndown charts such as story boards and continuous integration, and how these tools not only track your project, but ultimately help reduce issues and defects in the products being developed.

Are burndown charts the best way to track an Agile project or are there other methods?

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.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.