Let me kick-off this post by quickly stating the following facts:
Compiling Reports Sucks…
…and the closer you are to the ground, the more it sucks. Having to look back while your “To Do” list is getting longer and longer seems to be a counter-productive concept (it’s not). After all, reports are just another way for “The Man” to keep an eye on you and constantly evaluate who the next flogging victim is going to be (not true either – I hope).
On top of that, reports usually require supporting stats and digging out that data can be tricky and/or time-consuming. Finally, in most cases, the objective of those reports is to explain why things have gone wrong/the production environment has exploded/the live database has disappeared (delete as required).
As a result, I have yet to meet a report compilation enthusiast – I, for sure, am not one!
Lengthy Reports Cost Money
The longer it takes you to compile a report, the higher the direct cost (“time is money blah blah…”). Indirectly, the cost of having a Scrum Master compiling reports as opposed to running the Scrum or removing impediments can be even higher.
And the story does not end here. The longer the report, the longer it’ll take for the reader to find the information he/she needs and time is money… you get the idea.
Reports are actually needed…
…for many different reasons. Either as an article for convincing your team sponsor to keep paying your wages or (more importantly) to enable you as a team to “inspect and adapt” and become a better unit.
When it comes to Scrum and end-of-sprint reporting, I have seen and written many different types of reports; trying to explain how the sprint went, what we delivered, what the problems were etc. Some of those reports were long or pointless or full of unnecessary clutter (and in some cases, all of the above). But ultimately, what I have found is that the traditional Scrum artifacts are enough to give you the whole picture:
- How many of the sprint’s original objectives were achieved?
- How many story points were delivered (compared to how many were taken into sprint)?
- The points burndown chart
- A breakdown of the points status (not started/in progress/done)
- An overview of the distractions (live issues, blockages etc.)
- The team’s velocity per sprint
- An overview of any production releases
All this information can fit quite neatly on a single A4 page as follows (click on the image to enlarge, or see here for a PDF version) :
The above report has been compiled using PowerPoint and is available for download. Please note however, that the following (free) fonts have to be installed in advance:
- Fertigo Pro: Download here
- Walkway Bold: Download here
- Walkway SemiBold: Download here
- Walkway UltraBold: Download here
The PowerPoint Template (PPTX) can be downloaded from here: Sprint Overview