TL;DR
The Sprint Review is always at the end of a Sprint. It cannot fulfill its purpose properly if done before there is not yet a Sprint to review, e.g. what would be the value of a Sprint Review the second day of your first Sprint?
It is also a defined event in Scrum, and 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:
-
The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
-
[T]he Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment.
-
[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), that 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 Master1 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.
1. 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.
