Sprint Reviews: make them Public or Private?
We try to include all elements in our Sprint Review meetings, as described in the Scrum Guide. Our organization is currently growing in Scrum maturity, but stakeholders are hesitant on making the Sprint Review meeting public . open to the entire organization. Instead, they prefer to keep the Sprint Review closed, with only the Scrum Team and Stakeholders present, and have the Scrum Team demo the increment in a separate demo meeting for the rest of the organization somewhere in the following sprint. Their primary reason is to mitigate the amount of time other teams and colleagues spend attending Sprint Reviews and have them just get the bare minimum of info during the separate demo meeting. One of the key purposes of this Scrum Team is to drive innovation and try new technology, whilst working on a new product.
I noted that the Scrum Guide doesn't really specify that the Sprint Review should be an open meeting, but only mentions that Scrum Team and stakeholders collaborate about what was done in the Sprint. However, as the Product Owner and an Agile coach for the organisation, I'm inclined to make the Sprint Review open to the organisation and invite anyone that has shows an interest in the Increment and product. I believe this fosters transparency and innovation within the organisation.
I'm interested to hear what your thoughts and experience are on having Sprint Review meetings open to the entire organisation, or using alternative ways on keeping other people in the organisation informed on progress.
The Scrum Guide provides for stakeholders to be invited to a Sprint Review at the Product Owner's discretion. Since the PO is accountable to product stakeholders, it is up to him or her to determine the appropriate stakeholder audience for reviewing a given increment.
+1 to Ian, and in practice, inviting people who don't understand the purpose and details of the PBL can be a complete waste of time. People will ask numerous questions about stuff because they are totally out of the loop with the goals of the PO and team.
The whole org doesn't need to come. I know some other Scrum Trainers popularize this thinking, but I think it's bad advice as a rule, and I think it's a misunderstanding of Scrum.
OTOH, there are contexts where inviting the whole org is a great idea. So, your mileage may vary, but *at the minimum*, the Scrum Guide says the PO invites the *key* stakeholders.
In my view, key stakeholders are usually customers, end users, and people who control the money/budget being spent on the product.
Here is an idea - You could record the Sprint Review and have it available for anyone in the org to view afterwards to stay up to date, that way you could keep the sprint review to the people who care about it most & have contextual awareness about what is going on.
You could also have an online forum to answer questions for those random folks who are interested in the project.
What I would do personally - have it open to the capacity of the room. It promotes transparency and 'nothing to hide'. It is gives a chance for others to be excited about what you're doing - both the scrum part & the product you are building.
You can always try having it open and seeing how it goes. You can always change it later & discuss it in the retrospective.
I'm in an organisation that practice the whole organisation thing on the sprint review meeting. To be honest, if you have strong independent confident stakeholders/leaders/managers with very little prestige involved you may succeed. In addition, every team member on the development team must be confident to speak about his or her failures/success in public and those who listen must understand what the development team describes so that no misunderstanding occur or false romour starts in the corridors. I guess it all boils down to the company culture. If you want to spread information around the company a demo is a good idea but to have a public sprint review is not, in my opinion.
Posted By Joe Flo on 29 Oct 2014 04:36 PM
..... In addition, every team member on the development team must be confident to speak about his or her failures/success in public and those who listen must understand what the development team describes so that no misunderstanding occur or false romour starts in the corridors.
Hi Jo,
Why is a team member supposed to do that during sprint review? If we follow the scrum guide the sprint review is about displaying "done" work to stakeholders and contemplate on future work. Maybe i'm wrong but discussing what was "ok" and "not ok" during the sprint isn't something that should happen during the sprint retro ?
I guess it all boils down to the company culture. If you want to spread information around the company a demo is a good idea but to have a public sprint review is not, in my opinion.
I agree on the company culture thing, however normally during the "sprint review" your PO should ask from some of the stakeholders to participate. For the Sprint retrospective however i think it's better to keep it inside the scrum team.
Thanks to all for the replies. We're keeping the sprint reviews with the stakeholders and people who show explicit interest in attending for now, and update the rest of the organization in separate demo meetings.
As for Joe's remark about sharing both success and failures: I don't think you should expect every team member to share the same presenter skills, but I do think any Scrum team should be transparent about what did and what didn't succeed. Especially if the cause of not meeting the sprint forecast lies outside of the Scrum team, the reduction of expected velocity can often be resolved by stakeholders, who then decide to improve the circumstances or capacity for the team.
+1 to Dimitrios and Morgan's last 2 comments.
Tim, your idea... well... I know that your heart is in the right place, but let me tell you a little story about recording the Sprint Review....
I coached a team who did this, and I let them know of this possible downside, but they did it anyways and it became true within about 3 sprints.
Once the Sprint Review is recorded and available for all to view, the key stakeholders might very well stop showing up, which means everyone loses a tremendous amount of transparency on two major things:
1. Feedback on the increment
2. Transparency about how the PBL will proceed in the near future.
This 2nd part is the one that most teams forget about anyway, but it is actually every bit as important if not MORE important than the 1st part.
Then, if you really want to talk about the Scrum Guide, there are 5-6 other things (see the bullet points under the Scrum Guide section on Sprint Review) that should also be discussed so that all key stakeholders and PO are present so that everyone realizes that there are competing needs and the PO has the last say on those needs.
When you record a Sprint Review, you can lose all of this gigantically valuable feedback. It happened in 3 sprints to the team I coached... only one key stakeholder kept coming -- the rest operated in the shadows and by watching the videos instead. It was brutal. The team retrospected and decided to go back the other direction and stopped recording them, letting the key stakeholders know why. Slowly, but eventually, they all started coming back to the Sprint Review. This particular org never got beyond much more than about #1 and #2 above while I was still there, and I don't know what happened after that.