A sprint review is held at the end of each sprint. It is a chance for the team and stakeholders to inspect and adapt the product. If stakeholders like what the team has done, the teams should do more of it. If the stakeholders don't like something that team is done the, team may have to go back in and rework it A lot of teams refer to the sprint review as a demo. While demonstrating the product is a key component of the Sprint Review, there's more to it than that. The Sprinterview is also the time to collaborate on the next things to be done to add value to product. Let's walk through what a typical sprint review might look like. Let imagine we're a team opening a new chain of pizzerias. And in the sprint that's coming to an end, the team focused on developing the perfect pizza crust. Our product owner wants to ensure we get valuable and useful feedback and so invites some internal stakeholders. Perhaps our national marketing VP, a couple of salespeople, and our VP of operations who is focused on keeping costs down. It would be a shame to invent a perfect crust that costs $50 a slice. Our product owner also invites a few of our initial franchisees, people who will own and operate individual restaurants in our new chain of pizzerias. And hopefully they invite me because I'd really love to try this perfect crust. During the meeting, the team shares what their goal was for the product increment and what they accomplished. Then they ask the other participants to taste the crust and provide feedback. During the sprint review, the scrum master fosters a really open, transparent conversation about the team's work. One participant might want a lighter crust. Another might love the taste, but wonder if it can be made gluten-free. another might be concerned that to achieve the great flavor, the pizza is cooked longer at a lower temperature, which will affect cost and delivery time. The product owner processes this feedback and uses it to influence what the team will build next. If the gluten-free idea is essential, it may be added to the top of the product backlog. Reducing cooking time, on the other hand, may worth doing, but doesn't need to be done immediately. Not all feedback needs to acted on. Perhaps only one person thought the crust should have a lighter taste. The product owner may choose to ignore certain comments. Ultimately, its the Product Owner's call. Sprint reviews should occur at a regular cadence at the end of every sprint and are no longer than four hours for a one-month sprint. The majority of teams find that an hour, maybe two, is sufficient.