4 big ideas to improve your sprint reviews

• The developers present the work done in the last Sprint to the Product Owner and answer questions about the increment.
• The Product Owner accepts the elements that were “done” and decides what was not “done”.
• The team celebrates the achievement and moves on to the next event, Sprint Planning.

While all of these things are either mentioned in the Scrum Guide or are considered “good practices” in many organisations, in my experience something essential is missing: the will to really inspect and adapt the product, and to continuously focus on what to do next to maximise the delivery value.

And how can organisations get the most out of a Sprint Review? With the following four ideas:

• Involve real customers and/or end users in the Sprint Review!
• Have the Product Owner (or someone supporting them) provide insights into the product’s performance, existing schedules, budgets and market opportunities to gain the most relevant knowledge about the product!
• As much as possible, let customers and/or end users experience for themselves the features of the product that the team has implemented!
• Give each participant the opportunity to actively work on how the Product Backlog can be adjusted to reflect the feedback and work on what is most important next (with the Product Owner having the final say)!

I would like to go into these four ideas in more detail below:

Involve real customers and/or end users in the Sprint Review!

Scrum suggests including 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.

Often this is a sign that it is a component team focusing only on some technical parts of a particular system that need to be integrated with the work of other teams, which automatically leads to waterfall development. The only way to change this is to change your organisational structure to form feature teams that implement end-to-end customer requirements, as suggested by LeSS, for example.

However, even if feature teams are formed, many companies do not conduct the Sprint Review with real customers or end users because they are not sure how to find, motivate and involve the right people.

If you are developing an internal product (e.g. a CRM system), the customers should be the people who use the system. This means that it should not be difficult to find and motivate them to participate in your Sprint Review. If you are developing a product intended for the market, you will usually have a marketing department (if they are not integrated into the teams) and a select group of first adopters who love and use your product extensively – again, it should not be too difficult to include at least some people from these groups in your Sprint Review. However, if you do not have such people, you may want to reconsider whether it is worth investing more in product development.

Let the Product Owner provide insights into the product’s performance, existing schedules, budgets and market opportunities!

The Sprint Review should give everyone involved in the product idea, product creation, product delivery and product use the opportunity to assess whether the right product or features have been developed and delivered.

This is one of the most important parts of empirical process control. There is no point in delivering in short iterations if you do not thoroughly analyse whether you are working on the right things and change direction when you realise that you are not.

To assess this properly, you need to look at concrete data, such as

• how many users you actually have,
• how often new functions are used and, above all,
• whether the newly developed product features are having the desired impact.

I personally like to use techniques like Impact Mapping for this, but at the very least it is a good idea to prepare insightful data on product usage for all participants in the Sprint Review. This can be prepared by the Product Owner or delegated to other product managers, but of course the Product Owner needs to have a handle on the numbers in order to make important product decisions.

If there is an official release schedule, the Sprint Review is also an opportunity to clarify stakeholder expectations. Also, be sure to provide feedback on budget numbers that the Product Owner should manage as the person responsible for the product’s return on investment (ROI). Any other key insights about market changes and opportunities that are important to everyone involved in product development, product creation, product delivery and product use can also be communicated in the Sprint Review.

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

In practice, many teams struggle with this point. On the one hand, it is great to empower and motivate developers to present newly implemented features to customers and/or end users, but often corresponding demos have serious drawbacks:

• The developers show what they tested and what worked (or ideally what the automated tests checked).
• They usually explain how and why they would use the function in a certain way.
• Feedback is limited to a few people who notice something during the demo and are not afraid to mention it.

Instead of having developers present the newly implemented features, I suggest giving all Sprint Review participants the opportunity to experience the features as hands-on as possible. You can achieve this,

• by handing out a device to the participants,
• giving them the link to the software/application or
  placing some paper/digital prototypes on a (virtual) whiteboard.

It is often useful to include short descriptions or specific questions about the functions, so that you can subsequently receive targeted feedback that is valuable in terms of content.

This approach has several advantages:

• Developers can observe how customers actually perceive and use the product/features.
• Users are not influenced in their use of the features (reflecting the reality where your customers do not receive an explanation of each new feature when they use a particular product).
• The developers sometimes experience that the behaviour of the customers is quite different from what they expected, which helps them to find better solutions in the future.

Give every participant the opportunity to actively contribute to the adaptation of the product backlog!

In addition to giving participants the opportunity to experience the increment of the Sprint as hands-on as possible, you should also give them the chance to give as much feedback as possible.

I prefer to do this by making sure there are plenty of post-its and pens next to the unit or paper prototypes. And if I do the review virtually, I have the team take screenshots of the app screens to be reviewed on a virtual whiteboard, for example, where participants can then leave their feedback directly. Of course, you can also ask additional questions, e.g. which functions are currently missing or which functionality is desired differently. If you put this into practice accordingly, you will be amazed at how much valuable feedback you receive compared to a “pure demo”.

But the crucial part only starts when you have received all the feedback. Because as mentioned earlier, iterative and incremental development doesn’t make much sense if you don’t constantly adjust the backlog and make sure you’re working on the items that have the highest value to the business/customers based on recent feedback and current understanding. So you want to distil all the feedback and make a decision about it,

• What critical feedback you have and want to work on immediately (maybe in the next Sprint),
• what important feedback there is that you want to discuss and re-evaluate in a future Product Backlog Refinement, and
• Which feedback is not important at the moment.

You can do this by grouping all the feedback and putting the groups into different categories. Ultimately, the Product Owner should make the final decision on prioritisation, but the more participants you involve in reviewing, grouping and differentiating the feedback, the better they will understand the customer needs and the purpose of the product.

Conclusion

Use these 4 big ideas to improve your Sprint Reviews. These “simple” changes will give you highly interactive events where each product creator/developer interacts directly with and understands the customers and/or end users of the product,

• how the current product is serving its purpose and
• what they need to implement next to solve customers’ problems or help them achieve a better outcome with the product they are creating.

Notes:

If you like the post or want to discuss it, feel free to share it with your network.

If you would like to experience a Sprint Review where all of the above suggestions are demonstrated, sign up for the Lean Sherpas LeSSons Learned newsletter. Robert Briese is happy to enable customers and clients to attend real Sprint Reviews and see the Lean Sherpas live in action.

Robert Briese has published two more posts on the t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.