When Should Each Scrum Event Take Place During A Sprint

To properly schedule the Scrum Events, you need to think about the best structure and flow that is suitable for your team and for the project context. It might sound easy but you have to consider a couple of things and don’t make the plan by yourself.

To choose the most appropriate time for each event, consider things like your team members living in locations with different time zones, as well as the readiness of the requirements. Official holidays and time off might worth to be considered as well.

Every project and company is different and having a general rule that you follow doesn’t make much sense if it doesn’t match the context. There are some things that I tried to monitor when planning the calendar for my teams. They helped me have a clear agenda for the entire sprint.

Choose the right moment for your Sprint Planning

Wednesday is the best weekday to choose for Sprint Planning if your project context allows it.

And I bet that right now you are wondering why is it so special to this day and why not Monday. That’s when the week starts, so it would make more sense to start a new sprint when a new week begins, right? Here’s the catch.

Holidays & Vacation days: Most of the times, we observe days off on Mondays or on Fridays, especially if a holiday will fall on a Saturday or Sunday. Also, often people take one vacation day on Friday or Monday to have a 3 days weekend.

Or when there’s a single-day holiday that falls on Monday, you’ll most likely take Friday off to have a four days weekend. So just imagine planning the work for your two-week sprint when half of your team is out for three days weekend. 

Also, according to Zippia’s research, 20% of all sick days occur on a Monday.

The Product Backlog has a minimum set of prioritized items well understood by the Development Team.

In my early days as a Product Owner, I’ve learned that going to Sprint Planning with your backlog items not prioritized will waste everyone’s time. 

Even if it’s a short-term plan because you didn’t get the chance to organize the items for one sprint ahead, make sure that your backlog contains at the top at least a couple of well-defined and prioritized items that the team can take on in the first couple of days before going to the planning meeting. 

Hold the Sprint Planning in the first part of the day.

As the end of the workday approaches, it becomes more difficult to focus. Your mind is fresher in the morning and it’s easier to make a good plan and analyze how you’ll do the work. 

Also, because the Sprint Planning is held on the first day of the sprint, prepare for it early in the morning and allow your team to concentrate on the items they have to work on in the remaining hours.

It applies to the rest of the Scrum Events as well, not only to Sprint Planning. That is because people are too tired towards the end of the day and you won’t get the same results as you will in the first few hours. 

Make sure your Daily Scrum takes place every day 

Hold Daily Scrum early in the morning.

When the team members are connecting with each other early in the day, they can organize their work for the following couple of hours. If your working hours start at 9:00 am, that is not really the best time for you to schedule the meeting.

Allow yourself and your team to get some coffee first. Anytime between 10:00 am and 11:00 am is a good time to have your Daily Scrum. 

You should meet every day for the Daily Scrum, no exception.

The team should meet every day and discuss their progress, or inform the rest of the team about impediments or risks they’ve encountered. To make a good plan for the day, these things have to be discussed and known by the entire team.

Always show your work in the Sprint Review

At the end of each sprint, the team should deliver a potentially shippable increment.

By doing so, you show what value will the work performed in that sprint, bring to the final product.  

The Sprint Review should take place on the last day of each sprint and it must happen before the Development Team releases the code. The rationale behind this is that the Product Owner can approve or not what is about to be delivered to customers.

Releasing the code into production before getting feedback from the Product Owner, cancels the entire purpose of the Sprint Review. 

Still, there are some rare cases when the Product Owner needs to release a functionality before the end of the sprint. Here, it makes sense to hold the Sprint Review earlier in the sprint. 

Inspect and adapt in Sprint Retrospective

The Sprint Retrospective must always occur at the end of each sprint.

On the last day of every sprint, is very important for the team to meet, inspect what happened during the sprint and improve. And you should not skip the Sprint Retrospectives because it’s the best place where the team can identify how to do things better. 

If the Development Team has been working together for a couple of years, they might find it hard to think of ways to do things better or even finding what to improve. Don’t give up on retrospectives if that happens.

They might be also used to some things not going well that they don’t even realize. Try to bring into discussion some topics and ask them what they think, that most definitely will generate some new ideas to debate. 

When can you incorporate the Backlog Refinement in the sprint

You can schedule a Backlog Refinement session anytime during the sprint.

Some teams prefer to refine the backlog in the middle of the sprint, with one week before the Sprint Planning. This allows teams to prepare just enough work on the backlog for the upcoming sprint, and sometimes for one or two sprints ahead.

I prefer this cadence as well because the teams don’t feel overwhelmed by too many meetings taking place in the same week. For example, if your Sprint Retrospective takes place on a Tuesday, normally the Sprint Planning will be scheduled on Wednesday.

Therefore, you’ll be having 3 long meetings in the same week.  

Whenever the Product Backlog lacks ordered and estimated items.

Here, the Product Owner must prepare items together with the team as soon as possible. Even if it’s about a couple of tasks that the team will work on only in the first few days of the next sprint, make sure you don’t go into the Sprint Planning without having just enough for the first two to five days. 

Final thoughts

There are many elements to take into consideration when creating an agenda for your sprint. And it’s also important to be prepared for any unexpected events so that you can act early. 

Try to find the best approach together with your team, present them your option and let them challenge the plan, and bring changes where they see fit. This should be a joint effort that will make them more involved in the process and in the project because they know they had their part of the contribution. 

The team won’t feel like someone demands them to work in a certain way, but it will motivate them to follow a plan they agreed with and worked on. 

What other things do you consider when making the agenda for the sprint? How is your team involved in the process? Let me know in the comments down below.