In an Agile enterprise, the Sprint Review and Sprint Demo are important activities of a Scrum. However, even the most practiced Scrum professional tends to mix Sprint Review and Sprint Demo – more though there is a close association between the two. The truth is that one is vastly different from the other. In this write-up, we will find out more about Sprint Demo vs Sprint Review.
To begin with it is important to understand that the Sprint Demo is usually a part of Sprint Review.
What is a Sprint Review?
This is held at the end of a Sprint but the purpose is different from that of the Demo. The objective is to go through the increments to the product during the Sprint and discuss and revise the Product Backlog accordingly. So, the explicit purpose is to get feedback from the team and is usually conducted by the Product Owner.
What is a Sprint Demo?
It is that part of the Sprint Review meeting where participants come prepared to see something – the demo of the last increments. It is the opportunity for the Scrum Team to showcase to Stakeholders and the Product Owner, things that have been done in a Sprint. The Product Owner on his part needs to showcase work that meets the predetermined Stakeholder needs. Feedback is shared, details of the next Sprint are discussed.
Understanding the difference between Sprint Review and demo
|Characteristics||Sprint Review||Sprint Demo|
|Who presents primarily?||Product Owner||Product Owner|
|Relevant Stakeholders – software Development Team, a cross-functional team from sales, operations, engineering and external Stakeholders like investors, customers, etc.||The Product Owner and other concerned internal Stakeholders.|
|What type of a meeting is it?||Formal Meeting||Casual Meeting|
|Duration of the meeting||
The meeting goes on for about 4 hours in case of a monthly Sprint Review meet.
However, if the Sprint is shorter than a month, then the duration of the Sprint Review is shorter.
|There is no specific duration in Sprint Demo but this will be shorter.|
|Role of Product Owner||
|Role of the Development team||Once the Product Owner briefs everyone about the status of the current Sprint, the Development Team then demonstrates the functionalities and answers questions.||The Development Team is the main organizer of the Sprint Demo. They showcase the ‘done entity’ to the Product Owner and other Stakeholders.|
|What are the elements of Sprint Review?||#1 – Product Owner starts by telling everyone present on the ‘Done’ items and items ‘not Done’.
#2 – The Development Team then talks about their experience during the Sprint; what all went off well and what did not; the problems that crept during the Sprint; and the way these were resolved.
#3 – Next, the Development Team carries out a demonstration to show everyone what has been ‘done’.
#4 – The Development Team will then answer questions from those present about increments.
#5 – Next, the Product Owner takes over and discusses the current status of the Product Backlog.
#6 – If required, the Product Owner revisits the target and the timeline depending on the present status of product development.
#7 – now, the discussion opens for everyone. They decide on the next course to action. The objective is to offer inputs and insights for the upcoming Sprint Planning exercise.
#8 – the Sprint Review is also about reviewing the potential user or the market to understand if there are changes in their need and preferences, depending on which the next to-do gets decided.
#9 – Finally the schedule, budget, the user and the potential capabilities are reviewed vis-a-vis the next functionality to be released.
|#1 – The entire development team prepares to demonstrate the features of the product.
#2 – It is the ultimate test time where the Development Team needs to show-off everyone present the value-driven features developed.
#3 – The purpose should be to make the demo as interesting and engaging as possible; and avoid making it boring and unfocused.
#4 – The team gathers around to demonstrate on what has been ‘done’ to tell everyone if the developed product meets the acceptance criteria.
#5 – Since the entire Sprint Demo is focused on the actual demo, there are lots ** preparations to be done. It is important to use test data and tools to be one-hundred percent sure of the criteria being met.
#6 – The demo should be about narrating a story. That is why great Sprint Demos are about carrying for the demonstration using realistic user problem.
#7 – The purpose of the Sprint Demo is about showing how user problems get solved using the product. It should not merely to show-for the features and functionality of the product.
#8 – One of the main elements of the Sprint Demo is to show how the product adds value. Hence, the demo is ideally kept short, covering few acceptance criteria at one time.
The output of a Sprint Review are:
The output of a Sprint Demo are:
|Why is it important?||Sprint Review is about inspecting the current Sprint, the Product Backlog. It is also about adapting Product Backlog and the new release plan.||
Sprint Demos is the best way to ensure QA of the product because there is an exchange of ideas on how to better the product.
It is also the best way to let across different departments and roles know what to expect from the product – it is the right platform to formally share information with cross-functional teams.
|Strategizing for best results||
Now that we understand Sprint Review vs Sprint demo, let us see why both are so vital for a Scrum team.
The Sprint Review is about reviewing the product that has been developed. It is essential to get feedback, which in turn helps refine items in the Product Backlog. Sprint Demo, on the other hand, is about demonstrating what has been developed in the current Sprint so that there can be constructive discussion from all involved Stakeholders with the Scrum team about how to better the product and accordingly amend items in the Product Backlog.
To summarise, both processes should be part of a Scrum-based development environment. They certainly do not mean the same thing and cannot be used interchangeably. Each has its own essence – in the end, both are essential for smooth and optimized use of an Agile organization’s resources.