Tracking Agile Projects is about monitoring the project health, and checking adherence to the schedule is a relatively simple exercise. The amount of work actually completed in an iteration is compared with the amount of work expected to be completed. Differentials are feed back into the amount of work expected to be completed in the future iterations, which has a self corrected effect on the project schedule.
Monitoring the Release Plan
The easiest way of showing this information is by using a release burndown chart. This chart displays the amount of work remaining on a release and the teams progress over each iteration. This diagram is updated at the end of each review.
The following diagram depicts a fictional project.
- The total number of points for the release is 200
- The estimated velocity is 20
- The iteration length is 2 weeks
- The red line indicates the trend line that should be followed in order to achieve completion on time.
- The blue line indicates the actual decrease (Or burndown) following each iteration
- The black line is a trend line for the actual burndown, indicating an estimated completion of 13 iterations.
From this diagram ,we can immediately derive the following information regarding the release:
- The average estimated velocity is slightly lower than anticipated and should be corrected accordingly
- The project will overrun by an estimated 6 weeks
- In iteration 2, there was actually a “burn up”, where more scope was added to the backlog than was actually completed during the iteration.
- The significant scope change in iteration, coupled a slightly lower than anticipated velocity appear to account for the overrun.
The project manager and owner have the following corrective actions available to them:
- Remove 3 iterations worth (60 points) from the release
- Accept the new release date
- Remove some features and accept a slightly later release date
Monitoring the Iteration Plan
Within an iteration, it is often more useful to monitor health at a lower level. Task boards are the most useful way of portraying this information. Task boards display the stories to be completed in the current iteration. These hourly estimated tasks for each story are displayed next to the story across multiple swim lanes to represent what stage if development the task is currently in.
As tasks are started, developed, tested and verified; they will be moved across the representative swim lanes. When all tasks relating to a story have been verified, the story itself is considered complete.
Tasks are measured in terms of hours, so the remaining estimates within the task board will be given in hours. This allows developers to see exactly how many ideal hours they have left in the iterations.
The following diagram depicts a task board in progress. Note that within LexAble, our swim lane for “to Verify” is called “Waiting for Testing” in order to be more explicit.
Although the task board is excellent at representing the state of the tasks and features within an iteration, it does not give a very clear picture of work left to complete. For this, we use an iteration burndown chart, similar to the release burndown previous discussed. Instead of summing the remaining story points, the total remaining hours should be used.
This chart shows that because the actual work completed line is below the expected, the team is ahead of schedule, but generally appears to be following the expected burndown.
Communicating
Communication within an Agile team should be open, honest and frequent. The charts given above very clearly denote the health of a project at a variety of scales. Favour these lightweight diagrams over complicated and unnecessary reports. As previously discussed, there a few formalised meetings within an Agile lifecycle, these are summarised below.
Release Planning
The first discussion, where themes and larger stories are identified and estimated. This will output the release plan.
Sprint Planning
Completed at the start of each iteration. Appropriately sized stories are selected and broken down into hourly estimated tasks.
Sprint Review and Retrospective
The team reviews the iteration, gathering lessons and new risks. New features are added to the backlog and it is re-prioritised if necessary. The project health will be reported to the owner, but this information should be freely available throughout the iteration. Estimations are also adjusted if required.
Release Review and Retrospective
Complete release review, including lessons, risks and process improvements. Project archival will be completed.