enthiosys agile product management - agile product management, motivated from within

Weekly Project Tracking in Agile Projects

 

One of the great virtues of agile methods is that they provide near real-time feedback into the status of the project. At the end of the iteration (or sprint) you know exactly where you stand, and you know which items from your iteration / release backlog have reached the “Done, Done” status of potentially releasable software. When coupled with velocity and burn-up / burn-down charts, many agile teams think that they everything they need to properly communicate their status to the rest of the organization.Unfortunately, they’re wrong. While it is certainly important to communicate velocity metrics, burn-up/burn-down charts, and the status of individual backlog items, a well-designed agile status reporting infrastructure communicates several additional and critical pieces of information.

I believe that a status report should serve the following goals:

1. Publicly and openly communicate the status of the development to the organization in a way that is consistent with Agile practices and helps other groups within the company accomplish their job(s), most notably preparing for the release.
2. Identify and track dependencies so that the organization manage the overall portfolio of projects.
3. Identify and track project risks and associated risk mitigation strategies.
4. Formally track agreements that affect the release.
5. As needed, track and communicate resource used by the project.

As you consider these goals, you might reflect that most of them have nothing to do with “agility” and instead have everything to do with sound principles of project management.

These goals, however useful, mean nothing if the team is unwilling to regularly create and communicate status information. This can be a legitimate point of concern—if you’re spending more than 15 – 30 min a week generating status reports, something is wrong. I’ve long felt that status reports are generated most enthusiastically when:

• They provide value to the person and/or team creating the report.
• They are generated relatively easily using the tools that the team is already using to monitor progress.
• Taken together over the life of the project / history of the release the status reports tell the abbreviated story of the project.

This means that whatever tool that you’re using to manage and track your project should provide a means to output status information in a simple and straightforward manner. Ideally, this tool is the sole repository of information, so that merely accessing the tool is all that you need to communicate the status of the project.

Return to agile PM blog