Useful Status Reports

Status reports are a way of life for most developers, however there is no standard way to write a status report unless you have a manager or team leader that is supplying some sort of template to fill in.  This lack of examples leads to a lot of confusion about what information to include, the type of details to supply and the size of the report to deliver.  There is always the suspicion that these reports are seldom read and the urban legend of the engineer that wrote their reports in a foreign language to see if their manager would notice, which allegedly they didn’t.

In my experience I’ve only ever had one manager who I know who would read and understand the reports given to her by her engineers in whatever format their engineers chose.  Most managers are not usually as flexible as this or as technical which leads to problems with them not understanding the reports and the potential for developers using technical terms as a smoke screen.

I think the best way to think about how to write a status report is to think about what the motivation is for the person who is asking for the report, what do they want to know?  In most cases what they want to know is:

• The work that has been completed since your last report: the gains.
• What could cause problems in the future: the risks.
• Things you’ve encountered that caused problems: the issues.

It is also worth considering how they want this information presented:

• An easily digestible format: the use of technical terms for non-technical individuals is counter productive.  Even if your manager or team leader is a technical individual it is quite likely their superiors are not technical or not closely familiar with your teams problem domain.
• In a concise manner: most managers or team leaders usually have to supply reports of their own to their superiors so having to distill the reports given to them during the preparation of their team reports is inefficient.
• In a single sentence: The more senior a person is the more likely they are to skim reports given to them due to time constraints. This makes concise non-technical summaries very important for getting the key points of the report across.

Below is a template I currently use for my end of scrum status reports for my team, which I supply to my non-technical manager as an email. The colour coding seems very popular and makes it easy to skim.  There are notes in the template that I write over that I added for myself to guide me while I write the report, which takes no more than ten minutes.  I keep this template inside a task in Outlook which I have set to recur at the end of each sprint, so I don’t forget to write the report or lose my template.

Summary sentence, avoiding technical terms and picking out the most important points, as this sentence may be as far as some people read.

Gains:

• List of completed features.
• Concise as possible.
• No technical terms!

Risks:

• Possible future risks and potential solutions.
• Concise as possible.
• No technical terms!

Issues:

• Problems experienced and the solution(s) used.
• Concise as possible.
• No technical terms!