We have begun the content migration to the new website based on the Kentico 10 platform. Dual-entry of items is required for content which has migrated. For details see the migration status page.

Get certified - Transform your world of work today

Close

Stop Calling Your Sprint Review a Demo—Words Matter!


Okay I’ll admit it; I believe vocabulary is important. My publisher almost freaked out when I submitted a 22-page glossary to be published in my Essential Scrum book. But, I felt it necessary to define every relevant agile, Scrum, and software-development term that I used—both as an aid to the reader and also to ensure that I used the terms in a consistent way throughout the book.

The words we use can inform both our understanding and our actions. Which brings me to what I really want to discuss. In my experience working with many Scrum teams, people more often than not refer to the sprint review as the sprint demo. This may seem like a simple example of word substitution: “Aren’t review and demo the same thing?”

Mistaking the Means to the Goal with the Goal Itself

No, in my opinion they are not. Calling the review a demo tends to refocus the activity on a means to the goal instead of on the goal itself. Giving a demonstration of the working software that the Scrum team just got done is a common practice at most sprint review meetings. But let’s not mistake the goal of the sprint review for a practice we might perform to achieve the goal. 
 
The goal of a sprint review is not to give a demonstration; rather, the goal of the sprint review is to inspect and adapt the product that is being built. In my experience, teams that call the meeting a demo believe that the only goal of the meeting is to give a demo. And, therefore, a successful demo equals a successful meeting! This misses the whole point of a sprint review! Let’s see why.

Anatomy of a Sprint Review

The following picture will clarify how I view the sprint review activity.

 Visual AGILExicon - Sprint Review
You can download a hi-res copy of the Sprint Review and other images from the 
Visual AGILExicon® at Innolution.com
 
At the top of the picture you will see that there can be many participants at a sprint review. On the left of the picture are the inputs: the sprint goal and sprint backlog, which collectively define what the team planned to do this sprint. The potentially shippable product increment is what the team actually got done.
 
Now look at the icon in the center of the picture (the two orange arrows with the blue cube in the middle). It represents the sprint review itself. Notice that the focus of the sprint review is to inspect and adapt the product increment that was produced during the sprint.  More specifically, we inspect what was just built and, based on the feedback that we get from our stakeholders, we can adapt what we build next by grooming the product backlog, which is shown as an output on the right side of the picture. Large adaptations (pivots) to our target product might also cause us to update our release plan.
 
Below the sprint review icon I illustrate a common approach for conducting the sprint review meeting. In this approach the first step is to review the goal and committed/forecasted features and compare that to what actually got accomplished during the sprint. Next you’ll see a demonstrate step. This is where the team members often demonstrate what they built. So, in this picture, giving a demonstration is simply one step of the overall sprint review activity. The real purpose of the demonstration is to enable the next two steps: discuss and adapt. The demonstration is useful to the extent that it enables a thoughtful discussion on what we just built and its ability to inform any changes we would like to make for what we will build in the future.
 
To be clear, the most important aspect of the sprint review is the in-depth conversation and collaboration among the participants, not the demonstration. These discussions enable productive adaptations to surface and be exploited. A review isn't a one-way flow of information, where the team is doing all of the showing and telling. It's an opportunity for the Scrum team members to get feedback from customers or users. The sprint review therefore represents a scheduled opportunity to inspect and adapt the product. If you are interested in exploring the sprint review in more detail, I refer you to Chapter 21 of Essential Scrum.

Reviews Without Demos

I’ll end with an example to re-emphasize the point that giving a demo is simply one means of enabling the inspect-and-adapt goal. Some teams don’t use demos at all.
 
I work with several game studios. At their sprint review meetings it is often more effective to allow the stakeholders to just play the game instead of team members demoing it (essentially playing it for them). In one instance I recall the team members were all set to give a demo of the new game features and one of the principal stakeholders said, “Move over, I’ll drive. Let me play and see if I think it’s fun!”
 
So, if you are calling the sprint review the sprint demo, I strongly suggest you stop. Keep in mind that the real goal is not to give a demo, but to inspect and adapt the product. What do you think? Please leave your comments below.

Article Rating

Current rating: 4.5 (10 ratings)
To leave a comment, please login with your scrumalliance.org credentials.
Comments
incognito spammer
spam test, spam, spam, spam
10/5/2016 3:12:30 PM

Incognito Spammer
spam test, spam, spam spam
10/5/2016 3:10:18 PM

Kelli Davis
testing, testing
10/5/2016 3:05:40 PM

Kelli Davis
testing, testing
10/5/2016 3:04:49 PM

Kelli Davis
test, test
10/5/2016 3:04:09 PM

Kelli Davis
testing, testing
10/5/2016 3:03:20 PM

Kelli Davis
hey, test
10/4/2016 3:38:33 PM

Kelli Davis
hey, test
10/4/2016 3:37:02 PM

Kelli Davis
hey, test
10/4/2016 3:36:23 PM

Kelli Davis
test
10/3/2016 2:38:58 PM

Kelli Davis
test, comment.
10/3/2016 2:35:38 PM

Kelli Davis
test, comment.
10/3/2016 2:31:33 PM

Kelli Davis
test, comment.
10/3/2016 2:30:52 PM

Kelli Davis
test, comment.
10/3/2016 2:29:46 PM

BM Test
another test
9/28/2016 2:41:45 PM

BM Test
test 1
9/28/2016 2:41:18 PM

BM Test
TEST 4
9/28/2016 2:35:44 PM

BM Test
TEST 4
9/28/2016 2:35:21 PM

BM Test
TEST 4
9/28/2016 2:34:54 PM

BM Test
TEST 4
9/28/2016 2:34:12 PM

BM Test
TEST 3
9/28/2016 2:33:45 PM

BM Test
TEST 2
9/28/2016 2:33:16 PM

BM Test
Test
9/28/2016 2:32:33 PM

Fabiana
Link missing in previous post: http://www.conductor.com/nightlight/rearchitecting-sprint-demo/
5/27/2015 7:40:21 PM

Fabiana
Here is how my company does sprint demos, they are very interactive and informative
5/27/2015 7:38:55 PM

Ajie
Hi Ken,
Thanks for this nice article. We figured out that standup meetings are great but needed improvement (they took a lot of time and de-focused our colleagues). Because of this we developed a SaaS tool to "automate" the daily standup meetings - with just a single email. If you like to take a look: www.30secondsmail.com.
Best,
Ajie
5/21/2015 4:07:19 AM

Ken Rubin
Thanks Matt. Glad you agree. Definitely the discussion and the potential adaptations are the important part!
5/17/2015 6:36:51 PM

Matt Adams (ba-guru.com)
Hi Ken,

This is really good clarification of a sprint review so thanks for that.

I'm a BA and would probably say our Sprint reviews are too along the lines of a demo but i think the adapt and discuss section are vital so we may need to provide more time for this.

Cheers,
Matt
5/17/2015 3:23:49 PM

Ken Rubin
Hopefully, Dereke, they at least give you good feedback that you can use to inspect and adapt during their "demo!"
5/15/2015 8:32:11 AM

Dereke Garrett
I totally agree with you. A lot of upper management at my job refers to the sprint review as demo and I've never been able to wrap my head around that. As you said, this is more than a demonstration.
5/12/2015 11:18:44 PM

Ken Rubin
Excellent summary Samir!
5/8/2015 4:02:35 PM

Samir Umrikar
This is a great Article. I agree..it is one more forum for collaboration.
5/8/2015 7:54:00 AM

Eric Yang
Hi Ken,
Participants of Part 1, sprint demo, were development teams, POs, and anyone who was interested in our product such as product support group. In part 3, product managers (PO) and department managers reviewed the progress of portfolio management items.
Recently I attended a product owner training/coach session, the CST told us Sprint Review meeting should be working software demoed and hosted by product owners to internal stakeholders and external customers in order to get first hand feedback. Can you please clarify it?
Thanks,
Eric Yang
4/10/2015 3:02:09 PM

Ken Rubin
Harishankar, I fully agree with you! Our vocabulary certainly matters, and it can influence how we interpret a situation.
4/10/2015 12:57:24 PM

Harishankar Rajagopalan
Completely agree, sometime words create a perception that defeats the purpose of an activity like Sprint Review. Individual mindset is always crucial for Scrum and this is one good example.
4/10/2015 10:10:16 AM

Ken Rubin
Hi Richard, I agree... Definitely not a status update meeting for PM types!
3/27/2015 8:05:40 AM

Richard Henderson
I have used the title 'demo' to emphasise that it is not a 'status update meeting' for PM types. It is for stakeholders and team. Bit I agree, it is a review.
3/27/2015 12:42:01 AM

Ken Rubin
Hi Nathan, glad you found the graphic helpful. Good luck with your team!
3/24/2015 8:39:53 AM

Nathan Pettit
I really like your point about demo not being enough. Your graphic is perfect to help drive home that point for me. I'm hoping I can use it to help my team focus more on the review aspect rather than just a quick demo. Well done!
3/24/2015 7:49:33 AM

Ken Rubin
Thanks Namitha!
3/17/2015 8:45:53 AM

namitha naveen
Great Post,Completely Agree..very useful.

Thank you.
3/17/2015 6:16:06 AM

Ken Rubin
Thanks for the kind remarks Mike! I appreciate you referencing people to the Essential Scrum book. I enjoy your online postings as well!
3/16/2015 1:25:14 PM

Mike Dwyer
Ken
Your book is on the top shelf, the one that I share with every class and workshop, When people ask me I'm gong to point them to this article and others.
Why? Yes I do like you and enjoy your work. But more important is the currency work like this brings to the community!
Thanks
Mike Dwyer
3/15/2015 6:08:27 PM

Ken Rubin
Hi Giuseppe,

I read your blog post and it is clear that we are fundamentally in agreement!

Thanks, Ken
2/22/2015 5:16:39 PM

Giuseppe De Simone
Great post, Ken! I share so much your view that few months ago I wrote a blog post around basically the same issue that I'm glad to share here: http://evolutionaryagility.blogspot.se/2013/12/what-hell-is-sprint-review.html :)
Regards
/Giuseppe
2/21/2015 1:26:19 PM

BHEEMASHANKAR PATTAR
Thank you Ken, Sprint demo vs Sprint review terminology gave me better perspective to handle situation.
2/18/2015 7:31:01 AM

Robin Goldsmith
I think the problem instead is that too often people call their sprint demo a review and mistakenly believe it constitutes user acceptance testing.
2/17/2015 9:01:00 AM

Ken Rubin
Hi Eric, I have a few questions. First, who attends your Sprint Demo and what is the true purpose of that activity? In Part 3 you mention alignment. Can you please elaborate on what that means? And, how well does this triad of meetings work for you organization? Can you point out some of the pros and cons for the rest of us?

Thanks,
Ken
2/13/2015 1:27:32 PM

Eric Yang
This is my view about the meeting in the last day of a sprint, it shall include:
Part 1: Sprint Demo - for accepted user stories in this sprint
Part 2: Team Retrospective - for team to cheer or improve
Part3, Sprint Review - for PO, team and stakeholders to review the alignment and over progress.
Thanks,
Eric Yang
2/13/2015 11:31:43 AM

Patricia Wong
Sprint Review - Totally agree Ken. Too easy to lose the original intent and value by the "re-labels" used for our ceremonies. I do try to provide reminders and reinforcements but it does take diligence!
2/9/2015 2:33:56 PM

Ken Rubin
Sorry, that should have said sprint RETROSPECTIVES!
1/28/2015 10:53:34 AM

Ken Rubin
Good comments John! And thanks for pointing out the other references to the opinion that POs should attend the sprint reviews.
1/28/2015 10:45:46 AM

John Hill
Hi Ken,

I just now read you comment that “Transparency is a foundational element of Scrum!” and it hit me like a wakeup call. After my tirade about not discussing problems with senior managers during sprint reviews, I felt a bit guilty, as well as a tad hypocritical, especially when I read your comment about how product owners should attend retrospectives. I feel very strongly about this, as do others:

In "Scrum Product Ownership: Balancing Value from the Inside Out" (2013), Bob Galen says:

“…as the Product Owner and team member, you owe it to yourself to fully participate in the retrospective. While this is always vital, it’s particularly important if the sprint didn’t go well or failed to meet your expectations.”

In "Agile Product Management with Scrum: Creating Products that Customers Love" (2010) Roman Pichler says:

“As the product owner, participate in the sprint retrospective on a regular basis. Attending the meeting allows you to contribute improvement measures and to strengthen the relationship with the rest of the Scrum team.”

In a newsletter reprinted during February, 2013, Mike Cohn said:

"I can’t think of a single good reason why a team would want to hold a retrospective without the product owner present."

Here’s a link to this short newsletter:
http://www.mountaingoatsoftware.com/blog/the-product-owner-in-a-sprint-retropsective

Anyway back to my guilt…

Product owners can cause sprints to fail. Because of this it’s imperative that they attend retrospectives and hear about their bad behavior if need be. After all, we talk the “transparency” talk so should also do the transparency walk! Last year I had a client that would not allow any product owners to attend retrospectives because of one very aggressive PO that everyone feared. It took me about 4 weeks to change that policy and that PO was actually transformed by attending a couple of retrospectives. So why do I feel guilty? I’ll tell you why!

I feel guilty because I’m selling transparency for retrospectives while stifling it for reviews. Perhaps a review is an appropriate forum to surface management practices that are causing sprint failures.

It can be a tough balancing act providing an environment that fosters complete transparency while simultaneously guaranteeing team safety… Anyway, I need to give this some more thought (and am interested in feedback from you and others on this).

Thanks!

John H.
1/27/2015 3:01:08 PM

Ken Rubin
Thanks Paria. The goal for Scrum Alliance articles is to be useful to the community so thanks for confirming!

Ken
1/27/2015 9:11:04 AM

paria
I am a newly scrum master! It was very useful to me.
Thanks.
1/26/2015 11:46:19 PM

Ken Rubin
Thanks, Che. I am glad you found the article useful and I appreciate the kind words!

Regards,
Ken
1/26/2015 5:58:50 PM

Che-Chuen Ho
Excellent, clear and concise reminder of the correct focus for the Sprint Review! I especially took to heart, "A review isn't a one-way flow of information, where the team is doing all of the showing and telling." The game studio example really drove it home. I think letting a stakeholder (someone who isn't intimately familiar with the coding) drive can draw out good feedback. In fact, watching how the stakeholder interacts with the product increment will provide valuable insight as to what that stakeholder focuses on.

Thanks for the great article, Ken!
Che
1/26/2015 5:30:16 PM

Ken Rubin
I agree that the sprint review is not the place to explore what “went wrong” with the sprint. Its goal is to inspect and adapt the product. My comment was focused on the Scrum team saying a sentence or two about why the results of the sprint might not have met the original forecast/commitment (e.g., “There were five user stories we were targeting for this sprint goal. However, we only got three done. The reason was that two team members got the flu this sprint so we ended up having less capacity than we anticipated.”)

The sprint retrospective provides the Scrum team with the opportunity to explore what is and isn’t working during sprints so that process improvements can be made. And, if bad senior management practices are the cause, then perhaps some or all of the members of the Scrum Team should have a separate meeting with the senior management to help them understand how their actions are negatively impacting the Scrum team.

As for the Sprint Retrospective, I personally believe this is a full Scrum team activity (including the product owner). I know that not everyone agrees with that position. Perhaps that will be the content of a future blog! I also feel that Scrum team members should be allowed to have a “private” retrospective that only includes them. So, if they don’t feel their environment is safe to have managers in the retrospective, then the managers shouldn’t be there. Of course, the ScrumMaster should be working to help address the safety problem so that the Scrum team would feel comfortable with anyone (within reason) being in the retrospective. Transparency is a foundational element of Scrum!

Happy Scrumming!
1/26/2015 8:56:49 AM

John Hill
Hi Ken,

(I wasn’t going to say any more on this but changed my mind…)

In my comment I said:
(The sprint review) “should focus on the product (“are we building the right product”) vs. the retrospective focus on the process (“are we building the product right”).

In your response you say:
“One thing I try to ensure is that if the team did not meet its sprint goal that we spend an “appropriate” amount of time to understand why and then get to the real purpose if the meeting (to inspect and adapt the product)”

Attempting to surface “why” a sprint failed during the sprint review can become a slippery slope. I follow the traditional advice to “invite the world” to the demo, which for me is part 2 of the review. If a sprint has failed due to some managerial failing (or can be directly related to some bad senior management practice), it can be dangerous to explore this territory with the “world”, especially if there are any "guilty" parties in attendance). While I believe it's essential to explore feature or functional-related product shortcomings during the review/demo, I sometimes withhold the deep-dive into “why” a sprint failed until the retrospective, which typically excludes managers and other potential guilty parties. This is also the reason why managers are often excluded from retrospectives (although I allow some exceptions).

During a review a couple of years ago a senior manager compared what he believed to be a prior “successful” sprint with the current sprint he saw as a “failure”. In his mind, one sprint succeeded because the team worked long hours and weekends thus delivering much more content, while the failure of the current sprint (delivering less) could be attributed to a work week limited to 40 hours. What this individual didn't recognize was that the team was unable to sustain this pace and he also did not acknowledge that sprints following this “heroic” sprint were fraught with quality problems causing much software to be backed-out at the end of later sprints. So, while the current sprint failed to deliver as much as the heroic sprint did, it nearly met its scope goal with very high-quality in a mostly predictable sustainable manner (which is the point). I’ve experienced many other examples of discussions of sprint shortcomings during reviews that have gone South (some with negative political ramifications for team members).

Bottom line, certain discussions around root causes for sprint failures are sometimes best avoided during reviews and held during retrospectives. Meeting this objective requires that an exceptionally skilled ScrumMaster facilitates the review.

Thanks for letting me pontificate yet more.

John H.
1/21/2015 12:18:00 PM

Deepak Joshi
Hi Ken,

Thank you!
The team referring the term PB1 does exactly what is expected in backlog refinement meetings:
o Get clarification from Product owner if needed and decompose the prioritized PBIs
o The team members together refine the requirements
A lot of Scrum teams wrongly ‘consider’ Backlog refinement as the WHAT part of the Sprint Planning. As you indicated the vocabulary is important! I too want to emphasis that modified names/acronyms create a lot of confusion and all of us should be strict to vocabulary to exhibit significance of the ceremonies.

Regards,
-Deepak
1/21/2015 8:24:00 AM

Ken Rubin
Hi John,

Thanks for posting! And I appreciate the kind remarks about the Visual AGILExicon ☺

As a rule, I think product owners should show up at Sprint Planning with at least a preliminary sprint goal in mind. The team is about to spend the product owner’s money, so imagine if it were your company and your money and you were the product owner. I am pretty certain that anyone in that position would show up to Sprint Planning with a good idea of what she wanted for her money that sprint!

Also, by the way you describe how you conduct Sprint Reviews, I can see that we approach them in a similar way!

One thing I try to ensure is that if the team did not meet its sprint goal that we spend an “appropriate” amount of time to understand why and then get into the real purpose of the meeting (to inspect and adapt the product). Obviously, if the team failed to deliver ANYTHING then an appropriate amount of time on why that happened might be a significant part of the meeting along with how does that (delivering nothing) affect what we will build moving forward (e.g., perhaps now we will have to agree to deliver less than we thought).

Thanks again for posting!
Ken
1/20/2015 3:38:27 PM

John Hill
Hi Ken,

I just returned from coaching a sprint planning session for a team with both a new product owner and new ScrumMaster. For most of the session, I observed much and coached little. By the end of the session when the product owner hadn’t identified any sprint goals and the team hadn’t indicated their degree of confidence in delivering the sprint backlog, however, I came to life.

As it turns out, the product owner had identified a succinct sprint goal that she then shared with the team. This is paramount for Scrum to succeed. During my Scrum coaching engagements I continue to struggle with the misconception that the sprint review ceremony (occurring before the retrospective) is only focused on a demonstration (this misconception seems to be almost everywhere lately).

The sprint review, as you point out, should focus on the product (“are we building the right product”) vs. the retrospective focus on the process (“are we building the product right”). My reviews begin with a statement of the sprint goal(s), along with a discussion of whether or not the goals were achieved. This discussion identifying the missed goals feeds into the retrospective discussion of “why” the goals were missed. I also try link the demonstration to the sprint goals as further evidence proving whether or not goals were achieved.

I also have much to say about when (and when not) to demonstrate anything during a sprint review, along with guidelines around who should perform each demo and why. I won’t belabor those points here as my comment is already exceeding a level of acceptable verbosity.

Thanks for posting this now (and the images in the Visual AGILExicon® remain the best in the Agile business!).

John H.
1/20/2015 3:19:18 PM

Ken Rubin
Hi Deepak,

Those are two excellent examples. I have been fortunate not to hear many teams refer to the Daily Scrum as the ‘Daily Status Meeting.’ I do, however, see some teams that are newer to Scrum act as if it were a status meeting!

More common for me is to hear teams refer to the Daily Scrum as the ‘Daily Standup.’ To be clear, although standing up during the Daily Scrum is a common (and I think many times a very effective approach for promoting brevity), it is not required.

As for BG1, that’s the first time I have ever seen that acronym! I have to admit to being confused by BG1 referring to the ‘what’ part of Product Backlog Grooming (Refinement).

The Sprint Planning meeting is often described as having a Part 1 (what part) and Part 2 (how part). Was this person referring to the ‘what’ part of Sprint Planning?

I strongly believe that if a team defers grooming of product backlog items to the Sprint Planning meeting its members will be every unhappy. This is where the concept of ‘Definition of Ready’ comes in. One of my rules of thumb is to have two to three sprints worth of stories in the ‘ready’ state at all times, and certainly before the team members show up at Sprint Planning.

My experience is that teams that attempt to do Sprint Planning without having sufficient product backlog items in the ready state have a very unproductive Sprint Planning session since they are spending most of their time grooming items to get them ready for consideration in the upcoming sprint. I explain this concept in detail in Chapter 6 of Essential Scrum and at http://www.innolution.com/blog/definition-of-ready.

Thanks for commenting!
Ken
1/20/2015 8:34:16 AM

Deepak Joshi
Hi Ken,

I fully agree with you on this and that’s what I read in your book ‘Essential Scrum’.
I found two main disadvantages of such renaming of the ceremonies.
First disadvantage is that most names have some significance; using other names ruins that. Say, calling ‘Daily Scrum’ as ‘Daily status meeting’ is certainly going to convert it into a status-reporting meeting. Many teams have experienced that, without their realizing it, the Daily Scrum has become a status meeting and lost its significance.

Secondly, not having a common name across the globe leads to misunderstandings.

I will share one instance where such renaming caused confusion. In one of our Scrum group events, one group member asked me in my organization how we conduct and what we do during BG1 (Bee Zee One). It took time me to understand that he was referring to Product Backlog Refinement (earlier known as Backlog Grooming) ‘What’ part.
And what if questions with such renamed ceremonies /acronyms are asked during interviews? :-)
1/20/2015 3:35:16 AM

Ken Rubin
Hi Tom,

Thank you for your comments.

To your point about who might demonstrate completed work at a Sprint Review, here is what I wrote about that topic in Chapter 21 of Essential Scrum:

"As for demoing the completed work, I prefer that every member of the development team have an opportunity at some sprint review to go hands-on and demonstrate, rather than the same person always dominating the demo every sprint review. However, I try to not get too wrapped up in who is going to do these things. I let the Scrum team make that determination with a goal of maximizing the benefit of the review activity."

Thanks!
Ken
1/19/2015 7:13:54 PM

Tom peters
Thanks so much on the clarification! It's easy to fall into demo mode. We did. I also found the answer to my question that brought me here. You wrote that the team members- plural demo what they have built. We had appointed one person to demo all the new features. Tom
1/19/2015 6:51:49 AM

 

Newsletter Sign-Up

Subscribe