<-- back to learn page

February 11, 2023

 - published by 

Robert Briese

4 Big Ideas to Improve your Sprint Review

4 Ideen um das Sprint Review zu verbessern

Many organizations don’t maximize the success they could have with Scrum by focusing the Sprint Review on the following:

  • Developers demonstrate work that was done in the last Sprint to the Product Owner and answer questions about the Increment.
  • The Product Owner accepts the items that have been “Done” and decides what wasn’t “Done”.
  • The team celebrates the effort and moves on to the next meeting (Sprint Planning).

While all those things are either mentioned in the Scrum Guide or seen as “good practices” in many organizations, in my opinion, all of them miss the opportunity of getting the best out of a given Scrum event: to inspect and adapt the product and continuously focus on what to do next in order to maximize delivery value.

Here are my top 4 suggestions regarding the Sprint Review:

  1. Get real customers and/or end-users involved in the Sprint Review.
  2. Have the Product Owner (or someone supporting) provide insights about how the product performs, existing timelines, budgets, and marketplace opportunities to maximize any learning about the impact a product has.
  3. Let customers and/or end-users experience the features of the product that the team implemented as much as possible hands-on.
  4. Give every participant a chance to actively collaborate on how to adapt the Product Backlog to reflect feedback and work on what’s most important next (with the Product Owner having the final say).

Let me elaborate more on each of the above points.

1. Get real customers and/or end-users involved in the Sprint Review

Scrum suggests integrating stakeholders in the Sprint Review, but often, I only see developers presenting the product increment to the Product Owner and sometimes Product Owners from other teams. This is often a sign that the team is a component team that only focuses on some technical parts of a given system that need to be integrated with work from other teams, which automatically leads to waterfall development. This can only be changed by changing your organizational design to create feature teams that implement end-to-end customer requirements, as suggested in LeSS. But even when having feature teams, I’ve seen many organizations do Sprint Reviews without actual customers or end-users because they weren’t sure about how to find, motivate and involve the right people. If you build an internal product (like a CRM system), the customers should be the people using that system. This means it shouldn’t be difficult to find and motivate them to join your Sprint Review. If you’re building a market-facing product, then you usually have a marketing department (if people are not integrated into the teams) as well as a selected group of first adopters that love your product and use it extensively – If you don’t, you might want to reconsider if it’s worth investing more in product development. It shouldn’t be hard to integrate at least a few different individuals from those groups in your Sprint Review.

2. Have the Product Owner provide insights about how the product performs, existing timelines, budgets, and marketplace opportunities 

The Sprint Review should be an opportunity for everyone involved in product ideation, creation, delivery, and consumption to assess if the right product (features) has/have been worked on and delivered. This is one of the most important parts of empirical process control. There is no value in delivering in short iterations if you don’t deeply analyze whether you’re working on the right things and change direction if you notice that you aren’t. To assess this properly, you need to look at the actual data, such as how many actual users you have, how often the new features are consumed, and most importantly, whether the recently developed product features lead to the desired impact. I personally like to use techniques such as impact mapping for this, but at minimum, it’s a good idea to prepare insightful data about the product usage for everyone attending the Sprint Review. This can be prepared by the Product Owner or delegated to some other Product Managers, but obviously, the Product Owner needs to be on top of the numbers to make important product decisions. Also, if there are official release timelines that have been communicated, the Sprint Review is a chance to manage expectations with the stakeholders. On top of that, look at providing feedback on budget numbers, which the Product Owner, as the one responsible for the ROI of the product, should be managing. Any other key insights regarding the market change and opportunities that are valuable to everyone involved in product ideation, creation, delivery, and consumption can be announced in the Sprint Review.

3. Let customers and/or end-users experience the features of the product that the team implemented as much as possible hands-on

This is another thing that I see a lot of teams struggling with. Yes, it’s great to empower and motivate your developers to present newly implemented features to customers and stakeholders the, but these demos have severe drawbacks:

  • The developers show what they have tested and what has worked (or ideally, the automated tests check).
  • They usually explain how and why they would use the feature in a certain way.
  • Feedback is limited to a few people who catch something during the demo and are not shy about mentioning it.

Instead of having developers present the newly implemented features, I suggest giving everyone participating in the Sprint Review a chance to experience the features as hands-on as possible. You can achieve this by (1) handing over participants a device, (2) giving the link to the software/application, or (3) putting some paper / digital prototypes on a (virtual) whiteboard. You can include a short description of how to access the features you want to get feedback on and any other questions that help you get valuable feedback. 

This approach has various advantages:

  • The developers can witness how the customers are actually perceiving and using the product/features.
  • The users are not influenced in how to use the features (which reflects the reality out there, where your customers don’t get an explanation of each new feature when they use a given product).
  • Developers sometimes witness customers’ behaviours that are very different to what they have expected, which helps them come up with better solutions in the future.

4. Give every participant a chance to actively collaborate on how to adapt the Product Backlog 

Next to allowing the participants to experience the Increment of the Sprint as hands-on as possible, you also want to give them a chance to provide as much feedback as possible. I prefer to do this by making sure that plenty post-its and pens are lying around next to the device or the paper prototypes, or, if I do this virtually, I have the team(s) create screenshots of the app screens, or whatever there is to review, on a virtual whiteboard where participants can directly leave feedback. You can also add additional questions (like what features are currently missing or whether they would expect the functionality to work differently) to get valuable feedback. You’ll be amazed at how much feedback you get compared to when you are “just doing a demo”.

But the crucial part only starts after you’ve received all the feedback. Because, as I mentioned earlier, there is not much value in doing an iterative and incremental development if you don’t constantly adapt the backlog and make sure you’re working on the items that, based on the latest feedback and current understanding, are supposed to deliver the highest value to the company/customers. So, you want to distil all the feedback and come to a decision on what critical feedback you have and want to act upon right away (maybe already in the next Sprint), what important feedback there is that you want to discuss and reevaluate in a future Product Backlog refinement, and what feedback isn’t important for now. You can do this by grouping all of the feedback together and separating the groups into different categories. Ultimately, it should be the Product Owner who makes the final decision on the prioritization, but the more you involve all participants in reviewing, grouping, and differentiating the feedback, the more they will better understand the customer needs and purpose of the product. 

With just a few changes, you’ll get more highly interactive events where every product creator/developer interacts directly with customers/users of the product and understands how the current product meets its purpose and what they need to implement next to solve the customer’s problems or help them achieve a better outcome with the product they are creating.

If you want to experience a Sprint Review where all the above mentioned suggestions get demonstrated, sign-up for our Lean Sherpas LeSSons Learned Newsletter. We allow our customers and clients to join our own Sprint Reviews and watch us in action.

Robert Briese

Robert is the CEO of Lean Sherpas and one of 25 certified LeSS Trainers globally and one of the few with hands-on experience in LeSS and LeSS Huge. As a change agent for 15+ years, consulting and coaching, he has worked with over 30 companies, including DAX-listed global brands such as Adidas, BMW, BP, Dr. Oetker, Henkel, Hilti, Hugo Boss, SAP, Volkswagen, and ZF.

From 2015 to 2016 he led a LeSS adoption at a Global Player in the Software Industry, scaling development from 3 to 7 teams and coaching the development and the management team on how to lead a scaled agile organization. In 2018 he contributed to significant improvements in product delivery at one of the biggest LeSS Huge adoptions in the world at BMW AG. Working with over 30 teams, including large groups of over 400 employees, he led them to deliver bi-weekly product increments consisting of hardware and software.

Robert Briese - LeSS Trainer LinkedIn profile.
MockUp of the Lean Sherpas Newsletter on a Galaxy S21.

Join the LeSSons learned Newsletter!

Early access to new content, real-world examples, and funny stories!

More content you might like

Published on 
October 21, 2023
Post by 
Konstantin Ribel

Konstantin Ribel and Craig Larman discuss how BMW's driverless driving team was built based on LeSS Huge, and the successes and problems encountered along the way.‍About the conferenceLeSS attempts to define what is just necessary for large-scale development. It avoids adding additional roles

Published on 
February 21, 2022
Post by 
Konstantin Ribel

Watch Konstantin Ribel discuss organizational behavior and performance and how LeSS can help manage organizational complexity. The orginal Video is viewable on the TC LeSS YouTube Channel. The original video can be seen on the TC LeSS YouTube Channel.