Why Effective Sprint Reviews Are So Hard To Achieve?
As we know, there are four main Scrum ceremonies: Sprint Planning, Daily Stand up, Sprint Review and Sprint Retrospective. Additionally, we also groom or refine the backlog (Backlog Refinement) which happens throughout the Sprint.
The Sprint Review is second to last ceremony in the Sprint. The purpose of the Sprint Review is for an Agile team to show their product increment to the Product Owner and business stakeholders. The idea is, for the team to demo their product increment, features or functionalities and engage the audience in conversation to understand how they feel about it, what they like or dislike about it, what they think is still lacking etc. In the course of this conversation, the team gets valuable feedback, which they use to improve the product in subsequent iterations.
Among all the Scrum ceremonies, the one that appears to be the weakest or least effective is the Sprint Review. There are many reasons why Agile teams struggle organizing effective Sprint Reviews.
1. The most critical reason is the inability of Agile teams to create their product keeping the big picture in mind. If one looks at the Product Backlog Items (PBI) of most Agile teams, they will not be surprised to see that many of those items, called “Stories”, do not give any value to the end user or customer. Even combining a few of these stories does not give much value. Having finished these components, the team demonstrates those bits and pieces to the business stakeholders. Not only is this boring for the audience, they also do not see much value in it. Imagine somebody is designing and creating a beautiful table, but only shows one leg and half of the top to potential buyers at an agreed upon date. Would you be excited to buy such a product? Will you even be motivated to come back and look at it unless it’s completely done?
I have often seen senior leaders and executives coming to a Sprint review for the first time when a new Agile team demonstrates their completed work. While these leaders praise the team for their accomplishments, you can see a confused look on their faces asking an unspoken question:
The senior leaders and executives eventually stop coming to the Sprint Reviews, as they don’t find them meaningful.
2. The second most important reason for Sprint Reviews to be not attended by senior leaders or relevant stakeholders has to do with the language used during the demo. What I mean here is, that a lot of Agile teams do the demonstration of their product in technical language. They bring up a screen with a Linux prompt and open the code, showing pieces to confirm on how the 
goal of a Story is achieved. While this could be attractive to other technical team members or even engineering managers, the business folks really do not get much value from it. This is akin to an audience that understands only Japanese, but being invited to a review of a product that is to be given fully in English. Just imagine bringing up a screen with English letters and words being displayed, with the hosting team speaking only in English. Will the Japanese stakeholders come back to such a Sprint Review? - NO!
It would be a good idea for the (Business) Product Owner to actually drive the demo. They can work with the team and also speak the language of business stakeholders. Enabling stakeholders to be able to directly interact with the functionality of a product rather than demoing technical code will also be appealing to them.
3. Sprint Reviews being held on the wrong day of the week. Ideally, the Sprint cadence should run from Wednesday to Tuesday or Thursday to Wednesday. The advantage with this 
cadence is that the starting and ending days do not fall on a Monday or a Friday - the days when people tend to be busy or not easily available. For example, a 2-week Sprint that starts on a Wednesday will end 2 weeks later on a Tuesday. However, many teams, especially new ones, without much experience, tend to start their Sprints on a Monday or a Tuesday. This results in Sprint Review falling on Fridays or Mondays (Ideally the last day of a Sprint) when senior leaders and relevant stakeholders are busy and unavailable, resulting in poor attendance.
4. I have also seen that there are certain scaling frameworks in Agile which tend to encourage many teams in organizing their reviews or demos together. I have seen such teams sitting in a big conference room for hours together doing their Sprint Reviews. This is a painful sight to see. Especially so, because most of these teams were component teams and did not have much understanding of how each other's work contributed to the bigger product. It is difficult to visualize senior leaders and business stakeholders sitting in such reviews for half a day. It would be considered a big waste of their time, and for this reason, attendance for such Sprint Reviews are low.
5. Lack of proper engagement of key stakeholders also results in poor attendance. Most teams call their Sprint Reviews as Sprint Demos. In fact, Sprint Demo has become the more popular name for Sprint Reviews. The whole idea of this ceremony is about engaging your customers and users for a meaningful conversation and taking important feedback that can be critical for the product success. But more often than not, hardly any conversation takes place. How do we break this barrier? One thing that comes to mind is, that, instead of waiting for the entire Sprint Review to be over, teams should take feedback after every item is reviewed. This will not only keep the stakeholders engaged, but will encourage them to provide valuable feedback for each item at the current time.
How often should we do Sprint Reviews?
Ideally speaking, Sprint Reviews should be held every Sprint. However, many teams only create components. They do not work by keeping the big picture in mind. Demoing these small components every Sprint does not bring much value to the end users, customers and business stakeholders. It might be worthwhile for such teams to do a more effective Sprint Review every few Sprints, where they have been able to combine the components from a few iterations into functionalities or features that can clearly demonstrate value and can call for valuable feedback. I know this is a revolutionary idea and will most probably be criticized by people “Doing Agile”. But, reflect on it for a moment or two. I am not saying that such teams (creating components) should not do an internal Sprint Review with the Product Owner and the team members to show their increment every Sprint. However, inviting executives and senior stakeholders to such reviews appears to waste their time, resulting in lower participation in future Sprint Reviews.
If the teams took this suggestion in the wrong way and to their heart, I would challenge them to start creating user story maps (journey maps) that feeds into a healthy looking Product Backlog. This will ensure that product or features are created keeping the big picture or systems thinking in mind and will result in slicing work so that functionality and features can come out every Sprint. This way, the Sprint Reviews will provide more value to senior stakeholders and business partners, resulting in them showing up at every Sprint Review.
Conclusion:
The Sprint Review is a difficult ceremony to master. A lot of it has to do with how teams are set up, how the work items are created, prevalent culture in teams and organizations. As a result, most of the teams end up demonstrating components that don’t show immediate value to the end users, customers and business stakeholders. As a result, Sprint Reviews are poorly attended and most of the time key stakeholders are missing. It could be beneficial to the teams to challenge themselves and their departments and organizations to create work items that show functionality or value at every Sprint Review. It also encourages the teams to become (more) cross-functional so that members can swarm together on completing a few stories (functionalities) every Sprint, resulting in higher value benefiting both the customers and the product organization.
Amitabh (Amit) Sinha is a servant leader entrepreneur, visionary, mentor, trainer and coach. Amit is highly passionate about Agile, its principles, values, and the human side. Amit is a people champion and strives to bring out the best in his teams. Amit leverages his expertise in Agile, Scrum, Kanban and people skills to increase team effectiveness and happiness. See more
