Sprint Review: How to prevent every single type of story from being "reviewed"

Question

The team decided to make every work item into a sprint story. This means that along with development stories that result in a product increment, a sprint also contains stories for integration testing, user acceptance testing and research/pre-development work.

Sprint reviews are scheduled at the end of each sprint. So far, stakeholders have not been available, but the PO and the Division director attends. Every completed story is reviewed/demonstrated. This has resulted in reviews with full agendas such that there is no time to actually inspect the product increment. We are shown charts, spreadsheets and word documents.

I asked my manager (Dev manager and PO) that we limit review items to those that result in product increment. But I was told that will mean only developers get to review the stories, non-developers will feel left out and since Agile is about people over processes, every one who completes a story will review/demo it.

What argument can I make to convince management to limit the reviews to just the product increment? Or am I wrong to do so?

Answer 1

As you suspect the standard purpose of the scrum review is to 'inspect the Increment and adapt the Product Backlog if needed'. In practice this means showing what work is now done (so these items can be removed from the backlog) but also to review that any changes in the market conditions & use cases of the product haven't caused a change in priority or requirements themselves that should be reflected in the backlog. Finally it allows an opportunity for miss-understanding of requirements to present themselves to the stakeholders (users) of the product. As such a large amount of the value of the review is lost without the presence of these key stakeholders.

It is unsurprising to me that stakeholders are not attending these meeting as they are currently set up. After-all how do they benefit? They don't get a better understanding of the product nor do they have a chance to influence the direction. Is this acceptable to your organization?

I suspect that your PO / dev manager is using the review for an alternate purpose however. You should start by clarifying what this is. For now I will guess they are using it for the purpose of ensuring recognition of work done, possibly with the intention to help them in the role managing other developers.

In order to convince them to stick to the intended purpose of the review you should aim to do two things.

Firstly you need to convince them of the importance of the true purpose of the review. I would recommend that you start by reviewing the scrum guide until you understand the purpose yourself. Once you have this I would raise the shortcomings of the current process at a sprint retrospective. Personally, I would start by raising my concerns that stakeholders weren't present at the review.

Secondly you need to provide an alternative way for them to achiev their goal for the current sprint review. As your dev manager / PO seems to be a supporter of agile in principle, they should recognize the importance of discussion. So I would start by having a discussion with them around what they want to achieve out of the scrum review. This could easily come out naturally in conversations in a retrospective if you raise your concerns over how the sprint review went.

Assuming they do in fact believe there is an issue with employees not feeling recognized for their work, the sort of questions I would be asking them are;

• If you could have another meeting beyond the sprint review to help promote recognition of work?
• Why they believe that presenting in the sprint review promotes recognition?

Answer 2

You need to review the product increment. From what I understand from your question, it seems to me that you are mostly reviewing the work that you did to build the actual increment.

If you want to track the work, acceptance testing or integration testing should be tasks associated with a User Story. You might also have a task for development, for code review, for deploy, etc. Are you going to discuss these too at the review? Maybe the developer that did the code review should bring up a presentation slide with how many bugs she found, or maybe show a "thumbs up" or "thumbs down" image depending on the quality of the code? I'm sarcastic of course, just to drive the point further home. Such activities are unimportant for stakeholders. Of course developments should be done, code reviews performed, the work tested, integrated, deployed, etc. No need to say anything about that unless it's relevant in some way (maybe you faced some problems and the way you solved it is important or innovative, maybe you might need some decisions taken about changing the approach, or whatever).

If such unimportant presentations end up filling the full review meeting, and there is no more time to actually inspect the product increment, then you have an even bigger problem. Feedback is needed, conversations need to hapen, and decisions need to be taken regarding the product. If these don't happen or get delayed too much, you risk building a product of less value.

So focus on the product increment.

As for people being left out, what the other posted answer mentions is correct: this is a non-issue. In one of my teams we had a rule that each developer should present the User Stories they worked on, just to give a further sense of accomplishment for the work, to make people more responsible, to also help them gain presentation skills, boost their confidence, etc. But more people worked on the same User Story: testers, reviewers, other developers pairing with the one doing the presentation at the review. So inevitably people were left out. They didn't mind. No harm done. But what happened and was doing harm was that a lot of time was wasted at the review meeting while people moved around the room to sit at the computer to present their own work. But we inspected and adapted. We eventually had the Product Owner present all the stories :).

So inspect and adapt. Bring this up at the Sprint Retrospective. Don't waste time trying to convince management to limit the reviews to just the product increment. They didn't ask for that. The team decided to do so. So discuss it and work it out with your team.

Answer 3

Several things stand out here.

I don't think that the methods of organizing the work in the Sprint Backlog is important. What external stakeholders typically care about is the work that was represented in the Product Backlog and brought into the Sprint. I'd start by focusing on those Product Backlog items rather than items that are used only in the Sprint Backlog to decompose and make work visible. Every Sprint should also have a Sprint Goal, which can be used to help focus not only the work during the Sprint, but how the work is reviewed at the end of the Sprint.

I also think that the notion that "non-developers will feel left out" is a non-issue. This feels like the team isn't a cross-functional, self-organizing team. One of the focuses of the Sprint Review is on the Increment that was produced. However, part of the Sprint Review is also reviewing and reorganizing the Product Backlog - this is a good opportunity to discuss the things that have been refined and any open questions or issues that may impact the Product Backlog.

I'd recommend reviewing the Scrum Guide's description of the Sprint Review. Understand the intent of the event and how each element described supports that intent. Then, see if you are meeting the intent of the event based on how you are executing it now. If you aren't meeting the intent, improvements should be made to move closer to that intent.

Answer 4

I think your devs have a reasonable point that making research & testing visible to stakeholders has value, both specifically in prioritizing the backlog and more generally to bring stakeholders a bit "behind the scenes" so they are at least a little aware of these under the hood kinds of things.

I would suggest a hybrid approach: keep the main focus on what contributes to the product increment, but as a team select one "behind the scenes" item to be reviewed each sprint. That way everybody gets to present sometimes; the stakeholders are educated on the less obvious stuff; and most of the review time is used by the book. If the team concern is about visibility and getting acknowledged for their work, I might also make a point of mentioning who the non-devs were that contributed to a user-facing story.

(And then probably see if I could encourage the team to think more team-wise than individual-credit-wise; but humans are human, after all.)