Sprint Review Event

Question

When Sprint Review event should begin? Is it required to have it at the end of Sprint or it can be done at first day of sprint?

Answer 1

The November 2020 version of the Scrum Guide makes it very clear when the Sprint Review occurs:

The Sprint Review is the second to last event of the Sprint

This places the Sprint Review before the Sprint Retrospective, which is the last event of the Sprint.

However, just stepping back, it only makes sense to have a Sprint Review at the end of the Sprint.

Consider the purpose of the Sprint Review:

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

The team needs to receive feedback on their progress and determine next steps. Then, they can take that feedback from the Sprint Review as one of the points of discussion into the Sprint Retrospective to understand how they can best improve their way of working.

Answer 2

TL;DR

The Sprint Review is always at the end of a Sprint. It cannot fulfill its purpose properly until the Sprint has produced an outcome for inspection by the Scrum Team and key stakeholders. In other words, there would be almost no value to extract from a Sprint Review held on the second day of your first Sprint.

The Sprint Review is also a defined event in Scrum. Part of its definition is that it is held at the end of a Sprint right before the Sprint Retrospective.

You can do whatever you like, of course, but then whatever you're doing is not Scrum. Nothing stops you from defining or practicing your own agile framework, but "doing your own thing" referred to as "cowboy agile," "Scrum-But," or "Scrum in Name Only"—and those are the more generous terms. "Setting yourself up for failure" is probably a more accurate term, so don't do that!

Analysis, Explanations, and Alternatives

Is it required to have it at the end of Sprint or it can be done at first day of sprint?

It can't be done at of the start of a Sprint because you can't "review" something that hasn't happened yet. The 2020 Scrum Guide describes objective of the Sprint Review as follows:

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations.

While one might argue that the agenda for the event, which includes:

1. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

2. [T]he Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment.

3. [A]ttendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities.

could refer to the previous Sprint, doing these things after Sprint Planning (which is always the first event of a new Sprint) would essentially postpone one of Scrum's most essential inspect-and-adapt loops by one Sprint every iteration. This would represent an anti-pattern since you want feedback and lessons learned to be incorporated before selecting new work for the Sprint.

In fact, this is so important that the Scrum Guide explicitly says:

The Sprint Review is the second to last event of the Sprint[.]

The last event is the Sprint Retrospective. The results of the Sprint Review often feed into the Sprint Retrospective, so separating these events by the length of a Sprint or holding the events across Sprint boundaries largely defeats the event's intended purpose.

Scrum Doesn't Fit Everyone

Please note that unless you've been instructed to do so by your leadership team, no one is forcing you to use Scrum. There are plenty of other frameworks to choose from, or you can roll your own even though doing so is likely to be less thoroughly vetted by years of community practice.

You can use the Kanban Method, systems based on Lean thinking, SAFe (which isn't agile and implements a bastardized version of Scrum at the team level), Extreme Programming, Amplio, or any other systematic approach that pleases you. However, if you're going to do Scrum at all, you should do it properly. Half-baked implementations are a leading cause of failure in all agile adoptions, which is why the authors of Scrum explicitly state that kinda-sorta following Scrum can't be called Scrum.

As Yoda says:

Do or do not. There is no "try."

If you don't want to follow the Scrum framework, find something else that suits you better. However, despite the perception that Scrum is inflexible, only the defined elements of the framework are immutable. Within that framework is a lot of room for empirical and idiosyncratic approaches.

Evaluate the Underlying Problems Fundamental Changes Might Address

That said, you should really spend some time thinking about why you'd want to implement a change like this, and what value you think it would provide to your process, before either adding new events to the framework or replacing the framework altogether. If you don't have a good reason, that's usually an indicator that the team lacks experience with the framework or lacks an understanding of the value of the framework events. It's the job of the Scrum Master¹ to work with the team and the organization to explain the purpose of the event, and to assist the Scrum Team in uncovering the root cause of why the team isn't finding the event useful as defined by the framework and why they think another event or a fundamental change to the framework would be beneficial.

---

¹ Aside: The Term "Scrum Master" Ought to be Renamed

The term "Scrum Master" is currently not changeable, but just as the Scrum Guide replaced the term "Backlog Grooming" with "Backlog Refinement" I'd like to see the role renamed "Scrum Referee", "Scrum Coach", or "Scrum Facilitator."

---

This type of analysis can be done during a Sprint Retrospecive, or at any time if it represents an existential problem that puts the Sprint Goal in jeopardy. In either case, there should be a reason to consider such a radical change, and there are usually better solutions to whatever the root cause is than breaking the fundamentals of the Scrum framework.

If the problems truly are legitimate, and there are no other solutions, then either accept that you're not "doing Scrum" or find a different framework that fits your organizational needs better. Otherwise, use the experience as a teachable moment to help the team learn root cause analysis or to better understand how the Scrum framework as defined supports Scrum Theory and the four values and twelve principles of the Agile Manifesto.

Answer 3

You could hold the sprit review whenever you are able to demonstrate a useful increment of work. That's typically on the last day of the sprint and it really should be done before the next sprint starts so that you can take account of any customer feedback in the following sprint planning meeting.

I would suggest scheduling the review at the same point in every sprint to make it easier to get people's time commitment and to give your audience confidence in the regular cadence of delivery.

Answer 4

"Sprint Review" is the time-boxed event for acceptance of a sprint. That's why, it is done at the end of a sprint, not at the start of the next sprint.

It also affects the next sprint; let's say there's a problem or misunderstanding about a story and that came out in the sprint review, a defect work item can be added to the next sprint.

Answer 5

It can be any time. It totally depends on the availability of the product owner and the readiness of your items for review. Agile suggests the frequent feedback loops.