Subscribe to AgileIQ via email

Your email:

Subscribe to our Newsletter

siq newsletter 180

AgileIQ Blog

Current Articles | RSS Feed RSS Feed

6 Common Misconceptions and Anti-Patterns of the Sprint Review Meeting

  
  
  

by Ron Quartel

"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

Feedback, please!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.

Comments

Nice article Ron!
Posted @ Friday, October 04, 2013 11:35 PM by Wesley Williams
I disagree on one point. Only demonstrating done work is pretty fundamental. Schwaber said "Functionality that isn't "done" cannot be presented." While we can allude to partial work, I don't think it should be part of the sprint demonstration, and it should not be considered an anti-pattern to only show done work. 
 
I do agree that getting feedback and defining future work is a key goal. I often see meetings where ideas and comments about new work ("I really need this other data on the page, now that I see it") is seen as failure. In the normal project where many stakeholders don't get to see a feature until the demo, we should celebrate constructive feedback. 
 
Thanks for the thought provoking post.
Posted @ Wednesday, October 09, 2013 12:00 PM by David Wylie
Hi David. In regards to your point on not demoing finished work - I ask, why? Why do you feel that Schwaber’s and Sutherland’s stance is correct? I did mention their stance on demoing finished work only and that my stance is not in total agreement, but I did that by substantiating why I felt this and gave an example (of a test bench not being available). I am not trying to be belligerent or facetious in my question to you of why you feel their stance is the correct one. It is more my question to Schwaber and Sutherland. I do not, and cannot, think of a reason why they have taken such a hard a stance on it and have not found in any book an explanation or description of their why. Now I know the scrum guide is intentionally short and succinct so an explanation of the whys in this document is not feasible. But if you know or have a personal opinion of the why then please share. I can be swayed but with my current understanding I think there should be exceptions. Particularly due to the fact that when scrum was originally conceived it was recommended that the sprint length be a month. Now why would you delay feedback on a story/feature by a month because it had missed the entirety of the Definition of Done? A month! For example - perhaps on a given story all manual testing had not been completed. So you would not show the story to a stakeholder for another whole month because of this? This doesn't seem to make sense to me and goes against the "why" of the sprint review meeting. It feels a bit like you are cutting your nose to spite your face. I am genuinely wondering if I am missing something or some insight that Schwaber and Sutherland have/had to have come up with such a hard stance. Any insights are appreciated.
Posted @ Thursday, October 10, 2013 11:12 AM by Ron Quartel
Comments have been closed for this article.