I once asked a friend of mine ‘What would be the one thing you would change about Scrum?’ He pondered with that question for a short time and then responded. ‘I would change the name of the Sprint Review’.

This intrigued me and followed a conversation that reminded me of a few core principles that I had pushed to one side in my mind.

Quite often I hear teams refer to these sessions as a ‘Show and tell’ or a ‘Demo’. I had never felt passionately about a name before until I had spoken to my friend. I thought back to the sessions that I had been seeing recently and wondered, were they just a demo or were we truly collecting feedback?

The Sprint Review is actually a form of retrospective.

It is about:

• The Product Owner telling the stakeholders what it is we have achieved against the Sprint Goal
• The Product Owner advising of any key decisions that have been made in the Sprint
• The team facilitating what changes have been made to the product
• The stakeholders asking questions and providing feedback. With the team and Product Owner filtering changes back through the Product Backlog
• Confirmation of when the Stories will be shipped
• Any discussion on the future strategy of the Product
• The Product Owner closing down the session and advising the candidate stories for the next sprint

In preparation of the review the team would have completed the Sprint to the Definition of Done and spent no more than an hour or two preparing for the Sprint Review (depending on length of sprint). These are informal sessions and there is no expectation to create flashy power points.

Work that is NOT DONE is NOT SHOWN…..

As with all ceremonies, they should be a regular heartbeat and the customers know when to expect them. The same time and the same place every 2 weeks is the dream, but sometimes tough to achieve.

As a ScrumMaster I would expect the team to self-organise over the Sprint Review. I might add a task to the Sprint Backlog during planning as a reminder to the team that this needs to be prepared for.

I have once let my team fail here. In one company I got fed up of reminding them to prepare for the Sprint Reviews and so one day, I just didn’t. Let’s just say that didn’t happen again

When running large reviews, it is critical to be prepared. Often I book the meeting room 15 minutes before the allotted time so the team can go in, set up the machines and open any tabs that they might need. I am always conscious that we have lots of people and so avoiding time spent on waiting is something we can always do with removing.

If you find that you are not getting people attending the Sprint Review , then think about your advertising. As a ScrumMaster I have put up posters, gone to visit stakeholders 121, sent mails around the office, floor walked inviting people that might have an interest or dependency.

In larger organisations where multiple teams rely on the same people, then you need to collaborate and find out what would work best for your attendees. You might need to experiment with this.

Ultimately, I do what it takes to get people to the Sprint Review.

Once the team have shown the fruits of their labour, we then need to do the most important part. The part that is always forgotten……collecting the feedback.

In an organisation recently I experimented with giving them post it notes and the format

• What did we like about these features?
• What didn’t we like about these Features?
• Great ideas to improve?

They did look at me a little crazy as this was something radical to them, but it ultimately got them to think about what we had just shown and enabled the Product Owner to get valuable feedback on where to head next.

How do you collect feedback in your Sprint Reviews?

At the end of the meeting the Product Owner should then give the attendees a view of the candidate stories for the next Sprint. I impress the word ‘Candidate’ on you because they are not confirmed until you have completed Sprint Planning.

Remember, the Sprint Review should not be the first time your Product Owner has seen the work. They should be looking at this regularly during the sprint, as with bringing in stakeholders to get early sight. Nothing in a Sprint Review should be a surprise!

I am often asked ‘What do we show, if there is nothing to show?’

This is an interesting question and a great one to exercise the 5 whys on:

• Why do you have nothing to show?
     - Because the testing was not completed
  
• Why was the testing not completed?
     - Because the developers did not get the work to us until the last day (hopefully you spotted the dysfunction there!)
  
• Why did the developer not complete the work until the last day?
    - Because we did not get everything we need from the PO (Dysfunction)
    - Because the story was too big (Dysfunction)
    - Because the PO changed their mind mid Sprint (Dysfunction)

You get the picture. Remember what I about the ScrumMaster remorsefully looking to establish and remove dysfunctions of the team? There are visual and verbal clues over everything you do.

Other things to watch out for is where teams are not vertically slicing and so just delivering component parts. I also had this at an organisation recently. The question I ask them is ‘If I pulled the plug on your feature right now, what value have I got for my money?’ Because if I was truly being iterative and incremental, I would have still got something I could sell…right??

If I pulled your Sprint right now, do you have something that could still be used?

On the odd occasion there is a small config or non-client facing change, then assume your attendees don’t want to see physical code. Remember they are likely to be from the business. In this instance it is perfectly acceptable to just explain in plain English the change you have made and move on.

Another beautiful technique I saw a team do was story cards. One of the developers created it and used it to explain to clients complicated technical code changes that sat deep in a system. It was his way of articulating what they had done.

See the blog here for more details: http://tlaalt.blogspot.co.uk/2015/07/describing-value-using-situation-cards.html

Other tips

• Consider if your stakeholders are distributed having two way video so you can see what they are doing and reactions to the product.
• Consider actually getting some interaction from your stakeholders. Invite them to play with the product in real time.
• You do not need to tell your stakeholders how many story points you completed.
• You don’t have to justify why stuff was not done.
• As ScrumMasters we can help this practice to be clear, transparent and engaging to the attendees. Use the walls and visualisation to help the session.
• If the Product Owner cannot facilitate the Sprint Review as they are out of the office. Ask for a volunteer to do this the same as any other the session.
• NEVER CANCEL! I have only ever cancelled 3 in eight years and 1 of those was because it was Christmas.  If you are cancelling these, its probably because you are hiding something.

If you take one thing from this blog, then that should be.

‘The Sprint Review is more than a demo, it’s about gathering feedback, inspecting and adapting’

My friend suggestion for renaming was ‘Sprint Product Retrospective’

My friend, is the funniest man in Agile….Nigel Baker

Finally….

I asked Paul Goddard for a tip of the week. He said ‘Listen with your eyes closed, you hear much more!’