Current Episode

Episode 9:

How do we improve our giant, multi-team Sprint Review session (or Sprint Reviews in general)?

Dae-Ho’s organization has multiple Scrum teams, and one giant all-day Sprint Review. People come and go throughout the day, and stakeholders are not always present. He wonders if there’s a better way to do things. Even if your company only has one Scrum team, the tips in this episode will likely help improve your Sprint Reviews too.

Like the podcast? I’d love it if you’d take 60 seconds to rate it in iTunes.

Do you have a question for the show? Submit it at


Leave a Reply

Adam: Welcome to Agile Answers. I’m Adam Weisbart, your Certified Scrum Trainer and agile coach. Each week, I get your questions about Scrum and agility, and I answer them, here on Agile Answers.

Often, seemingly complex questions could be answered just by looking at the basics. Today’s question comes from Dae-Ho and he is struggling with a problem that seems quite complex, but if you actually just break it down and get back to the basics of Scrum, I think it’s actually relatively simple to fix. Now, things that are simple are not always easy, but at least it will give us a road map for figuring out how to address the problem. So without further ado, let’s listen to Dae-Ho’s question.

Dae-Ho: Hi Adam. My name is Dae-Ho and I am a Scrum master for an engineering team in San Francisco. To date, our company has structured sprint reviews as an all-day affair, where a single large meeting room is booked all day and each Scrum team presents to whoever is present in the room. For this meeting, every engineer and product manager is optionally invited, so the audience for each sprint review could vary from about 20 to 40 viewers at any given time.

I’m struggling with this large scale format for several reasons. It feels more like an evaluation or a demo than it does a sprint review in the sense that we’ve created a culture of wanting to demo complete things and only talk about things that went well. This results in a scarce amount of constructive feedback or productive questions. We’re demoing things that are too late to accept feedback, the people we are presenting to aren’t actually the stakeholders or people that are just too intimidated to ask questions in front of a large audience.

I was wondering, Adam, do you have any recommendations on how to buck this trend? Should we hold more private sprint reviews with a smaller guest list, inviting only relevant stakeholders? I’m concerned that having private reviews at scale may fall apart with every team booking the same stakeholders for the same time. Would you try that approach or do you have any other recommendations on how to possibly salvage our current formats so that the right audience is in the room, but still be schedule-friendly? Thanks so much for your help. You can provide any guidance on this one.

Adam: Dae-Ho, thanks for the awesome question. So as I said before, complex questions like the one you have can often be resolved by just focusing on the basics. So there’s some things that you listed that I like a lot, and I think are a great approach, and some other things that are less ideal. But before I dive into all of that, I think it would be wise to take a look at why we have sprint review to begin with.

And it seems like maybe sprint review is for the product owner. It turns out, sprint review isn’t just for the product owner, essentially, it is for the stakeholders. It’s to get feedback from the stakeholders in real time. We’re not doing it through a proxy of a product owner. When all else fails and we have to do it through a proxy, that person certainly is the product owner. But one of the things you called out in your question was that you were doing these all-day demos and they weren’t for the stakeholders. Well, the whole reason to have this to begin with is to do it for the stakeholders.

So my first recommendation or first question, I guess, for you or anybody in this situation is why aren’t your stakeholders there? We work with our product owners throughout the sprint, so we should be able to get feedback from them whenever we need it, really. We can get it anytime during the two-week sprint, if we have two-week sprints, of course. And often people will wait till sprint review to get feedback from even just their product owners. Now as you point out in your question, at this point, it’s too late to actually use that feedback, right? We are at the end of the sprint. And if the color of a button, for example, is incorrect, and a product owner won’t accept that item, there’s no way for us to fix it as a team.

So the way to resolve this is to simply work with our product owner throughout the sprint. Ideally, they’re sitting with you. They’re co-located with your team. Or if you’re a virtual team, they’re co-located in whatever virtual setup that you have. And when the product owner is not always available because they have to go talk to customers and stakeholders and all that good stuff, they’re available often. And the team can get feedback from them throughout the sprint. And if we think about what a product owner is, a product owner is a proxy or the voice of the customer, right? So they can answer questions. They can make definitive decisions about how to move forward when it would be impractical to talk to all of your stakeholders, right?

So if you currently don’t have a product owner that is in this position, that has the authority to make decisions about how to move forward, that’s actually the first place I’d start. And it wasn’t directly in your question, but it would help sort of clarify a bunch of this. So I would make sure that you have a product owner that has the authority to say when something is done. After all, they own the definition of done, so they should be able to say when something is done.

Secondly, one of the things that I like about your format for this sprint review is that anybody who wants to can be involved. I think that’s great. It also sounds like, frankly, it’s a little bit of a liability in your situation, right? With great power comes great responsibility. One of those responsibilities is to make sure that the stakeholders are available and there for your sprint review. So I would figure out how not to make it really optional for stakeholders, but how to get them involved. I’m not sure what sort of impediments you’re running into, but one of them that you outlined is if you have a bunch of teams, it’s actually not possible for every important stakeholder to be at every sprint review. If you’re doing them all in one day, I suppose if you keep adding teams, if you keep scaling out, your company is successful and you add more and more teams, there will be some point that one single person cannot go to all sprint reviews, unless you had sprint reviews just go on and on and on, days and days and days, which is not ideal for anybody.

So the question you had about dealing with the scaling problem, frankly, is that not every stakeholder is going to be able to go to every sprint review. And that’s all right. But they’re not really, how should I say this, they’re not optional. Stakeholders in general are not optional for any given sprint review. They really need to be there. If for some reason they just can’t, one of them can’t because of scheduling conflicts or whatnot, then your product owner gets to be the voice of that customer, of course, right?

And I would also expect that a strong product owner is spending a bunch of time with all of your stakeholders throughout the sprint. So a bunch of the work that I think you’re trying to cram into sprint review could be dealt with one on one with the product owner and the stakeholder or a group of stakeholders at any time during the sprint. Their feedback is essential for driving the product, for creating your product backlog, for enhancing your product backlog, and so I would expect that the product owner is doing that ongoing with your stakeholders, especially if you have a lot of teams, and especially if you have a lot of stakeholders.

So that’s how I would clear up that part. I would one, make sure we have a strong product owner, again; and I’ll make sure that product owner is spending time with our stakeholders even outside of sprint review; and then thirdly and probably most importantly, that stakeholders aren’t optional for sprint review. They’re the whole reason we have sprint review. So I understand not every single stakeholder can come to every single sprint review, but in general, they are not optional for said sprint reviews.

Now speaking to your point about this feeling more like an evaluation or a demo and not a sprint review, in that you’re only demoing things that are complete and you’re only talking about thigs that went well, I actually think you have the definition of a sprint review in many ways right there. So let’s look at the definition of sprint review.

Again, one of the things that I recommend doing in your sprint review is just saying here are the four items, or however many they are, that we committed to but did not complete. These are the items that our team committed to in sprint planning, but did not complete. They’re user stories or product backlog items. We explain what they were, and we stop the explanation at that. I actually agree with the way you’re currently doing it in that you’re only demonstrating features that you have finished. I think this is very important for the team to get good at estimating your work, for getting good at meeting commitments or forecasts. I think that this is actually quite essential. I think reporting, “Here are the things we committed to but did not complete,” is good enough for those things.

And then going on and demoing the features that you completed to get feedback about them, and when you get this feedback from stakeholders, you’re right, it can’t really affect what you currently delivered for the sprint, because the sprint is over. You’re in sprint review. It can, however, inform the product backlog, which is the reason we have this sprint review.

So the product owner will accept it based on their understanding of what they gave the team to begin with in sprint planning and working with the team throughout the sprint. But if that spurs new ideas from stakeholders and the product owner decides they would like to change the product based on that feedback, they would just create new product backlog items. So you’re right. You can’t change the items that you just complete, but you can add new items to the product backlog for a future sprint. So I think that would address the trouble you’re running into there.

Lastly, I think I’ve mentioned this, but you said schedule-friendly, and I do understand when doing this at scale, that it can be challenging. I don’t think that every stakeholder can go to every single sprint review, if you have a really large organization, but they can go to the ones that are appropriate to them, and then maybe have each team, as part of their sprint review, put together just a short paragraph, something that explains, “Here are the features that we completed this sprint,” and those can go out to everybody in the organization. Now this shouldn’t be like a dry, boring release notes kind of thing. Maybe think of it more as a little press release. “Here are the exiting things that our team completed this sprint,” in a very user friendly way. We don’t have to get very technical, but it would be a way to share with all of the organization, if you are really past the point of being able to go to everybody’s sprint review in person.

So Dae-Ho, in closing, I think it would be wise to one, not make sprint review optional for important stakeholders. Two, to make sure you have strong product owners who can work with these stakeholders throughout the sprint, because we know we’re going to need more feedback from them than just in this sprint review, and it’s possible that not every stakeholder will be able to go to every sprint review, but they can make up for that by actually talking with their product owners throughout the sprint. And lastly, I agree that you should just be demoing things that are done, just the things that are done and reporting, just briefly, on the things that you did not complete as a way of keeping of everybody accountable.

Thanks so much for your question, Dae-Ho. I hope that was useful. For having your question answered on the show, you’ll get a deck of my Agile Antipattern Cards. If anybody else out there listening has a question they would like answered on the show, you can go to And right there on the home page, you can record a message just like Dae-Ho did, which I might answer on a future episode. And of course, if I answer it, you’ll get a deck of the Agile Antipattern Cards as well.

Just remember, whenever you’re feeling stuck, go back to the basics. Questions always seem quite complex, but often can be broken down and looked at from their basics, like why do we have sprint review? What’s the purpose, and what is the role of the stakeholder and the product owner? I know it’s easy for someone on the outside to say. When you’re in the thick of it, it seems much harder. I’ve certainly been in that situation. So if you feel stuck, submit a question. I’d be happy to do my best to answer it.

Well, until next time, stay agile. Never change.

Past Episodes

Episode 24:

What should we do instead of painful “Annual Planning”?

Episode 23:

Agile Virtual Summit Preview: Lyssa Adkins

Episode 22:

How do we make sure we have cross-functional teams and why does it matter?

Episode 21:

What agile practices can you recommend to our game development studio?