Should Scrum meetings be held in one day or two days?

Question

I was asked an interesting question to which I do not have a strict answer. I would only have suggestions, thus I'd like to ask you the same question:

How do you believe regular scrum meetings should be handled when it comes to time? Say you have 2-week long sprints, then in theory: Planning - 4 hours max Review - 2 hours max Retro - 1,5 hours max

Now the sequence for me is clear -> Sprint Planning -> Sprint Review -> Sprint Retrospective.

Question is -> should this all happen in one day (of course given the fact that it may be shorter - planning 1 hour, review 1 hour, retro 1,5 hour)?

The benefits from such distribution in my opinion are that by having all these meetings in one day we have rest of the time in sprint for working on user stories, project discussions, backlog refining activities etc - regular work.

However - spending whole day on meetings may cause them to be ineffective and the team to be less active and Scrum ideas may be lost.

Splitting them into two days again makes two days a bit less productive when it comes to regular work, however team should be able to benefit more from higher activity during meetings.

My idea is there is no strict answer and one should keep in mind context of the team, PO, project etc and adapt it to fit best what the team needs.

What are your opinions?

Answer 1

The simplest answer is to ask the team. Go with what they feel most comfortable with. If it doesn't work out, adapt and shift the meetings around.

I have worked with some teams that prefer to have all the meetings in one day. They see that as a 'hands-off' day and like to get it out of the way rather than having meetings spread out.

Other teams don't like to spend all day in meetings and find that planning is less effective at the end of a busy day of meetings.

Answer 2

Question is -> should this all happen in one day (of course given the fact that it may be shorter - planning 1 hour, review 1 hour, retro 1,5 hour)?

The typical cadence of a the Scrum ceremony is to host Sprint Planning and then at the mid-point of the timebox run a Backlog Refinement ceremony. The Sprint Review occurs at the end of the timebox as that is when the work the team committed to delivering is due. Finally a Sprint retrospective takes place to discuss improvements in the working environment and practices prior to the next Sprint.

Traditionally for a two-week Sprint it would be

1. Sprint Planning | 4 hours | First day of the Sprint
2. Backlog Refinement | 2 Hours | Mid-Sprint
3. Sprint Review | 2 hours | Last Day of the Sprint
4. Sprint Retrospective | 1 hour | Last Day of the Sprint

I know some teams have experimented with Mon-Fri type Sprints, Wed-Wed Sprints but I have not come across a working practice which puts Sprint Review, Retrospective and then straight into Planning on the same day.

Personally, I feel that any benefits that arise from cramming all ceremonies into a single day would be eradicated by the severe drop in morale and concentration which would come from such a technique.

My firm answer is that Scrum ceremonies should occur across two days at the least but ideally a third day would incorporate backlog refinement.

My process as Scrum Master

I think that Sprint Planning is a fairly relaxed introduction to the new week and we plan on Mondays. I always ensure that I arrive with snacks and drinks for the team (cheese, doughnuts, gourmet coffee etc).

We start Sprint Planning approximately 1 hour after the working day begins which gives the team time to review emails after the weekend and collate all of their commitments and holidays and constraints before arriving at the planning session.

We actually run a three hour Sprint Planning session but that is an adaptation we found because of our workflow.

Normally it finishes around 12.15 at which point we break for lunch. In that break I place each of the committed cards back on the Board and the team return from lunch ready to start work by picking up their first cards around 1pm.

Our Sprint Planning Agenda is as follows (feel free to steal)

• 2 mins [SM] Open
• 5 mins [PO] Planning Vision and Roadmap
• 10 mins [Gov Mgr] Development and Architecture Status
• 5 mins [BP] Sprint Goal and Theme
• 5 mins [SM] Velocity Review
• 5 mins [SM] Sprint Timebox considerations
• 15 mins [All] Team Capacity
• 10 mins [All] Issues / Concerns
• 10 mins [PO] Review Definition of Done
• 2 hours [PO & Team] Product Backlog Items for consideration
• 15 mins [Dev Team] User Story Owners
• 15 mins [Dev Team] Assumptions / Dependencies for User Stories
• 5 mins [All] Agreement
• 15 mins [SM] Parked Items
• 5 mins [SM] Action Items
• 2 mins [SM] Closure

For Sprint retrosepctives we use a round robin of ideas from Retromat - a retrospective generator.

Answer 3

As you said, there isn't necessarily a "right" answer. However, in teams I worked with, I split it into two days, but it's the afternoon of the first day and the morning of the second. The most success I've had so far has been

Day 1:

Retrospective

Sprint Review

--End of Day--

Day 2:

--Start of Day--

Sprint Planning

Personally, I like having the retrospective before sprint planning because I often find that the team decides to do things in the next sprint that need to be accounted for in planning. The order of day 1 can go either way. Retro before Review risks missing things from the review in the retro, which the other way risks the review items overriding important lessons from throughout the sprint. So, I'll swap those around depending on the team. Having the planning first thing on day 2 means people come in fresh and the other meetings are still clearly in memory, but aren't taxing their ability to focus on planning.

Answer 4

I'll agree that there isn't a right answer and it really is up to the team.

That said how you run the meetings makes a major impact on things. This goes to basic meeting facilitation and isn't agile specific.

• Publish an agenda ahead of time: On average, half your team hates to be surprised. They want to go into a meeting well prepared. This includes providing an update on the current backlog in the email or calendar invite, even if its easy to pull from your tool of choice.

• Post the agenda during the meeting. An agenda shown on the first slide of a .ppt deck ( a bigger crime in waterfall) is useless as soon as you change slides. Post the agenda clearly for everyone to see.

• Make sure there is a clock in the room, big and easy to read. Yes, everyone has a cell phone. That requires more effort and draws more focus (from everyone) than a quick glance at a wall clock. Also means everyone is on exactly the same time.

• Do a time based agenda. Venture's agenda is excellent. However put it in clock times, so "Meeting Open: 10:00, Planning and Vision: 10:05, Dev an Arch status: 10:10." By putting the time the agenda item starts it makes it much easier to track to your agenda. If it's 10:15 and you still haven't started Dev and Arch Status, you know you need to shave 5 minutes of Dev and Arch or agree with the team to shave it elsewhere.

• Plan and schedule breaks: Science and years of experience have shown us the human mind can't stay focused for more than about 90 minutes in a stretch. After this, even the most engaging topic will start to lose focus. Plan your breaks into the agenda and then enforce them. Engineers are notorious for the "let's keep going, we're almost done" syndrome. They may get done faster, the right issues might not have come up because brains were too foggy.

• Limit the technology: A good running agile team knows this already. If everyone has their laptop open and active, it will pull energy away. Most successful teams I know will do all their planning with old fashioned wall and post its and then transfer it to their electronic tool of choice. I'd even support a phone bowl, where everyone puts their phone during planning. They can have them at breaks.

Again, not agile, just good meeting facilitation that can make an agile ceremony even more effective.

Answer 5

Our team prefers having all meetings in one day. Our schedule is as follows, on every other Tuesday:

• 10-11am: Sprint Review
• 11-12pm: Sprint Retrospective
• 1-5pm: Sprint Planning

Grooming occurs on mid-sprint Tuesdays. This schedule was suggested in my Scrum Master training class, and it's working out great for us.

Answer 6

In my opinion, these should generally be across two days.

It does depend however on the size, preferences etc of the team but also the length of the sprints. The team should all collectively decide on this in line with Scrums values. @CodeGnome asked where @Arek got his timings from. These are based on halving the scrum guides maximum time boxes for a 1-month sprint.

The reasons I believe it should generally be two days are due to both focus and context.

Firstly, having a day full of meetings is generally not a good idea as people will loose focus easily and miss something. This can be slightly alleviated by having regular breaks, say every hour if it is a requirement.

In terms of context, we are looking at items from one sprint and then items for another sprint so it is good to give them a break in-between.

There is also a general business overhead that should be considered, and someone else mentioned, regarding checking emails and other business activities. These should be given time to be done bearing in mind that no-one should be fully allocated for a sprint to account for these anyway.

If you get the situation where there are a few hours left at the end of the day then these extra activities can be completed along with potentially some training so it's never wasted time.

Going back to my earlier comment, though, take this information to the team and let them collectively decide it. It's not set in stone and can change over time in line with Kaizen as well.