What does the perfect status report look like? [closed]

Question

I work with a lot of offsite developers and contractors. I ask them daily to send me a quick 5 minute status of their work for the day. I have to sometimes consolidate the status of individuals into teams and sometimes consolidate the status of a week, for end-of-period reporting to my clients.

I want to learn:

• Items accomplished and how much time was spent on each
• Problems encountered and how much time was spent on each
• Items that will be worked on next, their estimates (in man hours) and their target dates
• Questions they have on the work

I'm looking for a format that will provide this information while:

• Being quick for the developers to complete (5-10 minutes, without thinking too much)
• Easy for me to read and browse quickly
• Is uniform for each developer

What would you suggest?

Answer 1

you probably do not want to hear this, but here is it anyway -

i have been in this situation on both sides of the desk, and come to the conclusion that these kinds of rolled-up status reports are a complete waste of time for you and the developers. Here's why:

• the developers should be working on features/deliverables with specified deadlines
• the developers should be asking questions when they occur
• communication should flow in both directions as needed

if these things are not happening, no amount of passive status reporting is going to fix the problems that will inevitably arise

on the developer side of the fence - a "quick five minute status" [i hate that phrase, five minutes is not quick!] interrupts the developer's flow, causing a loss of fifteen minutes (or more) of productivity (joel even blogged about this i think). But even if it really is only five minutes, if you have a dozen developers then you're wasting five man-hours per week on administrivia (and it's probably more like 20)

on the manager side of the fence - rolling up the status reports of individuals into teams by project etc. is non-productive busywork that wastes your time also. Chances are that no one even reads the reports.

but here's the real problem: this kind of reporting and roll-up may indicate reactive management instead of pro-active management. In other words, it doesn't matter what methodology is being used - scrum, xp, agile, rational, waterfall, home-grown, or whatever - if the project is properly planned and executed then you should already know what everyone is doing because it was planned in advance. And it doesn't matter if it was planned that morning or six months ago.

ignoring client requirements for a moment, if you really need this information on a daily basis to manage the projects then there are probably some serious problems with the projects - asking the developer every day what they're going to work on next and how long it will take, for example, hints that no real planning was done in advance...

as for the client requirements, if they absolutely insist on this kind of minutia [and i know that, for example, some government agencies do] then the best option is to provide a web interface or other application to automate the tedium that will do the roll-up for you. You'll still be wasting the developers' time, but at least you won't be wasting your time ;-)

oh, and to answer your question literally: the perfect status report says "on target with the project plan", and nothing more ;-)

Answer 2

Use Scrum. Create the sprint backlog, have a spreadsheet with the tasks and a column for each day of the sprint. Ask people to fill out the hours worked on each task every day. Send daily report starting with the burndown chart for the sprint and then short two one liners for each member - last worked on and next working on. Send weekly report with the burndown chart, red/yellow/green status for each major feature (and blocking issues and notes if it's not green) and the remaining items on the sprint backlog.

I don't have a link to samples, but here are some drafts:

10/02/2008 - Product A daily status

<Burndown chart>

Team member A
Last 24: feature A
Next 24: feature A unit tests

Team member B
Last 24: bug jail
Next 24: feature B

Team member C
Last 24: feature C
Next 24: feature C
Blocked on: Dependency D - still waiting on the redist from team D

10/02/2008 - Product A weekly status

<Burndown chart>

**Feature A** - Green
[note: red/yellow/green represents status; use background color as well for better visualisation]
On track

**Feature B** - Yellow
[note: red/yellow/green represents status; use background color as well for better visualisation]
Slipping a day due to bug jail
Mitigation: will load balance unit tests on team member A

**Feature C** - Red
[note: red/yellow/green represents status; use background color as well for better visualisation]
Feature is blocked on external dependency from team D. No ETA on unblock.
Mitigation: consider cutting the feature for this sprint

**Milestone schedule:**
Planning complete - 9/15 (two weeks of planning)
Code complete - 10/15 (four weeks of coding)
RC - 10/30 (two weeks stabilization and testing)