The main method of status reporting is through the daily scrum meetings. Whilst this is great for those involved with the project who can attend, there may be many stakeholders who aren’t available to attend daily meetings.
Those stakeholders may be providing significant investment to the project or be relying on it to add value to the business; it is therefore imperative that they are kept ‘in the loop’.
Here we will explore other methods of Agile status reporting.
Agile Reporting
Unsurprisingly, reporting follows the Agile concept of being simple and ‘just enough’. The focus in on getting the project done efficiently and sufficiently, not completing check box exercises.
When selecting reporting techniques therefore, it is important to focus on those which will deliver value. Traditional methods such as Gantt charts and project plans often don’t fit into this category, although they may be the most familiar reporting methods.
Types of Agile Reporting
As mentioned previously, the daily scrum meetings are the main method of status reporting. There are however four other reports, completed at the end of each sprint, that will keep stakeholders up-to-date with the status of the project.
Product backlog
Containing every feature that makes up the finished project, the product backlog is a simple document that lists a one-line description of each feature listed, a relative estimate of size, and an indication of its priority.
For more information visit Agile: Product Backlog.
Sprint backlog
The sprint backlog can be categorised as a learning document; each sprint reveals new realities about the product, processes, staff capabilities and completion speed. Learning about the realities of the project enables the team to make changes to the plans as the project progresses.
A subset of the product backlog, the sprint backlog only takes into account the features contained in that one sprint. The stories that are developed are owned by the team and regular progress updates are provided in the sprint planning meetings.
Changes report
Agile is about being flexible and responsive to changes. Whereas traditional project management methods map out the entire project at the planning stage, in Agile changes and additions to the product are commonplace as stakeholders are exposed to the product as it develops. This ensures that the end customer receives the highest quality product.
Change can often seem cumbersome, and so processes must be put into place that encourage teams to make changes that will be beneficial to the customer.
This is where the changes report comes in. Features that are added, deleted or modified are tracked in the report and are subject to approval of the product owner.
The report acts as a traceability report for budget and audit purposes and helps to eliminate any disagreements of changes that have been requested.
Burndown chart
A simple trend graph, illustrating the work performed over a certain time frame, the burndown chart estimates the work that needs to be done and plots the story points that have been developed as time passes. A trend line is then drawn between those points.
This simple, visual chart shows the team how far they still have to go and indicates any areas where the project slows, or changes have been incorporated.
For more information visit Agile: Project Burndown Chart Overview.
Agile pioneer, Ron Jeffries made a case for visible charts, and so having this chart in an area visible to everyone, on the wall for example, allows all who pass to see clearly what has been achieved, what is left to achieve, and how the project is progressing against commitments.
It is vital in Agile that the team and stakeholders don’t get bogged down by detail. Remember that the daily scrum meetings are the most important method of communication and are complemented by the reporting methods above.
Charts and programmes can be used in the implementation of those reporting methods; however, the key is Agile. Don’t use fancy programmes for the sake of it. Sometimes, the humble sticky note and whiteboard is all you need.
