Agile A3 Sprint Report

I really enjoy working with A3 Reports. They have the habit of making you to distill out the crucial information, to really drill down.

There are different kinds of A3 reports. The book 'Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System’ describes three different report types. Problem-, Proposal-, and Status Report. The Problem Solving is the one I use most often.

So what is an A3 report. A3 Reports are size limited and have to fit on an A3 size of paper (for US folks, it is 11.69 × 16.54 inches). The size limitation requires to only present important informations. Furthermore, the use of charts, graphics and other none textual descriptions is highly encouraged. The less words the better. Since the Problem A3 Report describes the current and the target situation they serve as excellent PDCA (plan do check act) tools.

In my profession as Scrum coach, I grew tired of all the different and bureaucratic status reports. Usually the decision makers require lots of text and a traffic light. The text does not get read and all decisions are based on a single color. So, my idea was to create an A3 Report which is hardly text and more differentiated then only one color. Providing a quick and easy way for more information width. 

This is how it looks like:

Top Left - Sprint Burndown

Current Sprint burndown. Blue remaining work in hours, Green remaining Story Points

Top Right - Release Burndown (Burnup in this case)

Up to date, including last Sprint, release burnup

Bottom Left - Risk list 

Up to date, risk list a la Frederic Brooks. New risks are continuously discovered and either handled by outside help (i.e. by the Scrum Master) or they get put into the Product Backlog and mitigated when the Product Owner puts them into a Sprint. The risk list is dynamic and subject to change from Sprint to Sprint. (*) Mitigated risks are kept on the list.

Bottom Right - Open Bugs

Up to date number of open bugs. If I can have my way on a project, the 10-Finger-Rule applies. The moment you run out of fingers to count bugs, you need to fix bugs first. This guarantees clean, maintainable and sustainable code. If a bug is rather tricky to fix, it can be put into the Product Backlog analog to a risk. Again, the Product Owner then schedules the fix, if she sees it to be appropriate. Also, this avoids the growing number of bug triage meetings towards the end of an project (**). If you work on an legacy project with X bugs, the rule changes to X+10. Done right, X will decrease over time and product quality will go up.

(*) On many projects the institutionalized company process requires a risk list. So, at the early beginning of the project a risk list is compiled, checked off on the check list and then put into a drawer. No transparency and accountability.

(**) On many projects you you have severity levels from P1 to P4. With P1 being worst and P4 minor. Usually, you have a company mandate, that no software can be shipped with open P1 and P2 bugs. Guess what ... in the growing number of meetings after each bug fixing cycle, panic tends to creep up. The human reaction is to ‘mis’-label P2 as P3. Problem fixed, process followed.