Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Scrum Review Meetings in theory look good on paper.
But in real world , do this review meetings yield anything positive continuously ? Or people just go through the motions ?
I am currently in a team , where we just go through the motions and there is no feedback . I am new to Scrum and wonder if this is the norm .
This might be opinion based/broad but i would like to know about real world experiences of other scrum teams.
As with most things in Scrum, if it doesn't feel right then generally something isn't right.
A key principle in Scrum is responding to change and focusing on delivering real business value rather than just turning out code. The Sprint Review is critical for this process as it is the opportunity for a wider audience to provide their feedback. The team talks continuously with the Product Owner throughout the sprint, but many stakeholders don't have the time available to do this. So they love the opportunity of the Sprint Review to really engage with the team.
As a Scrum Master I emphasise to my teams that they need to go in to Sprint Reviews with the attitude of looking for feedback rather than demonstrating progress.
As an example rather than saying
"This is what we did this sprint"
I much prefer a team to say
"We added a new search function on the home page. What do you think of the positioning? There was a lot of debate in the team about whether we should pre-load it with the last search. What are your thoughts on this?"
One good trick is to use a Sprint Review rehearsal to identify possible discussion points. As a Scrum Master I would constantly interrupt a rehearsal with questions. Why did you do that? What is that for? Couldn't you have done that differently? Where there are doubts or differences of opinion I make a note and suggest that the team raises the point in the Sprint Review.
Another piece of advice is to not expect the Sprint Review to follow a rigid structure. Anticipate that there will be feedback and encourage it. If the stakeholders detect a reluctance to accept feedback they will quickly switch off. Say, for example, a stakeholder gives some feedback and a discussion starts. Let that discussion run it's natural course. Don't interrupt and say there is not enough time due to more things you want to show.
If you constantly fail to get good feedback at the Sprint Review then it is worth questioning who is attending. I have seen one practice where a team will reserve 3 chairs for customers and end-users. If these people do not attend the Sprint Review then the chairs are empty. This reminds the team that they are missing out on important feedback.
Are you speaking specifically of the Sprint Review/ Demo meeting?
This meeting is one of the meetings that so very often goes off the rails.
The first flaw is many assume this is the meeting where the product owner accepts the work. If the PO doesn't accept the work until the Review, then if the story fails acceptance, it isn't done.
The next flaw is not having the right audience. The Sprint Review should have an open attendance. In specific you want your stakeholders, customers to be there. These are the people you want to be talking to and presenting to. You want to collect their feedback so you can adapt in the next sprint. If the stakeholders don't see the work until the very end, then it's little better than waterfall.
Next is the mindset of the meeting. Think of the Sprint Demo as a technical retrospective of the work done and not done in the last sprint. You want to talk about failures and why they happened. You want to talk about and demonstrate successes. The failures are important because stakeholders can often help with the cause of failures.
And a last common issue is getting people to show up because they are "too busy". If you have a number of teams doing scrum, band together and hold a "demo time" in a common area. Think of it like a science fair for code. Teams setup at tables and the stakeholders can walk around seeing each teams work product. Serve snacks and beer and turn it into a celebration.
