How do you help your team improve their sprint review presentation?

In my opinion, you should get rid of it. Don’t use a presentation at all.

What would be the value of a presentation? In theory, it makes things easier for a consumer to understand and allows the presenter to control the structure and flow of information.

That’s the concept of a presentation. You get to present information clearly and concisely, about something that you want to talk about.

The problem with a presentation in a sprint review is that it doesn’t help the developers or scrum team in any way. It doesn’t allow them to actively engage product stakeholders and customers to ascertain whether what they have built holds any value for those end users and stakeholders.

In some ways, a well delivered presentation could be a great way to hide.

Don’t waste time with preparation

To put together a presentation, you need to bring the team together to discuss what is going to be presented and to gather the necessary information from each developer to include in the deck.

You need to ascertain what has happened, what they intended to do, what the gap between those two elements are, and why that is the case.

You then need to condense that into slides and summarise the information to present effectively.

This is wasted time and opportunity.

You are better served having those conversations directly with the customers and product stakeholders. It empowers them to understand

what the team are attempting,
what was achieved,
and what stood in the way of them achieving their original goals and objectives.

The conversations provide insight and context that allows the stakeholders to understand what the potential impediments to progress are and through questioning the team, also understand how they can help to remove those impediments.

Remember, the time spent creating a presentation deck is time that developers aren’t working on the product or feature. It’s time that could prevent them from achieving the sprint goal.

A better ‘presentation’ format

How do you demonstrate what your team attempted to do in the sprint? You have a sprint backlog; you can simply show the product stakeholders and customers what the team took into the sprint.

Simply log into the tool that you use, whatever that may be, and talk about the sprint backlog which the team adopted during sprint planning.

Simple.

You can show them which items were completed by directing their attention to the ‘done’ column and you can speak to the items which weren’t completed during the sprint.

It’s already there, in your tool, you don’t need any preparation for this at all.

Instead of creating slides with screenshots of the product or feature, simply log into the system and show them the live product or updated feature. Show them what you have built. Show them the working product and updated feature in real-time.

Again, you don’t need any preparation for this. It already exists.

You can even go as far as allow the customers and product stakeholders to interact and engage with the completed product themselves. If it’s a new feature or functionality, allow them to interact with what you have built so that they have a visceral connection with the new product.

You are going to receive far better feedback from people who have actively engaged with the product, and you are going to provide them with a memorable experience.

Presenting screenshots on a deck isn’t going to achieve that outcome. It is a waste of time and effort.

To demonstrate where the team is going next and what might be achieved in the next sprint, simply show them the tool you use. If that is a spreadsheet, great, just walk them through the spreadsheet and talk about the items that are lined up for future sprints.

If you have a sprint burndown or burnup chart, walk them through what has been achieved over the past 3 sprints and explain what they can anticipate based on past performance. It is a rough estimate but can still be valuable for stakeholders to understand that you have a system in place to address important work and measure progress.

You can have conversations around the upcoming backlog items and check whether you are on the right track, doing the most valuable work for customers and stakeholders, or whether you need to go back to the drawing board.

Does this work for you?
Here are the reasons why these backlog items exist?
This is when we anticipate delivering X, does that still work for you?
Has anything changed which might impact what needs working on right now?

Managing expectations

One of the great things about introducing your customers and stakeholders to your systems and processes is that they become familiar with the environment.

You can offer to provide them with a login that allows them to check the environment, whenever they want, to understand where the team currently are.

A prioritised backlog and software tool for the scrum board or Kanban board allows them to clearly see what is in the sprint backlog, what is currently being worked on, what is under review and what has been completed.

It helps manage expectations and builds enthusiasm for the next sprint review when those customers and product stakeholders will have the opportunity to see what has been created.

It also allows them to make early interventions, via the product owner, if they can see that the team are focused on the wrong items. It empowers them to play a critical role in ensuring that the team are working on the most valuable items at the most valuable time.

So, that would be my advice. Scrap the presentation preparation and instead bring the customers and product stakeholders into your world.

Don’t present information, instead, have conversations with product stakeholders and customers around the work and allow them to ask questions, interact and engage as they see fit.

Document the feedback you receive and empower the product owner to update backlog items as and when necessary.

If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Scrum Masters website.

For more information on John McFadyen, connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/.

If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.

If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.

If you have several years’ experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.

#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster