Looking for examples of Scrum meeting schedules

Question

I'm interested to see how other people have handled scheduling the various scrum meetings (standup, sprint planning, estimation, retrospective, etc.) but none of the books I've read on Scrum include any template calendars for 2 or 3 week sprints.

There are lots of recommendations like standup should be first thing in the morning, you should plan to spend a full-day on estimation and planning, etc. but never do the books seem to present a template meeting calendar. What I'm looking for is something like this:

We do 3 week sprints that start on Wednesday 1. We do standup everyday at 9:30am 2. We do estimation every Wednesday from 10-11am 3. We do sprint planning the Thursday before the sprint starts from 1pm-4pm 4. We cut a release branch end of day Friday before the sprint ends 5. We launch the release (result of the sprint) on Tuesday (the last sprint day) 5. We do retrospective the Thursday after the sprint ends from 11-noon

Answer 1

Henrik Kniberg describes some schedules in Scrum and XP from the Trenches. See:

• Chapter 4 "How we do sprint planning"
  • Sprint planning meeting agenda
• Chapter 10 How we do sprint retrospectives
  • How we organize retrospectives
• chapter 11 Slack time between sprints.

Just in case, here are some durations I use as bases for a 2 weeks sprint (and corresponding ratios):

• sprint planning meeting: 4h (5%)¹
  • 1rst part (Product backlog item selection): 2h (2.5%)
  • 2nd part (Sprint Backlog creation): 2h (2.5%)
• daily scrums: 15mn max
• demo: 2h (2.5%)
• retrospective: 1.5 h (1,875%)
• plus another ~5% for backlog grooming in the middle of the sprint.

We do the sprint planning meetings on Monday (9:00-13:00), the daily scrum each day at 9:30, the demo and retrospective Friday afternoon (14:30-18:00) two weeks later. And the week-end gives us slack time.

But as always, inspect and adapt.

_{¹ To my experience, beginner teams often tend to need more time for the sprint planning meeting (up to 6 hours) in the beginning but I keep 4 hours as a target on the long run. And it works, people get used to the techniques (such as planning poker), they become more efficient in relative estimations with the experience and they do improve the way they manage the time.}

Answer 2

IMHO, one fits all doesn't exist in Scrum.

I've worked in many different organisations and never had the same schedule. Your organisation is different too, I bet.

I recommend that you start with the scheme proposed by Pascal or keep yours and try differrent things to detect improvements.

For example we had our daily standup at 9h30. We moved it at 10h and we noticed a boost in effectiveness. It was caused by emails, it's too long to explain in a stack overflow answer, but that was related to that company specifically.

I've also found that releasing the friday is usually a bad idea, but in one other company that was the ideal day. Also sprint length differ a lot depending on the type of market, the product and others factors.

Try, test, and find the most appropriate to YOUR company.

Answer 3

We do 2 week sprints. We have tried a few different approaches, but are schedule is as follows...

Thursday 12:00 - 4:00 - Formal Sprint Planning meeting

• Part 1 - product owner explains stories/answers question
• Part 2 - Team decomposition of tasks

Thursday 4:01 - Sprint execution begins

Daily 9:15 PROMPT - Daily Scrum

2 weeks later...

Thursday 9:15 - 10:15 - Sprint Demo (sprint team, product owner, devs from other teams, and anyone else interested is invited to attend)

Thursday 10:30 - 11:00 - Retrospective (sprint team + product owner)

Thursday 11:00 - 11:30 - Informal Sprint Planning meeting (Scrum master and Product owner scrub the backlog one final time to make adjustments from any stories added/changed based on demo/retrospective)

rinse repeat...

We also have a few common sense rules we take into consideration

• No meetings before 9:15.
• Avoid having starts/ends (planning meetings and demo/retrospectives) falling on Mondays and Fridays because we found people tend to take those days off more often.
• Holiday weeks, consider adjusting your capacity to include the extra shortened week to make a 3 week sprint.

Thursdays make for a long day, but its nice to just knock out the demo and planning in one day.

Answer 4

Sprint planning -- 5% of Sprint length, split evenly between Sprint Planning I & II

Daily Standup -- 15 minutes. However, I schedule 30 minutes for these; the first 15 (max) for the Standup, and the last 15 for any quick informal meetings Team members find useful. For 2-week or longer Sprints, Teams often find it helpful to substitute an hour meeting near the mid-point for a mid-Sprint review, in which the first 15 minutes are the Daily Standup, and the rest (as needed) a review in more depth of the Sprint.

Sprint Demo -- generally an hour for a 2-week Sprint, can be longer if needed.

Retrospective: 1 to 1.5 hours. Should always occur after the Demo, so the Demo results can be incorporated.

According to the Scrum Guide, up to 10% of the Team's time may be used in-Sprint for Backlog grooming, or Product Owner collaboration activities.

In my experience, I've found doing the Demo & and Retrospective on one day, and Sprint Planning I & II on a following day (generally the next day, but an occassional 'free-code' day in between the two can be a treat for the team (and a way to accommodate holidays, etc. in the schedule to keep even Sprint length).

As much as possible, I try not to schedule Demos/Retrospectives/Planning on Mondays or Fridays. I try very hard not to have a Sprint ending span a holiday weekend, and have built a spreadsheet to help coordinate Sprint scheduling.

Answer 5

We do 3 week sprints.

Before each sprint we have a 1 hour sprint planning meeting where we dish out the tasks and everything.

Each day during the sprint we meet for 15 minutes (usually ends up being closer to like 25 though).

It's usually about 50% development, 20% analysis, and 30% testing.

Answer 6

I understand what you're asking, because I've asked it too. And the answer I found was that I didn't need Scrum to be that prescriptive. There are rules of thumb that we follow, but in reality my project and team are going to be different than anyone else's.

That being said, here's what we do for 2 week sprints:

• Sprint Planning meeting: 4 hours in 2x 2 hour parts
• Sprint starts at beginning of planning meeting
• Estimating new backlog items as needed up to 10% of sprint
• Scrums are done first thing in the morning (we do 8:30)
• Scrum is followed by short modeling/design meeting
• We have a dev branch that is merged to the main branch as user stories are done.
• We may have a number of sprints in a release depending on release plan.
• The product owner can choose to release any time he wants since the main branch is synchronized with only "done" work. Although, depending on the maturity of the product, we might choose to have a release sprint before beginning work on the next release.
• In our "release Sprint" (if we have one) we make sure that any undone work is complete and bug debt paid. Depending, we may also decide to do a full QA regression.
• We conclude with a 2 hour review the last day of the sprint, followed by a 90 min retrospective using suggestions found in Agile Retrospectives by Esther Derby and Diana Larsen.

Hope this helps