How to do simple yet useful sprint reporting
Previously, I wrote how to delegate responsibilities and automated reports I receive from my VPs. Now, here’s an actual example of a report, so you can see how it works in real life. The example is related to the agile reporting and how I stay updated on the ActiveCollab's development without having to mire myself in day-to-day details.
Sprint metrics
We have a section in our company wiki called Control Tower, where project managers list features, releases, and sprints that are under development. Each big feature (that takes more than a month to develop) is a separate project. We develop them in biweekly sprints (like in Scrum).
After each sprint, the project manager creates a report that answers the following questions:
What was the goal of the sprint?
Before the project kick-off, we set clear targets for each sprint's goal. Not all projects lend themselves to the two-week timeline, but they all have established targets. Teams need clear goals, expected outcomes, and timeframes, so you can measure what you've achieved and test your estimating skills.
Who managed the team, and who did the work?
We record who manages the team and who is responsible for what parts of the work. This helps us with performance reviews of both project managers and the developers. It's also nice to check the wiki from time-to-time and remind yourself how you contributed to the company’s growth.
How long was the sprint, in work days?
We restrict sprints to 10-12 days, plus two extra days for the kickoff and retrospective. Days are recorded as actual dates, for future reference.
How many tasks did we plan to deliver? How many complexity points did they have during the estimate?
During the kickoff, the team estimates how complex each task is in the sprint. These are then used to gauge whether the workload can be actually achieved in those two weeks. A project manager monitors the team’s progress. If there's too much work, they remove some tasks from the sprint and put them for the next sprint.
How many tasks were finished? What's their complexity score?
We measure velocity (how much work we finish) by adding up the complexity points of each finished task. Only tasks that fully meet our definition of done are taken into the account. Knowing your velocity is important, so you can better plan in the future. It's also an indicator of how well we did our job.
What were the conclusions from retrospective?
We always hold a retrospective after each sprint and note the conclusions in the team’s knowledge base. This way, we capture learned lessons for future sprints and projects. This is especially helpful when someone new joins the team. We give them to read every sprint report before starting to work, so they learn from our experience.
Which wiki articles were written or updated during the sprint’s course?
With the pressure to deliver working software, documentation is often an afterthought. But, it's extremely important because it helps us maintain projects, especially the old ones. So, writing development documentation is a mandatory part of the process. All new and updated documents are listed in the sprint report.
Example of Agile Reporting
Here’s one of our sprint reports (numbers and descriptions have been tweaked a bit to better illustrate the point):
As you can see, a report is just a regular wiki page with a couple of tables, lists, and some conclusions gathered by the team immediately after the sprint, while the memory is fresh.
But the real magic happens later on when these reports pile up. Then you can see how well your team performs over time when you underestimate the work, etc. These reports are also very helpful when a new developer joins the team, so they can learn from our experience.
Agile reporting is great when you do it right. It gives everyone a good point of reference from the past, helps us plan future growth and make better daily decisions, and prepares us on how to deal with challenging situations.