11 Secrets for CRM Sprint Review Meetings
One of the benefits of Scrum for CRM customers is transparency: the ability to frequently inspect progress. We inspect tiny increments of progress at the daily standup and story previews but the most valuable inspection opportunity is at the sprint review meeting. In a traditional, sequential CRM implementation project users don't have a chance to review the system until the acceptance testing phase. By then it's very expensive to make any changes.
Contrast that with sprint review meetings were there most recently completed features are demonstrated every two weeks, during which feedback can be incorporated into the next sprint.
In Customer Agility projects, sprint review meetings take place at the end of every sprint.
Here are my secrets for great sprint review meetings:
- Use story previews to demonstrate completed features to the product owner beforehand so that you can maintain the pace of the sprint review meeting and there are no surprises for the product owner.
- Before the review, run through all the sprint items together and agree what's required to ensure they meet their acceptance criteria and your team's definition of done. Ideally, there are only a few open tasks left to complete. This is your last chance.
- If your team needs more than 30 minutes to prepare for the sprint review meeting then review your practices in the sprint retrospective afterwards to determine how you reduce sprint review preparation.
- Demonstrate features from your development environment so that another team member can make a quick change during the meeting and demonstrate them again before the end. After the sprint review, promote completed features into the acceptance testing environment.
- The sprint review meeting is for the benefit of the product owner. Other stakeholders should be invited too. Publicise your meeting and use a large enough room or an open space where future users, interested executives and other teams can drop in.
- Help stakeholders visualise progress. Have your story board and sprint burndown chart on display as well as demonstrating your completed features on the big screen.
- Sequence your demonstration so that there's a flow to the features, either following a business process if that was the sprint goal, or group them by user role.
- If your product owner has been closely involved in the development of a feature let them demonstrate it at the sprint review meeting. This works really well when other stakeholders are present. Nothing demonstrates acceptance like a product owner doing the demo.
- Leave no doubt about that each item is done (or not). The team should be able to present compelling evidence that each item meets its acceptance criteria and the definition of done. But the product owner has the final say.
- If a story isn't done or isn't accepted don't dwell on it for long. Note the incomplete tasks or failed acceptance criteria and move on. Review your practices at the sprint retrospective and review the story again in your next sprint planning meeting.
- Celebrate your progress. One of my teams, where the sales team used to ring a ship's bell every time they won a sales opportunity, used to ring a bell each time a story was accepted as done.
I'd love to hear what other tips and practices you've used to improve your sprint planning meetings. Join us in the comments below.