If you’re like most scrum teams, you likely conduct a review or demo at the end of each sprint. But do you send out a project report summarizing the work of the sprint? I do so in the form of a simple “project postcard” that I send to all stakeholders.
The postcard is a quick way to inform clients of work completed in the sprint and give them a snapshot of value delivered by the team. This is especially helpful for stakeholders who couldn’t attend the sprint review. They’re also an invaluable resource for new members joining the team to see where we’ve been.
Simplicity is key. The more succinct the content, the more likely someone will read it. And if not, at least I’ve only spent fifteen minutes on it. For each new project, I create a postcard template with the desired information.
Context
To begin, I title the postcard with some basic context about the sprint:
- sprint number
- sprint theme or goal
- sprint start and end dates
Completed
Next, I include a brief summary of work completed during the sprint:
- a list of backlog items completed
- total points completed, if using estimates
- any milestones met, such as releases
Depending on the project, I may also include a burnup or velocity chart or a screenshot showing visual progress on a key feature.
Upcoming
This section previews the work planned for the upcoming sprint:
- sprint theme or goal
- the next couple prioritized backlog items
- optional link to the full list of items committed in the team’s backlog management tool
Budget
For some clients, I include a budget update directly in the postcard. For others, I may send this information in a separate email to key individuals:
- budget total
- budget burned %
- scope complete %
- estimated budget end date
Schedule
There are a lot of moving parts and pieces in any sprint. It can be useful to offer a quick reminder of team availability:
- any planned out of office time for core team members
- office closures/holidays
- any planned milestones, such as releases or a new member joining the team
Other Metrics
Each project is unique, and each client has different needs. That’s why I make a habit of asking the product owner what information they’d like to see summarized. Depending on the project, I’ve tracked various metrics relating to project risks and retrospective takeaways.
For example:
- number of defects fixed
- number of automated tests written
- key decisions or priority changes made
- percentage of the backlog estimated
- change in scope (helpful for projects where unexpected work materialized during the sprint)
I try to keep project report creation to no more than fifteen minutes. Wherever possible, I make additional information easy to access by linking directly to our backlog management tool. In addition to emailing, I also put a copy of each postcard in a repository shared with the team.
Extensive reporting in the agile process can have diminishing returns. But I find this lightweight postcard helps keep stakeholders aligned on expectations. It’s also a fun way to look back and see how far we’ve come as a team.