Posts Tagged ‘stakeholder analysis’

Is that even the right question?

Sprint Reviews: my experience is that they can swing from compulsory to optional and very often fall short of their true potential. Some teams see them as “demos” – a place to “show off” and prove that we did some work. Others see them as a place to give Stakeholders the reassurance that we are delivering against our plan and are on track. Sometimes, they can be a place for feedback: usually when our customer is external and it’s the only chance we get to show them something while it’s still in progress. I’ve seen organisations make them compulsory – but then only invite the team, and I’ve seen other organisations choose to do them quarterly, usually after a major feature has gone live, and then the team spends hours preparing for them. Usually, it’s a presentation. Rarely is it interactive or collaborative.

I was working on a team that frequently cancelled their sprint review. Arguments ranged from:

  • We’ve already shown the stories to the key subject matter experts (SMEs): they have given their feedback
  • It takes too long to prepare for it: we’ll show everything once we have the end-to-end journey completed (and often, released)
  • There was an Exco meeting already this sprint: we covered everything then. No need to repeat. Let’s just have a team review. (Side comment – if your Scrum team needs a meeting every sprint to show each other what happened in the sprint, then that’s a signal there are other problems to solve.)

Cancelling a sprint review made my Scrum Master heart very heavy. The Scrum Guide describes the Sprint Review as follows:

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

Some of these conversations WERE happening. But they weren’t happening in our Sprint Reviews nor were they happening with the whole team. These conversations also often focused on the roadmap from a feature-list perspective rather than how our product was evolving. Our sprint review had turned into a presentation – and one that required a lot of preparation – so it was no surprise that the team wasn’t seeing the value. We tried some experiments to get more interaction out of our attendees (often about 50 when everything shifted to virtual), without much success. Mostly they seemed to be there to get updates on how things might be progressing rather than out of interest in how our Product was developing.

So I took a step back. And decided to approach the problem with my facilitator hat on:

  • Who were our stakeholders? Why were they there?
  • What was the desired outcome of the Sprint Review – and were we inviting the right people?
  • What did the people we were inviting want out of our review?
  • Why did we seem to have multiple versions of the same meeting?

One clue to this problem was that my Product Owner and other key people in the management space often referred to the Sprint Review as a Business Review. Long story short, my first a-ha moment was this:

What was happening in our space was that the stakeholders for both meetings were pretty much the same people. And those people were not comfortable having project type debates in front of the team. And although they were interested in the thing we were building, it was at a high level and more in terms of progress rather than a desire to build the best thing for our users.

If you take these two types of interests, and then consider the following stakeholder analysis for the two “meetings”, you would get two different groups of people (with some overlap):

Another thing I noticed was that whereas the group of stakeholders for the project would remain fairly consistent; the group for the Product could shift sprint-to-sprint depending on what the sprint goal had been. Based on this observation, if your meeting invitees for your sprint reviews never change, then that might be another signal that your Sprint Review is not actually a Sprint Review.

I believe that in a true Product focused environment where decision making sits mostly in the team, the Sprint Review could and should satisfy both interests. However, while most organisations are still transforming and things like budgets, team composition, and ROI still sit with managers, it may be wise to use this perspective and ensure you’re having the right meetings, with the right people, on the right cadence for both needs to be satisfied.

What has your experience been with Sprint Reviews?

What a-ha moments have you had?