The Sprint Review

Note: This is one in a continuing series of posts re Scrum Intro. The preceding post is here.

The Sprint Review (meeting) happens almost at the end of the Sprint.

Basics

We gather the team (the whole team, including of course the SM and the PO) and meet with the Business Stakeholders (BSHs).

We want to learn the truth. What progress have we made? What mistakes have we made (in terms of the product)? What do we need to do better (on the product)? How do we improve the product so that it is an outstanding product? One key phrase: The bad news doesn’t get better with age.

The overall time box for a two-week Sprint is two hours. I find that most teams at first do not have that much stuff that’s done, and also the feedback is not that extensive. So, often the meeting is over in about an hour. But, you can imagine, after the SM doubles the velocity and after the PO starts providing better “requirements” that the team will produce a lot more in two weeks, and so the meeting might need to go to two hours.

I think of the meeting in two parts.

The Review

The first part is a short review. In the review part, I recommend that the PO discuss a few basic things quickly — maybe summarized on one slide. (Certainly not a 50 slide presentation!!)

They might include:

• “These are the stories we committed to in the Sprint Planning Meeting…”
• “These are the stories that are done-done…”
• “Our velocity this past Sprint was X…”
• “Our average velocity over the last three sprints is Y, and with that average velocity we expect the current release to be delivered in Z more Sprints.” (say, two)
• “Our biggest impediments were one, two and three, and our current biggest impediments are three, four and five.”

Then there might be some discussion — hopefully about how the business side would like to support getting one or two impediments fixed. So, relatively quick, and 10 minutes might be typical.

Demo

The second part I think of as the demo, and in fact people often call this whole meeting “the demo” — which is not so bad, but I think slightly misleading. What do they demo? Well, maybe it is obvious by now, but they demo (mainly) the new “working product” that has been built during the Sprint.

Perhaps we should add now that the demos (of each story, one story at a time, typically) are given usually in the context of the whole product. That is, all the features from any prior release as well as all the features built in any prior Sprints to build the current release.

OK, so we want everyone to give us honest feedback, and the best feedback that they can give us, and complete feedback.The bad news does not get better with age. Anyone can give feedback, and the feedback is mainly about two things.

1. How much Business Value does the story have, now that they see it?
2. Are there any details that are imperfect?

The demo needs to be prepared (before this meeting) quickly. The data needs to be prepared. Someone needs to think through how we will demo the new features. Which examples will we use? Are they appropriate? Etc. This is important and sometimes hard, and it must be done in a time box.

The demo needs to be “narrated,” particularly at first, by someone who understands the Business Stakeholders. It cannot be so technical that the BSHs never want to come back. The speaker must engage the BSHs and then handle their comments and feedback. If this is not done well, then the BSHs will not come back, our feedback will be much less good, and therefore the product will achieve much less business value.

Let’s say again: Getting good BSHs that come every time is hard. Good luck with that problem.

Now, back to the demo itself. We need to hear every imperfect detail now. So, if an “imperfect” BSH does not understand every detail of each story being shown, that BSH should  bring a SME or BA or someone who does understand all those details — and bring that person today!

Feedback

What we want is perfect feedback about what the customers are going to want over the whole life-cycle of the product so that we achieve maximum Business Value over that whole life-cycle. What we get is less good than that. We get feedback from humans who are not the real customers, or at least that’s what I usually see happening.

Anyone can give feedback. That is, we mostly expect the best feedback will come from the Business Stakeholders. It is they who should understand the different customer groups the best (along with the PO).

But in fact, the Implementers often have excellent feedback. George may have excellent feedback on the story that he did not work on. Hopefully, much of the time, we get positive feedback — yay! We did stuff well and the customers are really going to like it — yes!

It is wonderful for the team to get that kind of feedback every two weeks. Wonderful. (Surprisingly, in the past the Implementers would often go months without getting positive feedback. Well, I am slightly sarcastic. Often they never would get any positive feedback from anyone who mattered. That is, anyone who represented the customer well. Sad to say.)

Some of the feedback is negative. Sometimes the Business Value appears to be less than we originally thought. Sometimes some of the details are not right, now that we can look at them.

To be fair, it is hard to read the mind of the customer, and what he or she or they will want in the future. We do the best we can. We live and learn. Also, not everyone agrees on the feedback. One BSH will disagree with another BSH. The PO won’t agree with an Implementer, etc., etc.

Decisions

In any case, though, the PO must decide quickly.

1. “It’s done, we think the customer will like it like it is.” Hopefully most of them fall into this category.
2. “It needs some changes and here is the complete list of exactly what those changes are.” A couple of stories can be in this category. We hope not many.
3. “It need improvement but we are uncertain about the details.” Hmmm. This is not a good category if we want to get the release done on time.
4. “Wow! Things are fouled up. No one is ever going to want this.” A story in this category is kind of depressing, but at least the bad news is not getting better with age. Then we have to decide: “Well, is there anything within this user story (the three parts) that is a real need?” Sometimes we realize that it was an idea, but at least not a real need now for the current release.

The PO must state the decisions clearly and also with a minimum of injury to the egos of the people whose opinions the PO is ignoring. Good luck with that. I guess at this point we should mention that the PO is not always senior to everyone else in the room. Sometimes some of the Business Stakeholders are more senior. Nonetheless, the PO must decide and get it to stick with the people in the room.

Again, sometimes the BSHs do not see things from the same point of view. Perhaps their “departments” or interests are rather opposed. Nonetheless, the PO must get them to express their differences and then must resolve them quickly, or at least decide quickly what to do with the current story. You can imagine how this meeting can be “interesting.”

Wrap-up?

Sometimes it is useful to have a “wrap-up” section of the meeting, and review the decisions that were made. They review the eight or so stories, say which ones ended up in which category and summarize the changes to be made (to only one or two stories, we usually hope) in the next Sprint.

Well, technically, a “to be improved” story does not have to be improved in the next Sprint, but almost always that is that right thing to do for everyone.

Two Questions

We also strongly recommend asking these two questions of the group. These questions can be asked many ways, but here is our suggested wording. At the beginning of the meeting, after all the stories have been quickly mentioned, ask:

“Did we work on the most important stories this Sprint? 20-20 hindsight, should we have worked on another story instead?”

Often this question will reveal new learning. For example, a new story for this release might be identified, and then, after all the stories have been shown, ask this:

“Seeing all these stories, do they make you think of any stories that should be in the Product Backlog?”

Typically, whatever they suggest, we must check if it is already in the Product Backlog. Again, sometimes some very important stories will be identified at this point. Some people might object. They might say, “Joe, you are inviting scope creep.” Well, no.

So, assuming we identify some new stories, one of the next questions is, “Should that new story be in the current release of the product, or later (or maybe never)?” Remember what Buddha said, “Everything changes, nothing remains the same.”

More specifically, we are always discovering ourselves and each other. As things change, we start to want different things in the product, or we (the builders) start to understand the life of the customer in a much different way. Whatever the reason, new important stories can still be identified. Better to identify them before the release than have the customers tell us of our glaring omission.

Just because we discover a new story does not mean that PO must put it in this release. That’s a different decision.

 Note: The next post in this series is here.

« « The Daily Scrum || The Retrospective » »