Sprint Demo Format
Beverly Denmark
Prepare to enter a world of endless possibilities. There are like 17 Ted Lasso Retrospective Formats, Gremlins, Barbie, and even the Great British Bake-off Retrospective formats. You name it, and it probably exists as a Sprint Retrospective Format, or someday, it will likely exist. Scrum practitioners seem to have a soft spot for Sprint Retrospective formats.
The Sprint Review is probably the most misunderstood Scrum event. Most falsely reduce it to a Sprint Demo where you showcase completed features. I believe it can be so much more valuable and useful than that.
You must tailor the Sprint Review to your context. Do what works best for your situation with the following question in the back of your mind: Are we collaborating in a way that improves our ability to deliver value? The Sprint Review format should provide transparency on the value your product is providing and the best opportunity to inspect and adapt to deliver more value.
These are some of the guidelines for a successful Sprint Review. I want to stress that you should treat these as guidelines and not as holy principles to follow no matter what. What works in your situation is always what matters most.
The Sprint Review adds another meeting without reducing other meetings. Ideally, you revisit your plans and roadmap once every Sprint. As the Sprint Review is quite a time commitment, reducing other meetings where timelines and roadmaps are discussed is important. This also prevents back-tracking, where you have to discuss the same topics with different people over and over again and make their difference of opinion your problem.
After the demo, you can explore how our product is doing, not by discussing features or delivery timelines but by examining product metrics. Is what we delivered in the previous Sprints moving the needle? Are we achieving the outcomes we set out to achieve?
Great article Marteen! I love the idea of a Product Review. I'll share it far and wide! 2 things - I'm not convinced about using the plural form of Sprint Goals in the context of one Sprint - smells of an antipattern. It might be worthwile to mention Liberating Structures as a way to improve Reviews - still not as many formats as Retros, but it's sth and sth good!
The current state of the Sprint Review is so sad that it is often even confused with the Sprint Retrospective. That might be unsurprising when dealing with people who are not Agile or Scrum experts, but I\u2019ve got news for you: including them doesn\u2019t make a big difference in interest in the Sprint Review.
Zip. Nada. Zilch. You\u2019ll likely find a few Sprint Review templates after some digging, but most of them will suck. Some are Sprint Retrospective templates mistakenly labeled as Sprint Review templates. Oops!
I\u2019ve also created a Sprint Review Miro template based on the ideas in this guide so you can immediately hit the ground running. The Sprint Review Miro was released a month ago and received a nomination for Best in Miroverse in the category Agile Workflows.
I dislike quoting the Scrum Guide because it creates the impression that it\u2019s the source of absolute truth we should all aspire to follow. First and foremost, we should be firmly anchored in the results we want to achieve. Adherence to the Scrum Guide only matters to the extent it produces the desired results.
To clarify, the sum of the increments is the whole product\u2014not just what you added in the previous Sprint. In an ideal world, what you\u2019ve delivered may already be live before the Sprint Review.
Your stakeholders will have already seen it and, if necessary, been consulted prior to the release. Releasing something provides better information than talking about something we can potentially release, that\u2019s why the Sprint Review should never be a gate to releasing value.
I want to stress that this paragraph of the Scrum Guide is phrased rather poorly. \u2018Presenting the sum of the increments at the Sprint Review thus supporting Empiricism\u2019 is an abstract statement. Presenting a product supports Empiricism much less than talking about data produced by the \u2018sum of the increments\u2019 aka your product, even of past Sprints.
In short, the Sprint Review should have been called the Product Review. We\u2019re not reviewing the past Sprint - we\u2019re supposed to check how our Product is doing holistically by answering questions like:
We should talk about the whole value our product is delivering, not just the past Sprint, because results are often lagging. I\u2019ve called these kind of Sprint Reviews, Goldfish Memory Sprint Reviews:
\u201CIn the movie 50 First Dates, Adam Sandler falls in love with Drew Barrymore. There\u2019s just a slight hitch\u200A\u2014\u200Ashe has amnesia and loses all the new memories she forms when the day ends. This prevents her from falling in love with Adam Sandler for longer than 24 hours.
Just talking about the previous Sprint isn\u2019t the only problem many Scrum Teams face at the Sprint Review. Unfortunately, since delivery is often such a struggle, the Sprint Review frequently devolves into a Sprint Demo, where we talk about what we\u2019ve done instead of shifting the focus to what we\u2019ve achieved with what we\u2019ve done.
Now that we\u2019ve hammered the point home that the Sprint Review\u2019s primary focus should not just be what we\u2019ve delivered in the past Sprint but trying to take a more holistic view of how your product delivers value, let\u2019s start by providing some guidelines for a great Sprint Review.
You don\u2019t have to demo features. Only demo something if you will get reliable and relevant feedback you can immediately act upon. A salesperson giving feedback on your product is not a substitute for actual customer or user feedback.
Think outcomes, not outputs. Sprint Reviews often take the teams and what we\u2019ve delivered in the past Sprint as the starting point. Who cares who did what and how much they did? A feature doesn\u2019t deliver value. What it makes possible delivers value, and that should be our primary concern.
If it\u2019s not done, don\u2019t demo it like it\u2019s done. It\u2019s okay to show something even if it\u2019s not done to get feedback, as long as it\u2019s crystal clear that it isn\u2019t done and the intent is to get feedback, not create false the illusion of progress. You will not get any points if you answer this in a Scrum exam, but the reality is more nuanced than the black-and-white answers, which easily fit in a multiple-choice format.
Keep it engaging and interactive. If it isn\u2019t lively and interactive, then you\u2019re either not talking about the right things, or you didn\u2019t invite the right audience. One-way traffic means you will leave the Sprint Review with the same understanding as before the meeting started, which is bad.
Everything is always demo\u2019ed. That most likely means you\u2019re performing delivery theater. People are busy creating and upholding the image that we\u2019re doing lots of work and moving mountains. The point is never to exert as much effort as possible. We actually want to do as little as possible while making as much of a difference as possible. The better we understand what we\u2019re trying to make possible for our customers and users, the better we can cater to their pains, needs and struggles.
Scrum Teams don\u2019t have clear goals. This is an anti-pattern in Sprint Reviews because goals provide guidance on what we\u2019re looking to achieve during the Sprint. If we don\u2019t know what we\u2019re trying to achieve, getting helpful feedback from stakeholders is difficult. The Sprint Review will become delivery and timeline-focused instead of concentrating on how we can create even more value for our customers and the business.
Lack of energy from participants. If everybody looks like they\u2019re falling asleep during the meeting, they probably don\u2019t consider the meeting valuable. Do we need to make the meeting shorter and discuss fewer topics? Are we discussing issues that the stakeholders aren\u2019t interested in? Every Sprint Review should be helpful, and if it isn\u2019t, then that\u2019s a symptom of something we should investigate.
Stakeholders should be talking, curious, and asking questions. If the Sprint Review is not engaging in an interactive, we won\u2019t get the feedback we need from our stakeholders. It must be a collaborative meeting, not a meeting where one party sends and the other only receives.
c80f0f1006