A past co-worker reach out distressed about their Sprint Review meetings running amuck. Too many participants, topics, and tangents dropped the value of the meeting down to zero. Clearly, the Scrum Master must get the meeting refocused, but what’s the best way to do that?
[featured-image single_newwindow=”false” alt=”National Library of Ireland – Flickr” title=”National Library of Ireland – Flickr”]National Library of Ireland – Flickr[/featured-image]
This team operates in a plan, build, and run model. In other words, there are people responsible for planning, people responsible for development, and people responsible for support. A problem with this model is the cost of transitioning work between the 3 teams.
In an attempt to lower the cost of the handoff, the build team (scrum team) decided to incorporate the transfer to the support team (run) during their Sprint Review meeting.
Not surprisingly, the participants in the Sprint Review meeting increased and the build team now struggles to complete the support transition in the 4 hour time box (4 week Sprints), let alone the actual activities that are supposed to be completed during a Sprint Review meeting.
From the Scrum Guide:
During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.
This means that the build team is not properly reviewing the current increment of software. They are not adjusting the product backlog to optimize the potential value of the next Sprint. And they are not collaborating with the product owner to get aligned for the next Sprint Planning session.
To solve this problem, the build team should add transitioning support of the new feature/story/bug fix to their Definition of Done. There are 3 clear benefits to moving the cost of this activity from the Sprint Review Meeting to the overall Sprint.
- Impact of the requirement will show in the team’s velocity. The build team should estimate their work knowing that transitioning the feature to the support team is part of the effort. This ensure that the cost of the process is known and can be discussed in real terms.
- Impact of the requirement will show in the value delivered. Similar to the value benefit, knowing the impact to amount of value a team can deliver in a sprint is another metric that can help guide better decision making and operational practices.
- The value of the requirement can be discussed in terms of impact to the organization. Having metrics replaces emotional conversations. Rather than argue that a transition meeting has zero value, the team can discuss the merits of the system in terms of value.
Perhaps most important of all is that the build team gets their Sprint Review meeting back. This meeting is critical for getting the team ready for the next Sprint and to ensure that product backlog is optimized and ready to be used in the next Sprint Planning meeting.