Please login or join to subscribe to this thread
"Agile Reporting" is a buzz-word. Most popular in project using agile practises are burn-down charts. But you need to use them carefully as they work with relative (non-dimensional) estimates to forcast what a team believes they can achieve in one iteration (so-called story points) and it is more a guideline for the team's forecast. It is not a teams commitment and it needs to be combined with other known facts.
As with any reports, you need to focus them on the information needs of your stakeholders. From a project progress tracking perspective, common agile ones include:
- burn up and burn down charts
- defect tracking charts
- cumulative flow diagrams (used in kanbanized environments)
These would be used in conjunction with other “traditional” reports.
A good book about this topic is Cohn´s "Agile Estimating and Planning" and Highsmith "Agile Project Management". You can find both inside the PMI´s book site for free if you are PMI member. But at the end, I will talk about my personal experience: First, something obvious. No matter you are working into Agile environments or not the only thing that matters is to know your stakeholders and their needs of taking information (remember that you have data and you have to transform it into information but information depends on the receptor). Second, you can create your own reporting. I make it in my actual work place and after making a intensive amount of work I will "sell" the idea and today is the "standard" in our company.
As mentioned, what are the needs of the stakeholders? What are the decided KPI's, criteria, and thresholds? How at the reports to be exposed? There are the 'typical' agile centric reports such as cum flow, burndown/up, velocity, etc.? The others have great points, with a lot of experience behind them.
Agile metrics are reported frequently through series of Sprints. Hence it is important to minimize the metrics to the key metrics that tells the story to the stakeholders.
Identify the needs of the stakeholders you are reporting to, categorise your stakeholders in main groups, create multiple reports with minor differences to target these different groups. Consider the complexity of these stakeholders.
Please login or join to reply