So your Sprint Reviews have turned into Garbage? ... here is how to step out of the dumpster!

Sprint Reviews are held at the end of the Sprints for a few very specific and very important reasons, which if missed or perverted, would turn the entire event into a waste of every ones' time and would lead to misaligned work that would be doomed to fail in the market.

Left unchecked, they can drift away from a great window of opportunity for the entire team to set pace and scope for re-targeting the market with the next best thing, into an expanding black hole, sucking everyone's energy and morale into oblivion.

Let's take a closer look at why Sprint Reviews are held and what is expected to come out of them.

Sprint Review’s main purpose:

To get the stakeholders to see (and possibly interact) with the completed work (as the outcome of the finished Sprint) and collect their feedback on that, and get everyone to collaborate on deciding what is the next best thing to do (based on current status and what they predict the market will need) and updating Product Backlog to reflect that.

It is the Sprint End ceremony in order to Inspecting and Adapting the Product Backlog (i.e. re-aligning the work with what market / customers want now)

During Sprint Review, Scrum Team and Stakeholders Collaborate on review of What was DONE (Increment) during the Now-Complete Sprint and Collaborate on What needs to be DONE in the Upcoming Sprint to Maximize Business Value Delivered.

As per Scrum.org, The Sprint Review includes the following elements:

1. Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
2. The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;
3. The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
4. The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
5. The Product Owner discusses the Product Backlog as it stands and projects likely target and delivery dates based on progress to date (if needed);
6. The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
7. Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
8. Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product. 

The Result of the Sprint Review:

A Revised Product Backlog that defines the probable Product Backlog items for the next Sprint. 

THE TOP TEN SPRINT REVIEW ANTI-PATTERNS TO AVOID

If you are already having trouble with your Sprint Reviews, chances are your sessions are suffering from one or more these top ten Anti-Patterns:

1. Not holding any Sprint Reviews

Sacrificing Sprint Review due to shortness of time (last minute code development or production bug fixing which get everyone running to the release and no time to hold any Review events before the next Sprint’s planning)

Cancelling Sprint Review because there is Nothing to Demo (even if due to a variety of reasons, the increment did not complete and is not ready for a Demo, there is still much more agenda items for the Sprint Review session to be held)

2. Turning Sprint Reviews into Reporting Sessions

Moving away from the essence of collaborative review of the work and deciding on what is the Next Best work, towards a stats of the work done (e.g. “We delivered this Sprint: 24 Stories, 8 Bug Fixes, 10 BAU work items for a total of 57 Story Points) which will not tell your stakeholders anything about what was really DONE and delivered.

3. Sleep Therapy Session

Putting the entire session to sleep by a prolonged boring presentation of screenshots of the increment (without any live demonstration of the work, or allowing stakeholders to play with the completed functionalities) done by just the Scrum Master or Product Owner as the main agenda of the Review session.

4. Surprise Party

Happens when Development team suddenly reveals during the Demo that they have done extra – yet unwarranted – work that was not part of the Sprint Backlog and was never discussed with the Product Owner.

This is a damaging behavior at many levels, as it would create trust issues between stakeholders and the team, and distorts Product Owner’s relationship with the Development team, as well as injecting work that has not been previously accepted by the Product Owner into the increment.

5. Ghost “Dev” Town

This is when we don’t have the needed Development team members attending the Review and the Demo, which can be due to a few reasons, including:

They are dealing with a prolonged overworked status, last minute code developments or Production bug fighting that has burnt them out.

They have lost faith in the value of Review sessions since historically it had not have much outcome in the sense of collecting feedback and decision making on the next best work.

6. Only Works on Developer’s Machine

This is when what is being demonstrated to the stakeholders is not really DONE (Deployment Ready) and would only run on a Developer’s machine (since it has not been yet integrated with the rest of the system, nor has it been tested for it and there is no build ready for deployment).

7. Missing Stakeholders

This is when Stakeholders are not attending the Sprint Review sessions which creates a disconnect between the Development Team and Customers (or their Reps) over the work that is completed and the next step to be decided on. This may have a few reasons:

They may not be invited (Product Owners may think that them being the liaison between Business and the Development team is good enough so why make the session crowded?)

They may have lost faith in productivity of the sessions due the historical disconnect between their collaboration and the work that gets done at the end.

They may not have fully grasped the value of their collaboration in the Sprint Review due to lack of familiarity with Scrum and how it works (they may work in Waterfall environments).

They may be overwhelmed with work and shifting priorities in their own side and skip the sessions as a result.

8. Sprint Gating (Scrum Fall)

This is when Stakeholders are confusing the purpose of the Sprint Review with a Project Gating review session and instead of keeping the session in its informal setting and participating in feedback gathering and deciding on the next best steps, they think they are asked there to sign-off on the work that is done.

9. Silent Treatment

This is when Stakeholders are acting as spectators and refrain from sharing feedback or participating in the joint review work and setting the next best steps for the product. The reasons behind this behavior can be from lack of faith in the initiative to fear of backlash if the next increment turns out to be a failure in the market. 

10. The All-Knowing-PO

This is when the Product Owner believes he / she can cover the role of Stakeholders during the review session and provide all the feedback needed on the completed Increment.

This also applies to when Product Owner, Omnipotently decides on what needs to be built next, without participation of Stakeholders in the conversation during the Sprint Review sessions. 

The Sprint Review is the opportunity to Inspect and Adapt key success factors in delivering value to the customers.

Inspect

• Sprint
• Product Backlog
• Increment
• Marketplace
• Budget
• Timeline
• Capabilities

Adapt

• Product Backlog
• Release Plan

This is a good opportunity for the management to see the work completed and participate in the review activities to get an updated insight on the alignment of the work, and what they teams needs in order to succeed.

Now you may say "Hey! our management is too busy to attend 10 Sprint Reviews held by 10 different Scrum Teams!"

To that I would answer "Either they need to attend each one of them to get a full and current spectrum of their entire production delivery force, or to have a follow session with POs to review the summary of the sessions.

They need to know what is happening in their teams and how they can help!

Let's close this conversation with some good Sprint Review Practices

• Keep it as an informal meeting (like a meetup or expo), where the "DONE" increment is showcased on machines where the end-users (and generally all stakeholders) can interact with the newly completed work.
• Have refreshments for the attendees (if it runs over their lunchtime, some light lunch would be a good idea)
• Solicit and gather feedback (over the completed work) and ideas (for the next increment).
• Let the Development Team communicate directly with end-users (or their Reps) and stakeholders and gets direct feedback from them.
• Make sure the Product Backlog is updated after or during the Sprint Review, based on the gathered ideas.
• Try your best to have end-users attend the session (or at least Reps closest to them).
• Keep it fun, yet focused on the purpose of the meeting.

Celebrate the Achievements (through a mini party at the end of the session) but never mourn the losses and failures! They are your lessons learnt and your chance to do a better job next time!