“This is an informal meeting, not a status meeting, and the presentation of the increment is intended to elicit feedback and foster collaboration.”
— Ken Schwaber and Jeff Sutherland from the Scrum Guide
The sprint review meeting’s purpose is to elicit feedback and foster collaboration. It is an inspect and adapt point in the project. When I hear coaches’ and ScrumMasters’ theories on what should and shouldn’t happen in this meeting, I like to link them back to the purpose.
Here are some of the common anti-patterns, in my opinion:
1. Anti-pattern: The review meeting is where the product owner gets to see the stories demoed for the first time and signs off on them
You could do that, but I don’t like it. Why? Because the delivery team should have already had the chance to find out if it did not meet “done” before this meeting. Leaving sign-off to this late time in the sprint means there is no time to implement any PO-identified delta, and the team may fail delivery of that story.
I prefer the team to do a demo to the PO in-sprint as soon as it feels it has met “done”. This follows the pattern of early feedback that we are trying to foster in Agile. If the PO finds some issues or has minor changes (that will not affect the sprint delivery), then the team has a chance to implement them before the end of the sprint. This pattern keeps the PO involved in the delivery of the increment, and fosters collaboration.
Another reason why I don’t like this is because you run the risk of embarrassing the PO in front of the stakeholders if there are issues with the demo. Having the PO see a demo before the review gives the developers a safe environment to do a dry run, and make sure they know how to demo the story. The PO might even describe how he/she wants it demoed differently or only in part in the upcoming review meeting.
2. Anti-pattern: The only stories demoed are the ones that are done
The Scrum Guide says that in this meeting: “The development team demonstrates the work that has been done… The Product Owner explains what Product Backlog items have been ‘Done’ and what has not been ‘Done’”. So, do you show work that has not been “done”? I think the answer to that is up to the PO. If he/she sees value in the work that was done and can see that there is enough done to get feedback, then why not go ahead and show it? Yes, you will mention that it is not as complete as hoped at that juncture, and point out what made it “not done”. Remember, the purpose of the meeting is to get feedback, so if there is enough to get feedback on, show it.
Here is an example: I had a team that deployed software to an embedded system. Part of “done” was deploying the software to a test workbench. Come review day, the one test harness the team had died. The only way to demo was in an emulator. Is that the right thing to do? Yes. You explain to the stakeholders why it is not in the workbench, and will have to resort to showing the progress of the increment in an emulator in order to continue with the meeting. You want feedback and this will get you feedback, so yes, that is the correct thing to do.
3. Anti-pattern: The demo is for the team to see what work has been done
While this might be true, I don’t think it is the primary purpose of the meeting, and not one of the goals. The primary purpose is to elicit feedback from the stakeholders and/or customer(s). A highly collaborative team should know what is going on with the rest of the team during the sprint, anyway. Particularly, if team members are co-located, and even more so if they are pair programming (two practices I cannot recommend enough). I prefer that the entire team watch the sign-off demo to the PO mid-sprint. This might look like, for instance, a pair in a team calling a huddle, and calling the PO to view the work it feels is “done”. The team gathers around and watches the pair explain the finished work to the PO, and are present to hear any feedback or needed changes which might get added to the sprint backlog.
4. Anti-pattern: All stories must be demoed
I feel the demo should be slick, exciting and engaging to the stakeholders. Not all stories are necessary to demo to a room of stakeholders and customers. There may be stories that are run in a sprint that, while necessary to the forward momentum of the product, don’t immediately show value to stakeholders. In these cases, I feel a demo can do more trouble than good. Yes, you should mention that work was done, but that is enough for these stories. For example, let’s say you have to change the format of the log output so that it can be consumed by the new data mining platform that another project has implemented in the company. You can see how this feature is important — but in a product that is going to be a user-facing application is this feature an overhead story, or really an end user feature story?
Under these circumstances, I would recommend not wasting time and energy with demoing these types of stories. Remember, you are looking for feedback. Show only the stories that will elicit feedback. Don’t waste people’s time. If you can get through the meeting in under the allotted time box, then great!
5. Anti-pattern: The whole team must attend the review meeting always
“What?!” I hear you say. Now, I think that ideally yes, the whole team should participate. But if the room that you have available for the review is too small to accommodate the whole team and all the stakeholders involved, then I would recommend only bringing as many of the delivery team that the room will accommodate. At a minimum you (as PO) should bring the members needed to run the demo if you are unable to do it yourself.
6. Anti-pattern: The overall project progress is not discussed
From the Scrum Guide: “The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date.” Too many “demo meetings” I have attended are just that — demos and nothing else. The meeting is a sprint review meeting of which a demo is just part of the meeting. The important aspect of discussing the remaining backlog is missed, all too often. My personal preference is to bring in a product burn up chart. It’s simple to maintain, and contains the smallest (and most useful) amount of information needed to portray this information. And make it big! Agile likes big and visible and transparent.
Start with the “why”
When you understand the “why”, it will help you make the best decisions around any of the Agile practices. I hope these scenarios have helped you get a better grasp of the purpose behind the sprint review meeting.
Like this? You’ll love Agile Eats
Agile Eats is our semi-monthly e-blast chock full of tips and tricks too good not to share. Subscribe now!