Spicing Up Sprint Reviews

Finishing Well

After all of the hard work that the team has put into delivering the next product increment it's important to keep up the good work and finish well.

The Sprint Review, or "Sprint Demo" as we usually refer to it, will be the team's opportunity to demonstrate everything they've accomplished this sprint so that the Product Owner and their fellow stakeholders can assess the outcome and start to collaborate on what to do next.

Hopefully it will be a time to celebrate success and hand out a few accolades and not a time to hang our heads in shame after failing to deliver on our commitments or to customer expectations.

In order to finish well the team still has some work to do.

Golden Opportunity

We consider all time with the customer to be "golden".

Not only is it an important opportunity to demonstrate to the customer that they are getting value for money and that you are making good progress towards their product and project goals but it is also a time to ask questions and listen to their needs, priorities, challenges and concerns.

It's a good idea to designate a "Scribe" to capture matters that arise during the meeting as well as any feedback given by the Product Owner or stakeholders - especially if there is an agreed action, unanswered question or any contradiction or ambiguity. The whole team should share this responsibility throughout the meeting to help ensure the Scribe doesn't get swamped and miss something.

Note: Recording on-line meetings can help but this may not always be possible.

Understanding And Adjusting To Your Your Audience

Recognise that not everyone in your audience may be technical, or have a full grasp of the requirements that you have lived and breathed for the last sprint. Some may also be unaware of the full functionality of the product you are building or the systems that interface with it.

Your demonstration needs to be mostly non-technical and be easy to follow and understand. You should aim to provide proof of understanding requirements and demonstrate the quality of what you built.

If you are demonstrating to a remote audience then you won't easily be able to tell who is paying attention or anyone who is looking confused. In such situations it's good to occasionally ask and check that everything is making sense.

Sprint Review Preparation

Preparation for the Sprint Review is essential and should feature in Sprint Planning accordingly. The greater the importance, the greater the level of planning and preparation.

Mixing it up in terms of the people involved can also help although it may take some people out of their comfort zone until they get used to it. We insist each team demonstrates specifically what they built but leave it to the teams themselves to decide who exactly will do that.

Having a script helps:

  • Understand the running order.
  • Know who is doing what (Host, Scribe, feature X, feature Y ...).
  • Ensure nothing gets missed.
  • Understand likely timings.

Again, depending on the importance, you may wish to rehearse your demonstrations.

Turning Something Dull Into Something Shiny

Sometimes functionality is just plain dull and needs to be mode more interesting to demonstrate. On some occasions it may also be quite challenging to demonstrate features, especially when there are no user interface aspects to the functionality or when error situations have to be contrived.

Creating supporting content can help:

  • Provide a pre-amble explanation of each feature prior to demonstrating it.
  • Explain the specific test scenario and data values used.
  • Add to the fun and make it more interesting or thought provoking.

Using a test harness can help:

  • Add a visual element to non-visual features.
  • Make it easy to customise your test scenarios during a demonstration.

We introduced a test harness to demonstrate our tax calculations to make it easier for the customer to see calculation inputs and outputs instead of squinting at raw JSON data structures. This also enabled us to prepare different scenarios in advance that could then be rapidly called up during the review.

Presenting The Finished Work

The aim is to provide a seamless, ordered demonstration of everything that has been built during the sprint that will be a positive experience for all involved. Having a designated meeting host can help the meeting run smoothly and keep timings on track.

However, things don't always go to plan, especially in remote demonstrations and you may need to have some kind of contingency plan and be flexible in the order of presentation to enable recovery from unexpected problems.

If you know that you have some non-technical participants and someone from your team rattles out a whole load of techno-babble then you may want to chip in and explain what was just said to ensure you don't lose any of your audience along the way.

Make sure any questions that arise are suitably answered and that any agreed follow-up actions are recorded as necessary.

Beware going off-piste during a demonstration unless the customer encourages you to do so. You may win a friend (😊) or gain a bug report (😒). Whatever you do, don't de-rail the meeting!

Provoking Feedback And Knowledge Exchange

Teams thrive on feedback so your sprint reviews should be provocative. Don't be afraid to directly ask for feedback and be prepared to receive negative feedback.

Encourage positive feedback from the customer by delivering positive feedback and accolades of your own. Sprint reviews are a great opportunity to honour people who have done great work during the sprint.

Sprint reviews are not just about feedback, they are also an opportunity to share knowledge so that both the team and customer can engage to exchange valuable knowledge.

Variety

However you go about spicing up your sprint reviews, remember that variety is the spice of life!

Agile Health Check - Sprint Review

Why not take the opportunity to give your Sprint Reviews an Agile health check?

#AgileHealthCheck

Healthy
  • Sprint review occurs at the end of every sprint.
  • Whole team involved.
  • Sprint review preparation activities feature in sprint planning.
  • Team has sufficient time and prepares properly for the event.
  • All sprint work has been successfully completed to the "Definition of Done" prior to the sprint review.
  • Time with the customer is treated as "golden" by the team.
  • Customer is correctly represented (Product Owner and stakeholders).
  • Meeting host assigned to oversee the running of the review.
  • Responsibilities vary each sprint review so all team members get to demonstrate features.
  • Script in place with running order and who is doing what understood.
  • Important sprint review demonstrations are rehearsed.
  • Target audience is understood with all content aimed and presented at the right level.
  • Supporting content helps to correctly explain what is being demonstrated during the meeting.
  • Demonstration is easy to understand and follow.
  • Sprint metrics are discussed to explain what has and has not (if anything) been achieved.
  • Meeting runs smoothly and all completed features are demonstrated and discussed successfully.
  • Product Owner and stakeholders attentive and actively contribute to proceedings.
  • Team attentive to customer needs, priorities, challenges and concerns throughout the meeting.
  • Detailed customer feedback captured by Scribe (supported by team).
  • Both the team and customer exchange and gain useful knowledge and feedback.
  • Product Owner and stakeholders happy that the Sprint Goal has been successfully achieved.
  • Team and stakeholders collaborate on what to do next.
  • Accolades voiced to honour those who went more than the extra mile to achieve sprint success.
  • Team successfully met / exceeded customer expectations.
  • Product Owner and stakeholders have confidence in the team.
  • Team and stakeholders celebrate success.
  • All customer questions suitably answered with agreed follow-up actions captured.
  • All agree that the sprint review was a good and valuable experience for all involved.
  • On-line meeting recorded (if possible).
  • End of sprint documentation and agreed follow-up action plan communicated to Product Owner.
Unhealthy
  • Sprint review does not always occur at the end of every sprint.
  • Not all of the team involved.
  • Sprint review preparation activities do not feature in sprint planning.
  • Team has insufficient time to prepare properly for the event.
  • Not all sprint work has been successfully completed prior to the sprint review.
  • Time with the customer is not regarded as "golden" by the team.
  • Customer is not fully represented (Product Owner and/or some stakeholders missing).
  • No meeting host assigned to oversee the running of the meeting.
  • Same people demonstrate features each sprint.
  • Script not in place to define running order or confirm who is doing what.
  • Important sprint review demonstrations are not rehearsed.
  • Target audience is not well understood with content sometimes presented at the wrong level.
  • Supporting content not used to explain what is being demonstrated during the meeting.
  • Demonstration is not always easy to understand or follow.
  • Sprint metrics are not fully discussed to explain what has or has not been achieved.
  • Meeting does not run smoothly and not all completed features are demonstrated or discussed.
  • Product Owner and/or stakeholders unattentive or do not actively contribute to proceedings.
  • Team unattentive to customer needs, priorities, challenges and concerns during the meeting.
  • Detailed customer feedback not captured.
  • Both the team and customer fail to exchange or gain useful knowledge or feedback.
  • Product Owner and stakeholders not happy or convinced that the Sprint Goal has been achieved.
  • Team and stakeholders do not collaborate on what to do next.
  • No accolades voiced to honour those who went more than the extra mile to achieve sprint success.
  • Team failed to meet customer expectations.
  • Product Owner and stakeholders lack confidence in the team.
  • Team and stakeholders not able to celebrate success.
  • Not all customer questions suitably answered or agreed follow-up actions captured.
  • Sprint review was not an enjoyable experience for those involved.
  • On-line meeting not recorded (if possible).
  • No end of sprint documentation or follow-up action plan communicated to Product Owner.

Like

Tim Simpson
30th June, 2021
#LifeAtCapgemini

« Previous Blog Post Blog History Next Blog Post »