Let's say we arrange a sprint in agile methodology.
The sprint will last for 2 weeks.
let's say the first day is Monday of the 1st week &
last day is Friday of 2nd week.
In this setup, on what days should below mentioned event take place:
please add if I have missed any other sprint ceremonies.
In Scrum, there are five Scrum events: Sprint Planning, Sprint Review, Sprint Retrospective, the Daily Scrum, and the Sprint (which is a container for the other events).
The Scrum Guide defines when these events happen.
First, Sprints are consecutive. That means that there is little to no downtime or extended gaps between the end of one Sprint and the start of the next. If your Sprint ends on a Friday afternoon, your next Sprint would start that day or first thing on Monday morning, depending on exactly when the events happen.
The order of Sprint Planning, Sprint Review, and Sprint Retrospective are well defined. Sprint Planning is the first event of Sprint, Sprint Review is the next-to-last event, and Sprint Retrospective is the last event of Sprint.
These events are also timeboxed. Sprint Planning is timeboxed to 8 hours, Sprint Review is timeboxed to 4 hours, and Sprint Retrospective is timeboxed to 3 hours. These timeboxes are based on a one-month Sprint. For shorter Sprints, the events are "usually shorter", but the maximum timebox remains the same. In my experience, a team that has a very good understanding of the outcomes of the events and is effective at executing them can often complete them in a proportional time. This means an effective and efficient team using two-week Sprints can complete Sprint Planning within 4 hours, Sprint Review within 2 hours, and Sprint Retrospective in about 1 to 1.5 hours. A team still learning Scrum will likely have longer events.
Given these timeboxes and the specific case, one possible order of the events would be Sprint Planning on the first Monday of the Sprint and the Sprint Review and Sprint Retrospective on the last Friday. However, another order could be to have the Sprint Review on Friday and move the Sprint Retrospective and Sprint Planning to Monday. A third option would be to have the Sprint Review on Thursday, the Sprint Retrospective on Friday, and the Sprint Planning on Monday.
Product Backlog refinement, development, testing, and other activities happen within the Sprint. The needs of the team and the demands of the customer happen. Teams should attempt to minimize sequential work and focus on collaboration and
There is no set method of performing refinement. Different teams work in different ways. Some teams prefer to refine as a large group and set up longer meetings. Other teams prefer to refine individually or in small groups and come together in shorter sessions to synchronize and check in on the current state of refinement.
When planning development activities, remember that the Sprint Review "should never be considered a gate to releasing value". This means that the team does not have to wait for the Sprint Review to complete to release or deploy value-adding changes to the system and allow the users and customers to access them. This enables practices such as Continuous Delivery and Continuous Deployment to be consistent with the rest of the Scrum framework.
As of this writing, the Scrum framework has five defined events, most of which are flexible about their length and scheduling. However, most framework events have a clear ordinal sequence within each Sprint. in which they should occur. 100% of the work you're breaking out belongs inside the time boxed cadence represented by the Sprint.
Here's an example based on the Monday-Friday two week cadence you defined in your question.
For a two-week cadence that starts every other Monday and ends every other Friday, this is a fairly typical schedule for the formally-defined Scrum events.
Hold your Sprint Planning on a Monday, scheduled around the core hours planned for your routine Daily Scrum.
Example: If you expect to hold your Daily Scrum at 11:00 AM each day, I personally recommend against trying to schedule your Sprint Planning at 8:00 AM since you undoubtedly defined core hours for a reason.
Hold your Daily Scrum at the regular time if and only if it occurs before the scheduled Sprint Review.
Hold your Sprint Review on Friday at a predictable time.
Make sure to start the Sprint Review early enough to be able to follow it with the Sprint Retrospective if you plan to hold both the same day!
Hold your Sprint Retrospective immediately after the Sprint Review, suitably time boxed to extend no further than the end of the current day.
This should ideally be the terminal event of the day. If you can't schedule it that way for any reason, such as needing to include stakeholders who can't routinely meet until late in the day, then consider moving the Sprint Review back a day to every other Thursday, and continue to hold your Sprint Retrospective on Fridays. One less working day is less important than a predictable cadence and sufficient slack in the process.
Hold your next Sprint Planning event the next business day, i.e. the Monday after your Sprint Retrospective.
Other elements you asked about are either mapped differently in Scrum, or are otherwise undefined by the framework and up to the Scrum Team to optimize based on real-world context. I'll provide more specific analysis and guidance below about particular items you called out in your question.
Get a cup of coffee before reading below this line. It's a long answer with a number of interdependencies, so load up on caffeine first!
You provided the following list of framework activities in a specific order. The 2020 Scrum Guide™ no longer calls these activities "ceremonies"; they are now formally called events. Let's address each activity's framework fit first, and lightly touch on sequence as we go. Then we'll revisit the ordering of events and some broader considerations afterwards.
Backlog grooming
This event has been renamed to Backlog Refinement. It is an ongoing activity but not a sequenced event. The primary constraint is that the activity should happen before the next Sprint Planning event to be effective.
Sprint planning
Sprint Planning is a defined event, and has a defined ordinal placement in the framework.
Actual development
There's no such terminology in Scrum. The building of the Increment is all the work done during the Sprint to achieve the Sprint Goal.
Code freeze
There's no such terminology in Scrum. While you could implement such a practice without violating the Scrum framework in preparation for completing an Increment, you could theoretically continue working right up until the Sprint Review.
The purpose and value of a "code freeze" has a lot more to do with your tooling and internal team process than with Scrum, although the Scrum cadence might also need to fit an organizational process that imposes code freezes that impact delivery. None of that matters for Scrum since the framework doesn't require that what is delivered must be released. This is a much broader topic than your original question, and should be opened as a separate-but-linked question for a thorough canonical answer.
Testing
Testing is not a defined event in Scrum. It is best thought of as part of the Definition of Done, and happens throughout each Sprint. While not required by the framework, test-first development practices are often used, which then brings testing into scope at the beginning of each Sprint and continuing through completion of each Increment.
Pushing the sprint's development to higher environments (like staging, prod)
This is not a defined event within the Scrum framework or prescribed as part of the Sprint, but agile CI/CD practices such as continuous deployment or continuous delivery are allowed and encouraged by the framework. When and how you do these things within each Sprint is an emergent-design process for your team to define, routinely inspect, and adapt as needed to meet their goals.
Sprint retrospective
The Sprint Retrospective is a defined event within the framework. It is the terminal event of standard Sprint.
Sprint demo
This is not a defined event within the Scrum framework. However, demos are often done as part of the Sprint Review, which is defined as the penultimate event within a Sprint.
First of all, the Sprint itself isn't really an event, even though it's unfortunately listed within the framework's section named Scrum Events. If you read the section closely, it's actually just an ephemeral container for all the other events as defined as follows (emph. mine):
All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.
Nevertheless, the Sprint is listed as an event, so it's listed first sequentially since you can't have the other events if you don't have a Sprint, but it's often more helpful to think of it as a roll-up activity that bounds the other sequenced and ongoing events. The fixed events defined within Scrum are:
The Product Backlog refinement activity is actually defined most clearly in the section on framework artifacts, where it is described thus (emph. mine):
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
So, while the refinement activity is defined as an ongoing activity within each Sprint that ultimately feeds the Product Backlog artifact in preparation for the next Sprint Planning event. Outside of the initial Product Backlog, refinement must come before Sprint Planning because:
Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint.
If your Product Backlog items aren't refined and in some Definition of Ready state (e.g. INVEST) then you'll spend a lot of time in Sprint Planning trying to select backlog items that fit within a single Sprint and form a singular, cohesive Sprint Goal.
Sprint
+-----------------------------------------------------------------------+
| Sprint Planning | Daily Scrums | Sprint Review | Sprint Retrospective |
+-----------------------------------------------------------------------+
<--------------------- Product Backlog Refinement -------------------->
The Daily Scrum is hard to represent in an ASCII diagram because it's a recurring event that should happen every working day. Meanwhile, refinement is ongoing, so it can be spread out or consolidated based on a given team's inspect-and-adapt practices.
Some practitioners argue about whether you should have a Daily Scrum on the days you have Sprint Planning or a Sprint Retrospective. The answer to the first is implicitly "no" because "Sprint Planning initiates the Sprint". The answer to the second is explicitly "no" because "The Sprint Review is the second to last event of the Sprint...[and t]he Sprint Retrospective concludes the Sprint."
You could certainly create edge cases with unusual scheduling, such as tightly time-boxing your Sprint Review and Retrospective, immediately followed by Sprint Planning, to the latter end of a single day. In that case the Daily Scrum would still fit within the current Sprint if held before the Sprint Review.
Scrum defines the following time limits for events:
If your Daily Scrum is generally held at the beginning of the workday, you could still hold the time boxed Daily Scrum event before the final events of the Sprint, i.e. the Sprint Review and the Sprint Retrospective. However, while packing 3-4 framework events into a single day is possible, in practice I would consider that a fairly contrived edge case, especially since the framework also says:
A new Sprint starts immediately after the conclusion of the previous Sprint.
In real-world implementations, you'd have to go out of your way to gerrymander a Sprint cadence that provides adequate time for all the necessary events in proper sequence to occur successfully within the allotted time on a single day. It's not impossible, especially with shorter time boxes all the way around, but it's unlikely and not particularly useful to compress time this way.
Depending on your established cadence, the Sprint Review and the Sprint Retrospective might be held on different days. In that case, having a Daily Scrum before the Sprint Review is certainly allowed by the framework, and may even help the team sync up about how they'll present the Increment during the review. If the review is held later in the day and sufficiently time-boxed, there might even be some last-minute work to coordinate the day of the Sprint Review. If it adds value and fits within your normal cadence, hold the Daily Scrum. If not, then don't.
There's less utility value in holding a Daily Scrum after the Sprint Review but before the Sprint Retrospective, even if the events are spread across multiple days. Strictly speaking, the framework doesn't permit holding a Daily Scrum between the Sprint Review and the Sprint Retrospective, but if the team finds value in it based on your specific cadence and if it doesn't create busy-work or time compression then go ahead and do what works. I just want to be clear that this isn't what's defined by the framework, but it's enough of a minor edge case that I wouldn't call a flag on the play simply on principle.
Some of what you're asking about is the practices or patterns for product development within a Scrum Team. However, Scrum Theory is fundamentally based on empirical feedback loops and adaptation by self-managing teams. As a result, Scrum provides a scaffolding that allows teams to wire up their own processes and based on the set of practices that are most effective for that particular team.
Many Scrum teams will borrow heavily from Kanban, DevOps, Test-Driven Development (TDD), or other domains when it comes to defining their own best practices. Some people like this about Scrum and others hate it. Nevertheless, that's what Scrum offers: a chance to build and optimize your own best practices within whatever constraints are defined by your project and the small number of fixed "rules of engagement" defined for you by the Scrum framework.
Scrum works very well with CI/CD frameworks and test-first approaches. Collectively, those practices can be tuned to meet your testing and delivery requirements. Scrum-the-framework doesn't mandate that you follow DevOps, write unit tests, do continuous integration testing, or anything similar. It simply requires that you define what "done" means, which usually includes some level of quality testing, and leaves it up to the team to determine the best approach.
Some basic principles for team agility apply:
In other words, there's no universal answer. You have to lay out the objectives within the framework and within your project constraints, and then support and trust the team to figure out how to most efficiently deliver that in bite-sized increments.
