Kelly Waters is Web Technology Director for IPC Media, one of the UK's largest publishers of consumer magazines and web sites. Kelly has been in software development for about 25 years and is a well-known narrator of agile development principles and practices, as a result of his popular blog 'Agile Software Development Made Easy!' (www.agile-software-development.com). Kelly is a DZone MVB and is not an employee of DZone and has posted 40 posts at DZone. You can read more from them at their website. View Full User Profile
One area agile methods don't
really address is project status reporting.
Obviously the daily stand-up (or daily
scrum) is a good form of status reporting. It's great for people with a
close interest in the project who can spare the time to get to the scrum.
But it's really no good for other stakeholders that can't get to the
scrum each day, either because they are interested in less detail, or because
they have an interest in many projects and can't be at all the scrums.
For people like this, a traditional project status report is still
important. But traditional project status reports often have their problems too.
In my experience, they are often too wordy, sometimes leaving you to find the
essence of the report in a sea of useless information.
For a regular project status report, calculate the burndown
chart using the entire product backlog for the project, not
just for the current Sprint. Forecast what future Velocity
you think can be achieved based on the team's past performance. The forecast
line will allow you to forecast the project's likely end date.
burndown chart gives a really clear indication of status. Particularly if the
team is very disciplined about the definition
of done. Importantly, the status is obvious at a glance. So
it's really good for stakeholders that can't get to the scrum, providing the key
information without losing the point in lots of words.
If the project is
running behind, or facing key issues or risks, they obviously warrant a brief
The other key dimension on most projects is cost. Why
not create another burndown chart for the project's costs? If the forecast line
reaches zero before the planned line, you're running over budget and (unless you
finish early) you will run out of funds!