But, so often, the release sprints do not work and the feedback is thin. More nuisance. Meetings fatigue, competing priorities, and different focus areas lead to disengagement. People lose interest. If sprint reviews are to achieve their goals, then we need to find a fresh approach. One that supports each participant and entices them to contribute their best ideas.
This is how one team went from foggy sprint reviews to a lively feedback process. From isolation, disconnect, and boredom to collaboration, engagement, and impact.
Confluence along with Jira Snapshots for Confluence, were at the heart of this transformation:
- Ahead of the Sprint review, we share Sprint data on Confluence. After that, everyone can check whatever data is of interest to them. No longer forcing everyone to endure everything. The product owner digs into the sprint velocity reports. The technical writer skips that and heads to the demo videos.
- We share detailed, honest information about the Jira issues. For this, we use Jira Snapshots tables. These provide a static, time-stamped overview of Jira data. They are daylight clear, even for non-Jira users. Product owners are no longer required to muddle into Jira to discover lost stories.
- The face-to-face sprint review meeting is now a “sprint AMA (ask me anything)” instead. No longer review but rather a Q&A, led by the interests and feedback of the audience. This format ensures there is more time for juicy debates.
- A lot of the feedback happens offline. This happens through Confluence comments and often involves long threads.
Using Confluence to breathe life into the Sprint Review processes
A sprint review has a comprehensive agenda. It relies on many information bits shared by the sprint team with the broader business audience:
- Sprint goal
- Key achievements and challenges
- Performance charts and metrics review.
- Overview of stories, tasks, and bugs, planned vs. done.
- Important bugs resolved.
- Demo of stories.
- Plans for the new sprint.
- Stakeholder feedback, and customer feedback.
The PMO (Project Management Office) created a standard structure in Confluence. This is not a single page but a standard group of pages available for each sprint. The scrum master initiates it when they prepare the sprint. The sprint team adds data to these pages as the sprint progresses. For example: when transitioning a story to DONE, the developer records a demo and uploads to Confluence. They will also add notification to any person from whom they need feedback. The notified person does not need to wait until the sprint closes to check out the demo and provide feedback. They give their feedback as a comment on Confluence.
Using a consistent Confluence structure for sprint reviews
Leveraging Jira Snapshot to bring to light the status of Sprint stories
In this organization, sharing Jira data with business leaders was difficult. Jira was the haven of the geeks. A place where business leaders do not want to go and where developers bury stories in obscurity.
We wanted our feedback machine running again. For that to happen, development needed to stop being the technology snobs they used to be. Business leaders needed to know more about what was happening inside Jira. And this did not relate only to the summary reports and the key metrics; it needed to go down to the story level.
The PMO found that the Jira Snapshots for Confluence app can eradicate this information silo. With Jira snapshots, the scrum master created (with one click) a time-stamped list of all issues in the sprint. They took one snapshot when the sprint started and another one when it ended. Everyone with access to that Confluence page sees the same report—no need to buy a Jira license for people who do not use Jira. Also, business leaders did not need to learn how to navigate Jira. This fact delighted our business leaders. They felt included and respected.
We use Jira snapshots reports to generate our standard sprint reports:
- The list of issues in the sprint. The scrum master generates two snapshots: one at the start and a second at the end of the sprint. Jira Snapshots has a comparison view to see what changed between these two points in time.
- The list of bugs solved in the sprint.
It was easy to set up pages with standard configurations for the jira snapshots. These are re-used for each sprint. With a single click, we now have factual information sharing between developers and business leaders.
Jira snapshots shows a diff between the start and the end of the sprint
When sprint reviews rock
The new sprint review format has been running for the last few months. It took a sprint or two for people to adjust, but as you know- it’s easy to get used to positive changes. Looking at this now, no one understands why it took us so long to move to this way of reviewing.
Developers are happy because the feedback they receive now is more meaningful. People stopped complaining about what the scrum team did not achieve during the sprint and have become more supportive. The previous bunch of technology snobs found that sharing information yields more understanding. Stakeholders see how their input matters, so they feed developers with more precise and comprehensive input. They also see how our capacity works and how better prioritization can make a difference.
Transforming the sprint review process had a massive ripple effect.
The vibe of the organization is different now. Before, it was one of isolation, snobbism, and suspicion. Today people feel energized, supported, and trusted. They are happy to work in such a place. Even the churn rates have declined.
This is an example of how tooling can help a change in culture. It’s a matter of letting the tool in, and using it wisely.
Is your team ready for this change?
Download Jira Snapshots from the Atlassian Marketplace today!
