Do you do Sprint Reviews, demos or a mix of the two? Are you doing it wrong? Not knowing can be costly. For example, do feel that you have to sacrifice features to prepare for your demos or Sprint Reviews? Sadly, many Agile teams do. Let’s see how we can avoid that by understanding the difference between those two events.
A common error when applying Scrum is to treat the Sprint Review as a traditional demo. Understanding this as problematic is important for many reasons, efficiency being the main one.
If you are using Scrum methodologies, you absolutely need Sprint Reviews while, depending on your context, you may or may not need demos. This being said, we get to our burning question: What is the difference between a Sprint Review and a demo? The answer starts by comparing the reasoning behind each event. The Sprint Review enables the Scrum Team to show the advancements of the sprint, both from the user’s perspective and from the developer’s perspective. The demo, on the other hand, has more formality and presents a selection of working capabilities. The Sprint Review focuses only on the sprint content while a demo can, and often does, demonstrate capabilities across many features logically grouped (ex: end to end use case or all features related to user management).
Yet, both meetings share a common trait, which might be the source of the confusion, as they both are opportunities for stakeholders to give their feedback and thus influence prioritization. It sounds simple and yet many, in an Agile context, are confusing both events.
Classic mistakes when approaching Sprint Reviews:
- Demanding full demos to the Dev. Team: This often results in the investment of the last 2-3 days of the sprint in preparation for the Sprint Review “demo”.
- Only showing the user-facing advancements: The Dev. Team often has technical advancements or, minimally, can also describe the user-facing advancement from their point of view. It is important for the whole Dev. Team to understand the current state of development.
- Not having Sprint Reviews or skipping Sprint Reviews: This often happens with junior Agile teams which are, either not closing clean sprints (feeling the need to keep on working), or not engaged yet in the Agile methodologies (not understanding the need or goal of the Sprint Review). Failing to do Sprint Reviews removes a critical piece of the Scrum loop. It would take an entire blog post to explain all the impacts.
Classic mistakes when approaching demos in Agile:
- Planning to demonstrate features that are not completed (not DONE): Many reasons may have contributed to create such a situation and I would recommend resolving this. Nevertheless, the result implies investing effort on the creation of demo-quality features instead of staying focused on the backlog. Not driven by production development objectives, those demo-quality features are often hacks and technological debts that will set the project backward further than before the demo.
- Using the demo as a surprise inspection: In Agile/Scrum, visibility on the advancements is systematically done at each Sprint Review.
- Using the demo to force completion, integration and testing of features: In Agile, this is handled by the Development Team’s Definition of Done and the execution of clean sprints (i.e. closing stories and not generating technical debts).
All that being said, demos have a reason to be and they must coexist with the Sprint Reviews. Let’s look at some tips and tricks to make your next Sprint Review and demo relevant, effective and efficient.
Sprint Review
- Preparation for the Sprint Review should not take more than 15 minutes per Dev. Team member.
- Demonstrate the same way you have tested during the sprint.
Focus on the goals of the sprint review
- Show advancements to the users & stakeholders. This is normally done by the PO.
- Share development advancements done by the different Dev. Team members.
- Get feedback.
Demo
Aim for zero development effort cost. Invest this effort in the development of new features instead. You can drastically lower the cost of demos by doing the following:
- Only demo what is DONE (i.e. The results of previous sprints. Not ongoing, incomplete or future developments).
- Demos should be prepared and given by the PO, a domain expert or super-user in a production-like environment.
Still, if the Dev. Team is needed for a demo, do the following:
- Confirm how many demos the stakeholders needs.
- Create demo stories in the backlog.
- Calculate the cost of a demo by estimating the demo stories in points.
- Continue to manage the whole backlog by business value. This means the PO may have to choose between a feature story and a demo story. Depending on the situation, one will have more value than the other. With all this information, the PO will then be able to maximize the value by prioritizing the backlog.
Phillipe Cantin
Comments are closed.