Take a look at your calendar. Are you invited for a Sprint Demo?
If so, this blogpost could perhaps be helpful for you and the Product Owner or Scrum Master who invited you.
In many occasions I hear Sprint Demo when it comes to the event in Scrum that should actually be called Sprint Review. You may say it’s just a word, but I’ve experienced myself it makes a big difference.
In this post I’ll tell you about my experience with the naming and give you some suggestions for the Sprint Review itself.
Demo vs. Review
Why should you avoid using the term Sprint Demo?
When you use the term Sprint Demo, people are misinformed and chances are they will not be prepared enough for this very important event. The word demo implies that something will be demonstrated or presented and that this demonstration is the core objective of this event. People will visit this session with the idea that someone will take the stage and talk them through something the entire time.
Sprint Demo doesn’t exist.
There is no such Scrum event.
If there is a need for a demonstration of the software, please demo it, by all means! In fact, this could well be part of your daily work, discussing new functionality with the concerned individuals.
Invite other curious people to your desk, show the working software and consider this moment as another refinement. If members of another team want to know a bit more about the features you’ve built or why you wrote a piece of code in a particular way, go ahead, demo the darn thing. This is all part of the empirical process and the important elicitation in Agile software development.
Unlike Sprint demo, Sprint Review does exist.
It is a formal moment at the end of each sprint.
Let’s see what the Scrum guide says about this meaningful Scrum event.
| A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration. |
Purpose
What’s the exact purpose of such an event?
The Scrum guide tells us this:
| The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. |
How do we get to this result? By demonstrating some new features? By telling the audience what you’ve done in the last sprint? Where the guests only listen?
No.
You can get to this result by having a Sprint Review, where people take part in the discussions and participate actively.
With another word: collaborate.
Collaboration
Every person in the room has a responsibility and needs to get his or her hands dirty. Some by guiding the session itself, other contribute with in-depth knowledge about the product or process, others by asking relevant questions. Everyone has their own perspective and frame of reference. Exhibiting these different views is a big part of the collaboration.
Product Owner
The Product Owner explains what Product Backlog items have been Done, what has not been Done and tries to get as much feedback about the product, market, users, etc. as possible to make sure he or she is prepared to go to the Sprint planning session and change priorities if necessary. The Sprint Review isn’t the only point in time where the PO can get his feedback. Please read my post Constant Pace about getting and using feedback frequently.
Development team
The development team builds the product. So, they are responsible for showing what they’ve done, what problems they’ve encountered, how they solved them and answer questions.
This part is the actual demo part of the review and is just a small segment of the entire session.
Scrum Master
The Scrum Master makes sure the session is time boxed, people show up and understand the purpose of this event.
Stakeholders
The stakeholders aren’t invited to just sit and listen to the Scrum Team.
They have the responsibility to come prepared. A sensible Product Owner will ask them for their feedback as stated above. These stakeholders have knowledge about the business goal, the process, the market and its changes and the use of the product, etc. By sharing any relevant information during the review, they help the PO and the team building the correct PBI’s.
Suggestions
What to discuss?
The development team should only show working software. Don’t use slides, mock-ups or other documents, because these things aren’t the product itself.
Of course, you can use these kinds of documents in refinements, they are without a doubt very useful, but not during the review.
Maybe the PO wants to briefly discuss the overall progress and uses the roadmap for illustrating it.
I’ve seen teams showing the velocity, presenting the number of bugs solved and even how individual team members perform. In my opinion, these aren’t topics for a review. If you really want to discuss these things, organise another sit-down with your relevant stakeholders.
Location
A Sprint Review can be held anywhere.
But my experience with development teams is that when you use a room where people feel safe and familiar, people tend to be more confident and outgoing. More questions will be asked, feedback will be ventilated easier, etc. This is beneficial to the Sprint Review and its result.
When the review is held at a big impersonal facility, where the distance between audience and speaker is larger than a few metres, you probably won’t get to the desired result.
Attendees
Only relevant people should be invited.
In my opinion, there should always be a valid reason for an invitation. It’s best if all attendees are somehow involved in the product itself. But a valid reason could also be the on-boarding of a new colleague who wants to learn about the implemented Scrum process.
By inviting too many people, the opportunity to really collaborate could be compromised. If you are in a situation where you have a big number of stakeholders, invite a representative who is capable and authorized to speak on behalf of a larger group.
By keeping the number of attendees small enough, the Sprint Review stays convenient and you’ll be able to stay on topic easier.
On topic
Stay on topic.
Don’t linger or be distracted from the main purpose.
If you have the feeling a certain discussion doesn’t contribute to the review, end it. Be transparent about this, it’s not blunt, it’s for the best.
Always have a review
There should always be a Sprint Review.
Many things can be discussed during the review, but in all fairness, its best to show working software and get feedback on it. Remember, a solved bug is also working software.
If there isn’t any working software to be shown, something is failing. Please discuss this in your retrospective. Figure out what’s lacking or causing issues and how to solve them.
In this hopefully very rare occasion, don’t cancel the review. Tell stakeholders why there is no software to show. By being open to them, you’re managing expectations in a professional manner.
During this rare review, stakeholders could have relevant information about the market, the PO could spend a bit more time talking about the roadmap, the users can have important news regarding a feature which is in production, etc.
Result
When there is a common understanding and agreement with the stakeholders about the probable PBI’s for next Sprint, the Sprint Review has reached its goal. If you’re working with mature teams and experienced stakeholders, this process is pretty natural. The content of the next Sprint will hardly be a surprise. When you’re just starting or you have stakeholders that aren’t familiar with the Agile way of working, it will cost you a bit more time. Take that time, educate the people around you, let them learn from you or another experienced practitioner.
Okay, let’s wrap it up:
- Don’t call this event a demo. People think they will be presented something and are just spectators and no interaction or contribution is needed.
- The demo is part of the review.
- Show working software.
- There is a shared responsibility. Everyone should contribute.
- The result is a revised Backlog that defines the probable PBI’s for the next Sprint.
- Stay on topic, don’t linger on.
- Never cancel the review.
