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 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 […]
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 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.
To begin, I title the postcard with some basic context about the sprint:
Next, I include a brief summary of work completed during the sprint:
Depending on the project, I may also include a burnup or velocity chart or a screenshot showing visual progress on a key feature.
This section previews the work planned for the upcoming sprint:
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:
There are a lot of moving parts and pieces in any sprint. It can be useful to offer a quick reminder of team availability:
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.
I try to keep postcard 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.
The post The Project Postcard: Creating a Report Stakeholders Will Actually Read appeared first on Atomic Spin.
Source: Atomic Object