Agile insights from LitheSpeed
man at whiteboard

What Could Possibly Go Wrong with the Sprint Review?

By Luiz “Q” Quintela

I previously discussed the Sprint Retrospective, which is often not conducted properly and loses credibility quickly when that happens. The Sprint Review is often not used to its full potential as a feedback gathering mechanism and very often turns into a boring demo with little more going on than a couple people pretending to pay attention while the back row is mostly sleeping, attempting to stay awake or somewhere in between

In most cases, it is the lack of understanding of the purpose of a Sprint Review. The Sprint Review is extremely important to gather feedback, but I often hear it being referred as the Sprint demo and that is just about of what happens. I had a client that squeezed 8 teams doing demos back to back in close to 3 hours and was surprised that mostly people wouldn’t show up when invited! 

Let’s not mention the cost of having many people in a meeting that holds no interest to any of them but also the cost of gathering no feedback and adjusting your backlog to it. That is what is costly!

I noticed a few things like these:

    • Organizations that adopt Scrum in name only or believe they are “doing” Scrum because they picked up a few elements of it and believe that is all there is.
    • Product ownership being run by an unempowered “puppet” (you can call it a proxy if it makes you feel better) that does not understand the importance of feedback or mostly it is only interested in “pushing stuff out of the door.”
    • Scrum Masters that do not understand their role in supporting the team and the Product Owner and basically just set up the meeting, sorry event, and basically just sit there and appear interested.

All the above create dysfunction paradise.

A few things that I recommend that you consider having an efficient Sprint Review:

The review is not simply a “demo.” You should discuss obstacles and learning, review sprint goals, milestones, demonstrate functionality, show evidence of artifacts and quality measurements and show release progress.

Obviously, the Scrum team will demonstrate what got done during the Sprint, however, do not do a geeky demo!

Stakeholders and users could not care less about what version of .Net or Java you are using. They care about the outcomes! Demonstrate from the perspective of the stakeholders and users.

Please, don’t just do a controlled demo! Let the attendees actually “pilot” what is being demonstrated! I learned that years ago when a VP called me for a sidebar and mentioned that she didn’t think that something was done when nobody other than the team could “touch” it.

If you do not have a version that you can let stakeholders and users “play” with, it is likely that what you are demonstrating it Is not really done! Is it?

The most important, is, of course, to generate discussion between stakeholders. That said, while they are offering feedback, make sure that:

    • The Scrum team should be taking notes of anything and everything that is mentioned.
    • They must summarize and combine their notes and the Product Owner must then read it back to all present.
    • Do not rely on sending emails with a summary, odds are they will not be read. Don’t even let me start on creating a PowerPoint and sending it! We are supposed to eliminate waste and not create it!!
    • Ensure that the Product Owner announces the time and date of the next Sprint Review before adjourning.

I would look for the following things that can go wrong, and often do. If you like jargon, they are called anti-patterns.

    • Team demos work that is not done (by DoD).
    • Team does not demo from a user/value point of view.
    • Team gets defensive from feedback.
    • PO and/or the Scrum Master is the show headliner.
    • Product Owner is surprised by what was done or was not done.
    • Stakeholders not present.
    • Team does not show quality metrics.
    • The demo cannot be “piloted” by the attendees.
    • Feedback is not going into product backlog because PO dismisses it.
    • Nobody knows the project progress.
    • PO or SM “diss” the team.
    • Team members “diss” something or someone.
    • PO acts like they are the end user.
    • PO prevents the team from interacting with the end users.
    • Team demos with PowerPoint or screen shots instead of real software. If you I made it up, it did happen and more than once!
Get to know Luiz here.

Learn more about Scrum ceremonies and build your ScrumMaster skills with CSM training or the Advanced CSM.