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: Continue reading