Common Misconceptions and anti-patterns of the Sprint Review Meeting
“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 why of the meeting is - Intended to elicit feedback and foster collaboration. This meeting is an inspect and adapt point in the project. When I hear coaches and scrum masters theories on what should and shouldn’t happen in this meeting I like to link them back to the why of the meeting.
Here are some of the common anti-patterns in my opinion :-
Anti-pattern :- The review meeting is where the Product Owner get’s to see the stories demoed for the first time and signs off on themWell, you could do that but I don’t like it. Why? Because the delivery team should really have a chance to find out that they did not meet “done” before this meeting. Leaving sign off to this late in the sprint means there is no time to implement any PO identified delta and the team may fail delivery of that story.
I much prefer the team to do a demo to the product owner in sprint as soon as they feel they have 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 we have 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 I don’t like it is that 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 want’s it demoed differently or only in part in the upcoming Review meeting.
Anti-pattern :- Only demo stories that are doneThe 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”? Well 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 on, then why not go ahead and show it? Sure you will mention that it is not as complete as hoped at that juncture and point out what made it “not done”. Remember the why 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 deploy their software to an embedded system. Part of “done” is deploying the software to a test workbench. So come review day, the one test harness the team had dies. The only way to demo is in an emulator. Is that the right thing to do? Of course it is! 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.
Anti-pattern :- The demo is for the team to see what work has been doneWhilst this might be true, I don’t think it is a 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 in any case. Particularly if they are co-located and even more so if they are pair programming. (Two practices I cannot recommend highly enough.) I much prefer if the entire team watch the sign off demo to the PO mid-sprint. What this might look like is a pair in a team might call a huddle and call the PO over to view the work they feel to be “done”. The team all gather around and watch the pair explain the finished work to the PO and are present to hear if there is any feedback or needed changes which might get added to the sprint backlog.
Anti-pattern :- All stories must be demoedI 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 whilst necessary to the forward momentum of the product, are hard to show value to stakeholders. In these cases I feel a demo can do more trouble than good. Sure you should mention that work was done but that is plenty enough for these stories. An example is - 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. Can you see how this feature is important, but in a product that is going to be a user facing application, this feature is an overhead story and not an end user feature story?
Under these circumstances, I would recommend not wasting time and energy with demoing these type of stories. You are looking for feedback remember? Show only the stories that will elicit feedback. Don’t waste peoples time. If you can get through the meeting in under the allotted time box then great!
Anti-pattern :- the whole team must attend the review meeting alwaysWhat!?!?! I hear you say. Now I think 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.
Anti-pattern :- the overall project progress is not discussedFrom 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 all too often missed! 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. Oh - and make it big! Agile likes big and visible and transparent.
Start with the why. When you understand they 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 why behind the sprint review meeting.