Sprint Review

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.

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.

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 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!

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.

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!

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.

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.

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.

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.

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.

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.

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.

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.

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.