Get certified - Transform your world of work today


The Sprint Review: Mastering the Art of Feedback

21 April 2009

Bob Schatz
Agile Infusion, LLC

The sprint review in Scrum is a critical part of the inspect and adapt cycle. Having worked with many teams and organizations, I have noticed an overall reluctance (and in some cases fear) to do them in the way they were intended.

First, let’s understand what the purpose of the sprint review is.  As my friend and mentor Ken Schwaber writes in his first two books, the sprint review is “a 4-hour informational meeting for the team to present to management, customers, users, and the Product Owner the product increment that is has built during the Sprint.”

Focus on the End User

Some companies are reluctant to involve their end users for fear of “scope creep,” others feel they aren’t allowed to ask the end users to be involved, and certain others don’t even know who the end user is! Whatever your reason for not involving them, find a way to do it.

That’s what we did at Primavera when we adopted Scrum back in 2003. We started off demonstrating mostly to our product managers, but we knew something was missing. So we kept thinking about how to increase the value of feedback we were getting, then the obvious solution emerged—we should involve our actual customers! Customer collaboration, remember? So, we started by inviting some of the customers we had always worked closely with and began to expand it little by little.

We had our own challenges to deal with in involving end users. For one thing, we had about 15 Scrum teams all working on the same release of our software. To help keep end users focused, we started using themes for each sprint. Each team had some piece of work that related to the Sprint theme. Having a theme helped end users tailor their feedback towards the theme for the sprint.

Our sprint reviews could best be described as being like science fairs at school. Each team set up a station where they demonstrated what they worked on. The end users, stakeholders, and a few others from our company formed small teams. Each reviewer team started at a different station. We ran 15-minute iterations moving reviewer teams from station to station.  It was an environment of high-energy, excitement, and fun.

Involve the Product Owner

You’ll notice that the product owner was not part of our reviewer teams. Instead, the Product Owner was actually responsible for presenting the project. This deviation from the original book definition of a sprint review greatly improved the dynamics of our sprint review.

Too many companies and projects set up their sprint review so that the team is presenting to the Product Owner, as if he should grade them or judge them on their work.  This is nonsense! The Sprint Review is not an inquisition or a court of law; it is a way to get feedback from the customer. Instead of presenting to “Judge Product Owner,” teams should instead work with the Product Owner during the sprint to review each story as it’s completed.

Then, when it’s time for the sprint review, the Product Owner should be the first person to stand up, welcome people, and give an overview of the state of the project. The Product Owner should discuss what the overall goals were for the Sprint, what was achieved/not achieved, the quality level of the product, and the release/product burndown.  He should then let the reviewers know what they should be looking for and how to provide the feedback.  After setting the stage, the  Product Owner turns the “show” over to the Scrum teams for the demonstration of functionality.

Understand Group Dynamics

Changing the sprint review audience from a lone product owner to a team or teams of stakeholders and end users dramatically alters the group dynamics. Let’s look at how these roles change once the product owner is part of the presenting team.

Product Owner: The Product Owner is put in a position where he now is acting as a true owner of the product. He has the responsibility and accountability, as part of the overall team, to present the results of their decision-making to the end users and stakeholders. He stands up and presents the product increment and gives insight into the state of the project. Knowing he must do this at the sprint review enforces the discipline to maintain a product/release burndown and know the quality level of the product. Another byproduct of this approach is that any discrepancies between the Product Owner’s representation of the end users’ needs and the actual needs of the end users will surface immediately.

Scrum Team: The Scrum team is now in a better position to present what they’ve done in the sprint with a sense of pride. They get time with the end user, in the best cases face-to-face time. The best way to develop good software that provides the most value to the end user is to know the end user. The team learns how to take feedback, and with every sprint they get a better appreciation for the people they are developing the system for.  Another ancillary benefit is that presenting to the end user takes away the feeling of being graded or judged by the Product Owner. Instead, the team leaves the review motivated and energized for the next sprint.

Company Executives/Stakeholders: When executives and stakeholders are invited to the review, they not only get a great view of the real status of the project, they also get to see their teams in action. Additionally, they get time with the end users to hear directly about their needs. Perhaps most importantly, they learn how to behave themselves. It’s amazing how different the dynamics are when customers are around. Instead of the criticizing and bickering that usually goes on, everyone is on their best behavior, so the review becomes much more productive and motivating.

End Users/Customers/Partners: The end users are the stars of the sprint review. They get valuable face time with the people that are developing the software. They come to feel like they are part of the development team. They are engaged. Because they have been so involved in the product’s development, once it is released and put into production, they are usually the product’s biggest supporters inside their own companies. Having knowledgeable advocates for the product at the customer site can also help reduce the usual flood of support calls that are typical immediately after release.

ScrumMaster: The ScrumMaster’s sole role in a sprint review is to facilitate. She makes sure the environment is set up for all of this great stuff to happen—that the right people, supplies, and facilities are there. And she makes sure the pizza is ordered. This may seem like a small detail, but don’t forget to feed people. Food is a great collaboration tool. We had some great conversations in the times where we shared some food.

Remember, this is not a ScrumMaster show. During the review, the ScrumMaster should support the teams, make sure the end users are welcomed and made to feel like part of the team, ensure that they get a chance to be heard, and stay behind the scenes.

Be Courageous

If you want to master the art of feedback, the first step is to create an environment that allows it to happen. It can be scary to involve the end users in the process but remember: it’s better to hear the feedback early and have time to make adjustments than to go down a long path only to find out it was the wrong one. Still afraid of scope creep? Let it go. First, the Product Owner will make the decisions on what trade-offs will be made after each sprint review; and second, you may find out more about what the end users don’t need, which will stop overproduction of features that may never be used.

Focus on the end user, create energy and excitement, and make your sprint reviews an event that your customers want to be there for. All you have to do is create a review that has direct value for them. Then just sit back and listen. You may be surprised by what you learn.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.5 (2 ratings)


Sander Lems, CSM, 4/22/2009 4:12:28 AM
Bob, I like your post and share your opinion about involving the customer. We also experienced that when a customer feels involved in the proces, he would likely become a supporter of the product inside their own company; it saves us a lot of questions and support. Thanks for this post, we have shared it with our other ScrumMasters and Product Owners.
Brent Walker, CSM, 4/29/2009 2:09:13 PM
Bob, I do like your post and believe it in concept. However I have questions about its practicality. 1) Are all your customers local? 2) If not, do you pay for their travel? 3) How frequent are your sprint reviews and do you do this each sprint review? 4) Being a confidential meeting, how do you ensure that your *new* features are not shared directly with your competitors who may be having the same type of meetings with this same customer?
Bob Schatz, CST,CSP,CSM,CSPO,REP, 4/29/2009 3:15:47 PM
Good questions Brent,

One thing before providing some suggestions is to consider how you can make sure you are delivering value to your customers (or potential customers) if you are not directly collaborating with them?? A Sprint Review without end user feedback is simply a "look in the mirror". You need to get people outside of your organization, ideally, the end user.

1) No. Customers were/are not local in any of the circumstances I've done this.

2) Surprisingly, no I didn't. I thought I would probably have to, but customers are actually very excited to come in physically, and if you can't do that, then do it via webex, etc. Not the best, but better than not doing it.

3) I've always done the customer Sprint Reviews every 4 weeks, and yes get some participation in each review.

4) Well, legally you can have them sign an NDA, but practically your competitors already know. And getting into feature wars is a good path to a mediocre business plan, IMHO.
James Peckham, CSM,CSPO, 6/29/2009 1:33:17 PM
Thanks for this article. It puts into words what I've experienced when we do sprint reviews. You always learn something at them... and scope creep is such a negative connotation for something that is inevitable and we should always accept in agility... change. We should respond to change over following a plan. We should welcome changing requirements even late in development (the last day) because it's our customers' competitive advantage.
Hans Samios, CSM, 7/21/2009 1:18:24 PM
Great article, Bob.

One recommendation I would add is that before you get a customer to attend a Sprint Review, you spend some time with the customer discussing her role at the session and what to expect. We've found that people who are used to traditional development processes can become very critical because they are concerned that it is too late to have an impact. We typically conduct a half hour session with new (to the Sprint process) customers to:

1. Make them aware that their feedback will be an input into the overall plan and that we like to hear this.
2. Make them aware that by being motivational to the team, they they can have a lot more effect - the team will want to help them.
Julie Hendry, CSP,CSM, 7/24/2009 4:35:14 AM
Good article Bob, glad to see someone else has their PO present software - after all it 'belongs' to them, the team simply built what the PO asked.

Must admit I've faced many PO's who refuse to do this - usually when they are not really leading/sure of their decisions - any tips on how to handle hands-off PO's much appreciated.
Bob Schatz, CST,CSP,CSM,CSPO,REP, 7/24/2009 9:07:51 PM
Hi Julie,

The best way I've seen is to get the end user engaged in the Sprint Reviews. Having people from the outside who will actually be using the software (if that is your situation) will "force" the ownership into place. Give it a try!
Edward Corlett, CSM, 9/15/2011 7:35:07 AM
A very interesting read Bob. As a Scrum Master who works with a team which is just getting used to the basics of scrum, I wondered if you could help with the following question re Sprint Reviews?: Do you still go ahead with the review to prove what the team have done, even if the Sprint Goal has not been achieved?
Bob Schatz, CST,CSP,CSM,CSPO,REP, 9/15/2011 8:03:40 AM
The purpose of the Sprint Review is not to "prove" what the team has done, but to INSPECT where we are and get any feedback on items that are DONE by the Definition of DONE. The feedback should be solicited primarily from end-users. This inspect, or in Deming terms Check, cycle increases knowledge and provides an opportunity to adapt. So, in the past I have never cancelled or postponed a Sprint Review, nor have I demonstrated work that does not meet the work and quality standard established in the Definition of Done. If you would like to discuss further, please feel free to contact me via email or phone 215-435-3240

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up