Over the years I have seen sprint reviews turn into sprint demos. The paradigm of demo and review are very different, they each serve different purposes and they each require different levels of team engagement. In this blog we try to understand Sprint Review versus Sprint Demo.
What is the purpose of sprint review?
To actually inspect the increment and plan future adaptations, keeping product goal in mind and considering market conditions, feedbacks and changes.
What purpose does a sprint demo serve?
From my own experience with teams, I have seen sprint demos become a meeting where developers demonstrate the increment with the intent to seek approval/acceptance from product owner and stakeholders.
Sprint Review versus Sprint Demo
| Demo | Review |
| Developers present their work with the objective of seeking acceptance | Developers walk through the work with the objective of collectively reviewing the work from the perspective of “are we building the right product?” |
| Focus is to verify the implementation of increment as per the requirements | Focus is to review the increment developed based on the market needs and changes |
| Developers are focused on getting the acceptance and account each item towards their sprint velocity | Focus here is on completion of the item as per definition of done and its readiness to be released. |
| Product Owner and Stakeholders play the approver | Product Owner and Stakeholders review the increment along side developers |
| Developer operate from the paradigm of software developers coding as per requirements | Developers operate from the paradigm of product developers, where they focus on developing best product for the market |
| Usually characterised by a sub-team within scrum team, which is accountable for creating increment | Characterised by ONE Scrum team ownership. |
| Developers usually measured by the sprint velocity | Developers along with the whole Scrum team measure progress based on the value delivered against product goal |
| Co-operation driven – developers just develop what is being asked for | Collaboration driven – developers do not just develop what is being asked for, they engage into intellectual conversation of what features or what changes make more sense for the product. |
| Characterized by spoken or unspoken hierarchy | Characterized by NO hierarchy |
Most developers, coders or testers are used to implementing requirements as asked by customers. That is how we developed software in the waterfall world. This is also true for situations where one engages a software vendor to develop the product.
The paradigm for the software developers is to satisfy the product owner by coding as per the requirements defined by him/her. There is nothing wrong with coding as asked by the product owner. In fact that is precisely what is needed from the developers. However when these teams are measured based on the velocity or story point of work completed and accepted, their focus shifts to getting as much velocity as possible.
Product development requires much more intellectual collaboration within the scrum team, instead of just developing whatever is being asked for.
What prevents a scrum team from truly doing sprint review
- The spoken or unspoken hierarchy in the scrum team
- Teams measured and compared on sprint velocity
- Contracts which are based on velocity, in situations where external vendors are engaged as part of the scrum team.
- Waterfall Mindset of software developers, who find it hard to think as a product developer or be able to see the business side of a product.
Share your views on Sprint Review versus Sprint Demo below in the comment.
Read our other blogs on Scrum
30 Basic Scrum Interview Questions
What Is The Most Important Responsibility Of A Scrum Master?
