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