Show and tells, sprint reviews and showcases — what’s the difference?

I was recently asked to share some best practice on running effective show and tells. This led me into a semantic rabbit hole on the differences between show & tells, sprint reviews, team reviews, end of iteration reviews, sprint demos and showcases. These words are often used interchangeably to describe similar things. In this post, I’ll explain what some of these terms mean to me.

For most agile teams I’ve worked on in Government, all these terms are generally used to describe two different types of events: team review and show & tell.

Team reviews are for the team to review the work they have done in the most recent iteration.

• Also known as sprint reviews in SCRUM, these events are held at the end of each iteration. They are a forum for the team to inspect the outcome of the sprint and collaborate on what to do next. All completed work from that iteration should be demonstrated and if necessary discussed.
• Key stakeholders sometimes attend team reviews. On one team, whilst we worked on our MVP for private beta, decision makers from policy, legal, risk, security & data protection all attended team reviews so that they could see for themselves how acceptance criteria and definitions of done had been implemented.
• The SCRUM guide states that this event should take up to 4 hours for a 4 week sprint, but I’ve never been involved in team reviews that have lasted longer than 90 minutes.
• I like to set aside time after standup each day so that the team can review work together as it’s completed rather than all at the end, so my team reviews rarely last longer than an hour.

Show and tells are for the team to show their work to a wider group of stakeholders and to get feedback.

• They are a crucial form of governance for agile teams that keeps everyone up to date by allowing them to see the team’s progress first hand. They are also a forum for celebrating progress and the achievements of the team.
• The audience at show & tells is much wider than team reviews — including any stakeholders with an interest in or influence over the team’s work. There’s usually a lot of people in attendance, many of whom are non-technical and/or senior.
• They are usually held once per iteration, but can also be run less frequently, and are always held after the sprint review. I try to ensure that show & tells don’t last longer than 55 minutes.
• I like to group show & tells according to workstreams or themes to make it easier for all relevant stakeholders to attend each time, so there can be multiple teams presenting in one show & tell.
• Instead of walking through every item in the backlog, I find this wider group gets the most value out of seeing specific pieces of work that we think will be most interesting and/or useful to them, and the most likely to generate valuable feedback that will enable the team to validate their learning. I meet with the leads from each team presenting at show & tell beforehand to plan what we think those things are and how they will be delivered.

Combining team reviews and show & tells into a single event can be a good move when:

• The team is using Kanban or running continuous reviews of each deliverable throughout the iteration rather than one big review at the end. In these cases, the team will already have had a chance to review the work before show & tell, so a separate team review may be unnecessary.
• The team is not part of larger organisation or programme of work. In this case, there might not be enough extra people at the show & tell to warrant holding a separate event.
• The team is working in a high trust environment. In this case, team members should feel more able to share work in progress with the wider organisation with less fear of reputational damage if they show a bad piece of work / talk about it in the wrong way. My preference is for the team to review work before it’s shared outside the team, but the main person who needs to be sighted on things is the product manager.

Showcases are also worth a brief mention. They are one off or less frequent events where teams (or teams of teams) share their most important achievements and plans for the future. On GOV.UK we used to do these at the end of each quarter. They usually consisted of some combination of quick overviews from each team, deep dives into the work of specific teams and presentations from leadership or third party teams / organisations. Showcases can be for internal or external stakeholders (or both).

To summarise, the most important part of all this is that teams should aim to share their work regularly with each other and stakeholders, and get feedback. As with everything in agile, teams should continuously improve their ways of working and do what works best for them and their stakeholders. It doesn’t really matter how many different types of events you run or if you use the same words for things as I do, but it is important for teams within an organisation to describe things in a consistent way. People communicate more effectively when they have a shared language for things.

Thanks go to Steffen Lydum and Gethin Jones for their feedback on this blog post!

Originally published at http://alaniswright.com on April 6, 2021.