Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Schedule of Sprint Review, Retrospective and Planning

Last post 01:55 pm September 20, 2017 by Alex Crosby
10 replies
11:33 am March 7, 2017

Hi - I am interested to hear about others experience in scheduling these 3 events on a Scrum project with shorter (say 2 week) Sprints. To maximise available development time in each Sprint, logic would say that they should follow each other directly so we can start the next Sprint as soon after finishing the previous one. However, given that they might each be several hours long it seems unrealistic to get the Scrum Team together and focused for such a marathon of meetings in a single day for example.

Opinions, thoughts ?

Thanks, Roddy

 

 


02:54 pm March 7, 2017

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.


03:00 pm March 7, 2017

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

 


03:14 pm March 7, 2017

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


03:11 pm September 15, 2017

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. 


09:49 pm September 15, 2017
  • 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?


08:48 pm September 18, 2017

"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.


08:54 pm September 18, 2017

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.


02:05 pm September 19, 2017

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? 

 


01:14 pm September 20, 2017

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.

 


01:55 pm September 20, 2017

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


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.