Reporting on Agile Projects
Another post aimed at those new to Agile…
Although the Agile methodology does not prescribe any particular forms of reporting there are two tools or techniques that are almost always used. This is because between them they give a direct and comprehensive overview of the status and health of a project for the least effort. The daily stand up meeting, and the burn up chart tell you most of what you need to know about a project at a glance.
The daily standup meeting should give everyone in the team an up to date view of what people are working on and what problems they are facing on a daily basis. It is an extremely valuable tool for the team and helps in unblocking problems almost as they occur. If possible, the daily standup should be held near the Big Visible Plan so that you can literally point to the work on the board. Having a whiteboard handy is also a good idea so that issues that arise during standup can be captured immediately. This kind of reporting – internally to the team and to anyone else who can get to the standup – is essential to the smooth running of an Agile project.
The burnup chart is a simple graphical representation of completed scope over time (velocity). Functionality is estimated in terms of relative “points” and these points form the basic currency of the project. As each “point” of functionality is completed and approved by the customer it can be counted. At the end of each iteration the tally of completed points can be charted. It is also often useful to track points at various stages on the same burnup chart. For example, we commonly track:
- Points complete
- Points QA Complete
- Points Dev Complete
- Points Analysis Complete
This chart gives a clear indication of whether or not the velocity of the team is sufficient to complete the work planned or even if more work can be undertaken – how far have we come? How far have we got to go? Will we make it?
Standups and burnups give the team members a lot of information but they are not foolproof. Too often, stakeholders either can’t/don’t come to the regular meetings or are not located close enough to the team to see the burnup chart. They may also be used to reporting in a more traditional way. In some organisations project reporting is also centralised through a PMO and the format for reporting is prescribed.
Where I’m currently working, we prepare a written weekly status report which is shared with the team and is sent directly to senior stakeholders and management. This report contains a basic dashboard, a written summary of functionality delivered during the week, as well as a summary of the financial position of the project. It can also be very important to escalate risks and issues (some risks and issues can be effectively dealt with within the team but others need the support of stakeholders and other managers). The status report is a useful vehicle for this.
We typically have low levels of defects but reporting defect levels is also a very important factor as it gives all stakeholders a view of how healthy the output is.
If you are starting an Agile project, look to the Daily Standup and the Burn Up chart as the foundations of your reporting. Encourage interested parties to come to standup regularly. I personally don’t believe in segregating the group into “Chickens” and “Pigs” – as long as what people have to say is relevant to most of the group and they play by the rule then let them participate.
Use other tools creatively to aid communication. Written status reports have their place, I’ve also started “blogging” a status report in the form of a short narrative. In this format I’m trying to be engaging, a bit more human and hopefully slightly entertaining, including snippets of the more human side of what is going on for the team. This won’t work for everyone but at least people are interested to read it. Use what works and don’t be afraid to experiment.
