Here is a question for you
What is the one thing that Test Managers, Project Managers, Scrum Masters, and program Managers, are attentive of?
Yes, the answer is Reporting.
Why do we need Agile Reports?
Most organisations go for annual or half-yearly planning cycle for achieving targets. But in case of IT, all the finalising and approving backlogs are carried out at the beginning of a year.
The top management does not have the time to track the progress or program from close quarters. They do not even monitor progress day-to-day. They just want a snapshot of their department’s performance, and check if all the projects that roll under them are performing at a given point of time. This helps in absorbing, approving, managing funds, better allocation of resources, and finally to track against annual plans at enterprise, department, programme-level.
Obviously, reports are necessary
A few quick and interesting facts for you-
Metrics for tracking progress
Agile project managers have a different set of Metrics to choose, and that shows the progress of the project at different levels. Say, at iteration and release levels, the following is the diagram which speaks about various metrics used to track or address the progress of the project.
The following tweet reveals an interesting fact about the importance of Agile metrics.
Why is it so important to have Reports and Charts?
In any project, work being done is always complemented with Reports and charts. It provides a clear picture of the team's progress against the expected deliverables. It has been most essential for stakeholders and are usually prepared by Project Managers for them to determine where they are in the project at any given time. It actually helps them figure out how soon a project can be completed.
Transparency is the key
The reports and charts also provide them a signal if there were any deviation from what was expected. In Agile, when Product Owners loop information back to stakeholders and Scrum Master to Project Managers we also need to show reports and charts. But one great thing about Agile is that reports and charts are far simpler than in the traditional project management. ‘Simple but accurate’ is one of the key characteristics of Agile reports and charts.
But given its simplicity, do we really get the most out of it? Do we really know what it means? Do we know how to act on it if ever? As they say, the devil is in the details. We have to figure out what is really happening even with the slightest deviation. Insignificant as it may seem, we should be wary on these scenarios.
Reports should be reflect what is ‘real’
To ensure that the Agile reports and charts are effectively utilized, we'll have to break that mindset that reports and charts should always be positive and should always look good to stakeholders or even to Project Managers.
Transparency and on-time delivery
In Agile, when we collaborate or do the feedback loop from Scrum Team to Product Owner, it is important to be transparent and timely.
Clear analysis of deviations
We have already mentioned that transparency is actually the key ingredient for all Agile reports. When a Product Backlog item did not get into any of the Sprint, stakeholders are informed outright on why it never committed. It could be due to the lack of time, incomplete acceptance criteria or vague requirements.
If these are common, then it should lead to the question if the Product Backlog Refinement meeting is facilitated properly. We have to take note that Product Backlog items do evolve. It should be set as a goal that during Product Backlog refinement, you have clear items, they are expanded (more user stories) and with complete acceptance criteria. Strategically themed and high-valued product releases can then be efficiently planned and delivered.
The relevance of Sprint Velocity
If you encounter questions on when you can deliver the project, make reference to your Scrum Team's Velocity.
The following video will highlight the rules for calculating your team’s velocity with precision-
Scrum task board:
When a Project Manager or anyone in the Agile team asks for the daily progress of the Scrum Team, the Scrum Task Board is enough to supply this information.
What is a Scrum Task Board?
The Scrum Task Board is the visual representation of the tasks committed by the development team in a sprint. The tasks are placed in swim lanes that correspond to the progress of a task i.e. to do, in progress, for testing or completed. These are pretty much visible to anyone especially to the Agile Team so that anyone can easily assess the team's progress at any given time in the Sprint.
Visibility is another characteristic of Agile reports. Having too many items staying in the ‘To-Do’ swimlane could only mean that there are some issues that are blocking the implementation. It's another story if the Sprint is about to end and there are still a lot of To-Do items. This should pose as an alarm.
As another supplementary chart to define the Scrum Teams daily progress, the Sprint burndown is used.
A sprint burndown chart is a linear graphical representation of how much work has been performed in a sprint. All forecasted work is to be completed by the development team.
Should it then hit zero at the end of the sprint?
No, not necessarily. But you'll need to trust your team that they have committed enough work in the sprint which gets done within the sprint. Not hitting near zero could also mean that some additional requirements have been included and this will consequently affect the time the developer needs to complete it. These additional requirements can be due to a poor definition of the acceptance criteria.
Reporting in Agile, that you'll use against the Scrum Team in delivering the committed items in the Sprint or in the release should not flog. It should focus on how you'll need to improve the processes in place. Agile reports and charts should have the following characteristics: simple, accurate, transparent, timely and visible. By recording and reporting, it actually helps in managing expectations, promote collaboration and sustain the team's Agility.
What do your stakeholders look for in an Agile Report?
What single question you will have to answer with all your reports?
Are you on Track?
Each and every one that consumes your report, wants to know the progress, Can be Agile or Waterfall, whatever metrics you use, remember as long as your reports provide a clear answer to the above question, your job is almost done.
Basic tips on how to use Metrics or Reports in an Agile project
Suppose you are new to the Agile, and confused to define the progress of the project using different metrics or reports:
Reports and Charts or Metrics plays a vital role in tracking the progress of the businesses and teams. Be sure to only choose the metrics that are highly applicable and which can yield you better results.