Over the past year I ran a couple of Scrum trainings. At first I found it sort of funny to notice that amount of misconceptions that seem to appear in these various classes. Recently I figured that it would be more helpful to clarify some of them. Among one of the larger, and probably more manifested misconceptions regarding Scrum lies in the Sprint Review meeting. Let’s examine that one today. I am quite sure that someone has written about this before. I found that it would be worth to throw in my point of view as well.

Objective of the Sprint Review

What’s the core objective for the Sprint Review meeting? It seems that most folks think that the ProductOwner accepts the results of the sprint, that is the potentially shippable product increment. So, the core objective of the Sprint Review meeting lies in the ProductOwner marking the particular items from the Sprint Backlog with a green check mark, and appreciate the development team for their work in the past two weeks. At least this point of view is congruent with the notion that we don’t need to invite stakeholders to this meeting.

Can you figure the situation the situation where a customer, the department lead, and the CEO attend the open Sprint Review. The development team demonstrates the product increment, and shows what they finished according to the Definition of Done. Now, there was a rather vague backlog item in the Sprint. The ProductOwner now finds out that the development team has a different understanding about the item, and implemented it another way.

Only for a moment dive into this situation as a team member on the development team. Probably the one that is currently sitting at the keyboard demonstrating the product. A moment ago, you were proud of your results. Now, you notice that the face of the ProductOwner becomes more and more frowning and unhappy. “I am sorry, that’s not what I meant. You need to do this over.” Silence.

Digest that situation for another moment.

How do you feel? Do you notice the elephant in the room? Do you notice the hidden thoughts of all the developers in the room?

Let me adhere to the retrospective prime directive and not dive into this situation any deeper.

To make a long story short: as a member of the development team you would lose face in front of the stakeholders that also attend the meeting. You probably think more about what the ProductOwner did wrong with his crappy item, and I certainly think that a couple of development team members will start to fight that sort of feedback more actively.

To say the least, if the key objective of the Sprint Review meeting was to have the items, then why should you invite stakeholders at all to this meeting? And isn’t the Sprint Review meeting the most terrible moment in time to find out that you didn’t deliver anything this Sprint? I certainly think so.

The core objective of the Sprint Review meeting lies in receiving feedback from the stakeholders regarding the product increment. The ProductOwner should use that feedback in order to derive unaddressed backlog items that she can prioritize in the list of already existing backlog items accordingly. At this point having stakeholders attend the Sprint Review meeting also makes more sense. They play a central role.

Receiving feedback

While this objective sounds easy enough – it is not. The agenda of the Review meeting are quite easy. Team demonstrates product increment, we collect feedback from the stakeholders – and move on to the retrospective after closing the meeting, and releasing the stakeholders again. Finished. That’s it. Really.

Yeah, maybe the team did prepare sloppily for the demonstration part, and so on. Over time they may or may not come up with preparing the demonstration in a engaging way. Fair enough. That’s still basic in comparison to collecting feedback. Why?

In some of the classes we came up with an exercise where we work through a whole Sprint in a short amount of time. Then the whole training class comes together, some of us play the role of the stakeholder, and provide feedback. What always happened, no matter how long the training class was, is that the development team starts to justify their decisions. Also oftentimes the ProductOwner joins in this justification. At that point we actually shut down our minds for any feedback. That’s poor.

I always refer to a rule that I read in Peter Block’s Flawless Consulting. I avoid taking anything personally that happens before 6pm. I found this a helpful rule when consulting. I also found the rule helpful when reading review feedback of my articles and chapters. The same applies for a development team and their ProductOwner. They provide you with the most relevant information in order to make the product more valuable to them.

So, STFU, and listen!

Oh, and you need to trust your ScrumMaster that he will be able to handle unfair feedback, and get the discussion back on an objective level, rather than a personal one. (And if your ScrumMaster is not able to handle such a situation, you need to help him by providing him that feedback.)

But when does the ProductOwner accept items from the Sprint backlog?

Oh, glad you asked. If the Sprint Review meeting is not the right point in time to accept backlog items, when does that one happen? Ideally, the development team and ProductOwner interact with each other regularly, hopefully every day during the Daily Scrum. The ProductOwner should attend that meeting. When the team says that they finished one item in their Sprint Backlog, we can have a discussion afterwards about when to meet in order for the ProductOwner to have a look at it – and hopefully accept it, or identify remaining tasks for this item.

I worked once with a team where the first item would be finished after about three to five days into the Sprint. The development team would then make an appointment during the day with the ProductOwner to have a look at it. The ProductOwner would sit down on the test system to inspect the updated product, and the item in particular. Since there were always things that he wanted to change, one team member always joined him, and noted down everything that came up. Afterwards they put these tasks on the taskboard, and fixed the remaining problems over the next day. Usually the ProductOwner was happy after that, and the development team could move on.

The focus should move from acceptance of Sprint Backlog items during the Sprint Review meeting towards a model of Continuous Acceptance during the Sprint. That helps the development team and the ProductOwner realizing their progress within the Sprint, and not only finding that one out when it’s too late to do anything about it. I think this is a more fair model of interaction between development team and ProductOwner. In the end, none of the team roles can produce anything valuable without the other.

Let’s work together, rather than against each other.