Sprint Review


Try This

We never have anything to demo to Stakeholders

Experiment 1 - Say it ain't so

There’s really nothing to demo?  Seriously?  What did you work on this Sprint?  I’m betting there were stories in the User Story Format (As a…  I want…  So that…).  If you completed the work, you should always be able to show the ‘I want…’ part of that story definition.  If not, you’re not looking deep enough.

Experiment 2 - Dive into the code

Resist the urge to jump into the code, specification drawings, blueprints, etc.  No one wants to see that junk.  Yeah, I said junk.  If I ask you to build me a house, I don’t want you to show me pictures of a house.  I don’t want you to show me blueprints.  I don’t want you to tell me a story about how awesome the finished house is, but because it’s so hard to get to, you can’t show it to me.  I want to see the house!  I want to go inside and open the doors and stuff.  Do what you have to do to show it to me.  If you need me to meet you where the action is, I’ll be there.

Remember, your Stakeholders are likely paying for you to build this stuff.  Respect that.

All we did this Sprint was fix defects.  We didn’t add any new functionality.  No one wants to sit through a Sprint Review where we just show fixed bugs.

Experiment 1 - Build it and they will come

Hold the Sprint Review anyway.  Your Stakeholders should be there, like clockwork, every Sprint – just like the team is.  The team is not an island where Stakeholders go periodically to bask in your glory, but only if you’re holding a great party.  They are supposed to be there to weigh in on everything that you do / have done.

Experiment 2 - Let's poke it with a stick and see what happens

Don’t hold a Sprint Review.  Find out what happens.  There’s a few very evident possibilities.

  • No one will notice.  This is bad.  You want people to want your team to show them something / anything.
  • People will notice that there wasn’t a Review, but they figure you guys are doing well no matter what.  This isn’t great.  You want people to feel free to speak up and ask why a regular cadence was disrupted.
  • People will notice and call it to your attention.  This is good.  They are calling you out on the cadence disruption and they want answers.  Knowing that what your team does is important to other, is very important to team health.  Don’t force others to show that you are valued, like this.  Find a healthier way for your Stakeholders to show you how valued you are.
Experiment 3 - Avoidance

Stop defect-only Sprints.  If no one shows up for a Sprint Review, then what the team is doing is not valuable.  Stop doing stuff that not valuable.  When Stakeholders fins that you are back to doing valuable stuff, they’ll start coming back to the Reviews.

The Product Owner holds the Sprint Review without the Team Members

Experiment 1 - Let it go


Experiment 2 - Put me in Coach!

The Product Owner is part of the Scrum Team – they should be just as capable presenting the increment as anyone else.  If this is a real sore spot, then bring it up at the next Retrospective.  If you really want the spotlight on you, then volunteer to present the next increment at the next Review.  There’s no rule in The Scrum Guide that says who is supposed to present the increment.

But!  If you are going to carry the ball for the team, don’t drop it!

The team members present to the Product Owner during the Sprint Review

Experiment 1 - Invite the world

“Invite the world” is the general response when Scrum coaches get asked who attends the Sprint Review. I could spin a yarn a mile long about the organizations I’ve seen where no stakeholders were present at the Sprint Review, but after the team started invited people that were NOT in the stakeholder network, and word got out that the Review was awesome, the stakeholders started showing up, and the crowds grew, and so on…

Experiment 2 - Stop wasting my time

There’s a problem here.  If the team is presenting to the Product Owner during the Sprint Review, when do the stakeholders get to see the increment?  In private meetings?  That’s a waste, right?  If the team is presenting to the Product Owner on Wednesday, and the Product owner presents to the stakeholders on Thursday, that second presentation is a waste of the Product Owner’s time – it’s a duplication.

You might think that you can’t trust the team to present to stakeholders.  If that’s the case, you have a larger organizational problem than just who presents to whom.  One of the Principles behind the Manifesto for Agile Software Development relates to the trust that you need to have in the teams.  Maybe you should get more familiar with it.

Experiment 3 - Demo? Or Review?

Usually when we hear that Scrum Teams are presenting to the Product Owner during the Sprint Review, it’s because the Product Owner has NOT been involved throughout the Sprint.  This is a problem.  The Product Owner is part of the Scrum Team, and should be in constant contact with the rest of the team and be included in how they are progressing with the increment.  Start demoing the team’s work to the Product Owner several times during the Sprint to make sure you’re still making the RIGHT progress.  Finding out that the team went the wrong way on something, at the end of the Sprint, is too late!

Our Stakeholders never have any feedback for us

Experiment 1 - Silence is (not) golden

In truth, silence is not golden when we are talking about soliciting feedback for continual product improvement.  When we get zero feedback from one Sprint Review to another, we’re probably not asking right, at all, or we may have the wrong people in the room.  Generally the message that a team gets from silent stakeholders is that their product/work is not valuable.  Try explaining to the team of stakeholders that the only way for the Scrum Team to stay on track is to get hear from them, the stakeholders.

Experiment 2 - Well, thanks for nothing, then

If the stakeholders won’t provide feedback, they need to know that this is their best opportunity to change the course of the product.  If they cannot authorize change, then you might have the wrong stakeholders in the room.  Sit down with each stakeholder individually and find out if they have the proper authority to suggest changes in the product.  If not, find out who does and have them show up to the Sprint Reviews.

The Sprint Review only makes sense if we do it right before we release to production. And, we only do that every 3 months.

Experiment 1 - STOP IT!

If that is the entire truth, stop using Scrum.  It’s not for you.

Experiment 2 - I challenge your perspective

If your perspective, or opinion, is that it only makes sense to review the product at the end of the scheduled release, you may be looking at things through a very traditional lens.  Change your perspective.  Think about how difficult it is to change the product when you are ready to release.  Think about how easy it would be to know about small changes earlier in development.  Finding out about these changes early is what the Sprint Review is all about.  Don’t rob yourself of the opportunity to get a product release done right the first time.  And don’t saddle your company with a product that customers won’t use – even though the stakeholders knew it was useless months before production.

Experiment 3 - Take my dogma out for a walka.

Scrum is slightly dogmatic for a reason.  The rule is to hold a Sprint Review at the end of every Sprint.  Invite your stakeholders to see what you’ve created and solicit their feedback so you can make the next iteration of the product even better.  Follow the rules and the benefits will follow.  It’s that simple.  If current doctrine won’t allow for the change in process, Scrum may not be for you anyway.

Experiment 4 - I don't care. I'm gonna do it anyway.

Do it even if the current doctrine doesn’t allow for Reviews after each Sprint.  Maybe Scrum’s not right for your organization right now, but it may be in the future.  When stakeholders start seeing that they get frequent tangible updates on progress, and they are welcome in the change process, they may tell others about how easy it can be to get work done.

Our Stakeholders never complain about seeing our code/SQL in the Sprint Review, but our Coach says not to do it. Who is right?

Experiment 1 - Relax. I got this.

The Scrum Team is right.  They’ve presumably been doing this for a while and they have an expectation from their stakeholders that they are meeting.  Don’t rock the boat.

Experiment 2 - Just run the plays the coach calls!

The Coach is right.  They’ve been around the block a few times and seen everything there is to see.  If they say don’t show code or screenshots during a Sprint Review, it’s probably a good idea to change things up.

Experiment 3 - Everyone's a winner!

They are all right.  There really is no right or wrong on what to show in the Sprint Review.  Generally people advise teams to not show code, screenshots, hand drawn pictures, or just wave their hand and say ‘Imagine this…’  We advise not to show code, etc. because you aren’t showing the stakeholders what they asked for.  If you can’t show them some semblance of what they asked for, you might not be slicing your stories well.

The most common reason teams show code or screenshots, is because they are developing one layer at a time, and not slicing their work vertically.  It’s common, but it’s not great practice.  We generally tell teams to slice their work vertically because the outcome is obvious to stakeholders, and you don’t end up forgetting slight details when switching between one layer and another.

Since everyone in the Review gives us feedback, and we formulate plans based on that feedback in the Retro, we just extend the Review and hold the Retro with the Stakeholders in the room.

Experiment 1 - Privacy! Please!

Without referring to too much dogmatic literature, it’s generally not advisable to hold an open Retrospective.  Retrospectives are for the team, by the team.  They are suppose to be the team’s opportunity to self-reflect on how the Sprint went.  Sometimes Team Members want to talk about how other Team Members behaved during the Sprint.  This wouldn’t be too appropriate if the stakeholders were present.

Experiment 2 - Don't make it a habit

On occasion, it may not be a bad idea to hold an open Retrospective with many different people, related to the team, involved.  As long as the Prime Directive is understood, and everyone is comfortable with the idea, give it a shot and share your experiences.

Our Stakeholders never show up for the Sprint Review

Experiment 1 - Don't go.

Try not holding the Sprint Review and see what happens.  Retrospect on whatever happens.  You might have to do this twice before you find anything to Retrospect on.

Experiment 2 - Is anybody out there?

Contact all of the stakeholders and find out why they are not attending.  Retrospect on why they do not attend.  You may find that it’s a simple scheduling problem.  If it’s more complicated, come up with a simple solution.  There’s nothing worse than a complicated solution to a complicated problem.

We get a lot of positive feedback in Sprint Reviews, but there’s nothing to react to – nothing to fix or change.

Experiment 1 - The Crucial Stakeholder

Lack of negative, or constructive, feedback is just as difficult as not receiving any feedback at all.  Don’t assume that you need to make mistakes in order to get constructive feedback, though. Even Sprints that go perfectly can result in constructive feedback.

For example, I was a team member of a team once, where for almost 5 Sprints straight we delivered on the Sprint Goal completely, the Product Owner was very satisfied, and we expected the Stakeholders to have nothing to say at the Sprint Review.  Each time, though, they came up with things they either didn’t like, or ways to make the product better. We we reflected on this, we sent the Product Owner and ScrumMaster to the most senior Stakeholder to get some answers.

It turned out that the Stakeholders were overjoyed by what we had been producing Sprint after Sprint.  They never expected us to achieve so much in so little time.  But, whenever they pushed us a little more, we kept delivering, so they kept pushing.  The key was that they were very happy with us, and all of their improvement ideas were based on the things we delivered to them.  The Stakeholder admitted that more than half of their improvement ideas wouldn’t have even been thought up without seeing our Sprint Reviews.

What I’m getting at here is to have an honest dialog with your Stakeholders.  Find out why you aren’t getting the feedback you expect. Ask if you aren’t meeting their expectations.  Ask if they are or are not happy with the team’s results. Make sure that they know that it is crucial to the team that they be clear with their reactions and feedback.  The team needs it to continue with enthusiasm.


Experiment 2 - Keep calm and code on

No feedback means it’s OK to just keep coding away, right?  Not really.  Someone has to set the Sprint Goal, and it should be based on the Stakeholders’ request.  It’s the Product Owner’s responsibility to make sure we set a proper Sprint Goal.  So, if you aren’t hearing any feedback at all during the Sprint Review, then the Product Owner, at least, should be communicating with Stakeholders to make sure the team is still on the right track.


Still Need Help?

If these suggestions do not solve your problem, please accept our apologies for any dysfunctions that your Scrum has revealed to you. You may find related organizational dysfunctions in the section Advice & Preventative Maintenance