Daryl Katz Riethof
Sprint reviews for teams working with multiple clients and managing multiple projects can be a challenge. At Caktus, we combine more traditional sprint review guidelines with some tweaks to fit our company and client’s needs.
Meeting preparation
The morning of the sprint review, our Scrum Master shares the sprint goals with the stakeholders. This reminds stakeholders what we were working on and allows them to decide if what we are reviewing is relevant to them.
Before the sprint review meeting, the team gets together to determine the presentation order and who will present what. As the product owner (PO) for my team, I go through each of the sprint goals, organized by client, and we discuss what will and will not be presented.
Meeting structure
If there are no external stakeholders, the meeting is time-boxed and follows the general flow below to keep things organized and moving forward:
Starting the meeting
The product owner starts the meeting:
- Sets the stage
- Introduces attendees (when necessary)
- States what will and will not be demoed from the sprint
Presenting work
The team presents done work on staging/production, or work that is in QA but not yet completed if there is value in getting feedback on it at this point. Incomplete work is presented with the caveat that it is not done; we do not share any work that is solely on a developer’s local environment.
- Team members demo the work, individually or jointly
- The presenting team member discusses any applicable key events, major challenges, and solutions
- The PO asks for questions and feedback from stakeholders, recording it for later prioritization in the backlog
Discussion of the backlog
Once the demo is complete, the PO leads discussion of the backlog:
- Review the next highest backlog priorities and projections/release plan (if appropriate)
- Solicit opinions on those priorities
- Take into account feedback from the sprint review and re-evaluate the backlog for next sprint planning
When these meetings consist of internal stakeholders or a single client, we go through this script once.
In the cases where the team is working on projects for multiple clients, we break our meetings into half-hour or one-hour chunks. We then go through this script with each client, discussing only their pertinent projects.
Why do it this way?
Following this format gives each project the time required to have a thorough and helpful sprint review, and keep things on track for both the team and the client. It allows the client to see their features come to fruition and gives them the opportunity to ask questions in real time to the developers who do the actual work. It also allows the developers to hear feedback directly from the clients and gives both an opportunity for dialogue. Finally, POs can get a sense of how to start adjusting the backlog for the upcoming sprint.
If you found this helpful, check out these other project management tips.
