Schedule of Sprint Review, Retrospective and Planning

Here are some ideas, but there is no ultimate answer:



One option is to split it over two days: end the first day with the Sprint Review and Retrospective, and start fresh the next day to plan the newly-started Sprint.



Some teams will do the Review and Retro on a Friday and the Sprint Planning on the following Monday. The weekend makes the Sprint boundary clear. On the other hand, if there were valuable insights brought up either by stakeholders during the Review (which the Product Owner can leverage) or by the team during the Retrospective, these might not be as fresh in their mind after the weekend.

Hi Roddy,

We currently run 2 weeks sprints. So, every two Friday in the afternoon, we have a 2 hours "ceremony" by doing:

• Sprint Review (around 1 hour and 20 minutes)
• Sprint Planning (around 30 minutes)
• Sprint Retrospective (10 minutes)

We have chance to spend short time on the 3 events because:

• Demos for releasable pieces of increment are ready to be shown during Review
• User Stories are well-defined and easily understandable during Planning
• Retrospective is short because our team is performing really well for more than 2 years now

Hi Roddy,

assuming a two week sprint, we have:

Sprint Planning - around 4h or less

Sprint Review - around 2h or less

Sprint Retrospective - around 1.5h or less

In total around 7.5h or less. Additional we have (also stated in the Scrum Guide):

- A Sprint Review is held at the end of the Sprint...

- The Sprint Retrospective occurs after the Sprint Review...

And the Sprint Planning at the beginning of the Sprint. So you could have two "sessions": Planning(1) and Review+Retrospective(2). Given this, you could do this on two different days: Planning on the first day of your sprint, Review and Retro on the last day. But keep in mind:

- There is no time between two sprints, one sprint immediately follows the next

- Feedback from Sprint Review will probably be used in the following Sprint Planning

Monday-Friday Sprints

I have seen teams using the Weekend gap for this: Starting a Sprint on Mondays, ending a Sprint on Fridays. However, the weekend seems to "erase" some information from some Scrum Team Members, and maybe you will loss some time by recapitulating things you already talked about last Friday. On the other hand, I also had some Team member coming up with new ideas on Mondays, because they had time to sleep a night over it. People tend to also "think" in time boxes of Weeks, so this is quite natural, it frees your head for the weekend as you know you are done at the end of the week.

Mid-Week starting Sprints

Having the sprint ending on Tuesday or Wednesday, and starting on the following day has become a wide spread thing. By doing so, you take into account people often tend to start their weekend early on Friday afternoon, and will be back with their thoughts to work not until lunchtime on Mondays. Having Sprint Planning, Retro and Review on these "special" days could tend to decrease in concentration, efficiency and will probably lead to mistakes. However, some teams already told me, it "feels" odd to start on such uneven days.

So, it depends and you totally should ask your team what would work best for them and support their decision.

Knowing this is only one half of the truth. There are things outside the borders of Scrum you should take into account:

- Having breaks every now and then during your meetings will increase concentration. This can be having a break every hour or having a "red card" anyone who feels sleepy can raise to ask for a break, or....

- Order Team Pizza for lunch could keep the discussion rolling and reduces the interruption

- End the day with a get together will increase the fun, too

- Clarify how you want to manage interruptions like E-Mails or phone calls

- Try to stay as focused as possible to shorten your events. A focused 2 h sprint planning is worth much more than a chewy 4h long one

and several several more... In my opinion, this is more a "How to have an efficient meeting" question, than a "What Would Scrum Say" one, right? ;)

Hope I could help you

To maximise available development time in each Sprint, logic would say...

When you approach the issue this way it becomes difficult to schedule the meetings effectively since the starting position itself is that they are not an effective use of time. Using logic to then solve the problem will fail. 

• Retrospective is short because our team is performing really well for more than 2 years now

This sounds dangerous.. how can you tell if you hardly take time to talk/think about improvements?

"It doesn’t matter how good you are today; if you’re not better next month, you’re no longer agile." - 

Mike Cohn 

Succeeding With Agile

It is very dangerous to minimize the need for retrospectives.

To maximise available development time in each Sprint, logic would say...

When you approach the issue this way it becomes difficult to schedule the meetings effectively since the starting position itself is that they are not an effective use of time. Using logic to then solve the problem will fail

Dimitre, I believe you are drawing a conclusion that isn't there.  

Trying to schedule meetings efficiently to maximize available development time does not imply that such meetings are a waste of time.   The statement implies that, in consideration of available development time, there is a "good" way to schedule them, and a "poor" way to schedule them.

Hi Timothy,

that's a possible interpretation but since neither of us wrote the original post it's difficult to know which one is closer to the author's question. But I agree my conclusion is not strong (if it was in court it wouldn't pass). However, focusing on maximizing development time is a questionable practice too. Especially when juxtaposed to meeting time. It leads into the direction of equating development with coding. And what is development time? Aren't conversations during the ceremony meetings part of the development process? 

Dimitre,

Perhaps it is my "Lean" thinking hat here, but when I look at the issue from a context-switching perspective, there is a clear distinction between a good approach to scheduling meetings (less context-switching) and a poor approach (more context-switching).

To me, it isn't so much about trying to optimize development time, but to find ways to limit context-switching for the team so that the Development Team is provided solid blocks of time to devote to current sprint work.

Does anyone know how Ken Schwaber and Jeff Sutherland came up with the time-boxes in the Scrum Guide?