A typical 2 week Sprint calendar
Helping you plan the events with your scrum team
When you’re getting started with Scrum, one of the first things you are going to want to do (other than understand the 4 values of the Agile Manifesto, the 12 principles behind it and the 5 Scrum core values 😉) is to set up your Scrum events in your team calendar.
So today, let’s explore when you could run them in a typical 2 week Sprint, and the reasons behind that.
Recap of Scrum events
Before we get into when to put the events into a Sprint, here’s a recap of the 4 Scrum events that the Sprint encompasses:
- Daily Scrum every day (15 mins max)
- Sprint Review once per sprint (2 hours max)
- Sprint Retrospective once per sprint (2 hours max)
- Sprint Planning once per sprint (4 hours max)
And optionally…
- Product Backlog Refinement as a group (as required)
I find it useful to get some time together as a team to perform group Product Backlog Refinement — but in practice, this is an activity that also happens throughout the Sprint.
How I run a 2 week sprint
On a normal day, we are in the office between 9am and 5:30pm. Obviously during the COVID-19 pandemic, this has changed somewhat! But in general, we stick to the same times working remotely.
Some people get “in” earlier than this, and some people stay later than this. However, all the teams are around between our core hours of 10am to 4pm; this ensures we can plan our meetings effectively.
The following diagram is an overview on how we schedule our Sprint events, sometimes we stray a little bit from this if we need to, but we always do it for the right reasons. We are not constantly changing or extending them on a regular basis — we are building a rhythm.
This is the exact setup I use for one of my Scrum teams.
Summary of events in a two week sprint cycle
The top half of the diagram shows the first week of the sprint, and the bottom half shows the second week of the sprint.
As you can see, my teams’ two week sprints start on a Monday afternoon, and finish on a Monday morning two weeks later (so they span 3 separate calendar weeks in reality).
This is deliberate and we’ll get to why in a bit.
Before that though, here’s a bit more detail about each event on the calendar above:
- We hold a Daily Scrum at the same time, same place, every single day except the day we have Sprint Review, Sprint Retrospective and Sprint Planning — there are enough meetings on that day already, and more importantly, we don’t intend to do any other sprint work on that day anyway. This event is therefore not needed.
- We hold Sprint Planning immediately after Sprint Retrospective (with a small break so that we can have a rest) on Monday afternoon. We have the highest energy levels on a Monday, so we do most of the mentally taxing things on that day. Our Sprint Planning sessions sometimes spill over into Tuesday AM. This is quite rare, but when it happens it also gives us time to “sleep on it” if we have to. In this scenario, the 1st Daily Scrum of the Sprint is cancelled on the Tuesday, as we are planning together anyway — we don’t see any additional benefit of also having a Daily Scrum.
- Product Backlog Refinement 1 (as a group) is held every Thursday. The first of these sessions in a sprint allows us to ask any questions. If they can be answered there and then, it’s great. If not, we’ve got the rest of the sprint to figure it out. We also spend time in smaller groups refining items throughout the sprint. The product backlog refinement meetings are where we estimate as a group.
- Product Backlog Refinement 2 (as a group) happens in the second week of a sprint. We answer any questions raised in the first refinement meeting, and we make sure we are as ready as we can be for Sprint Planning only a few days away now.
- Sprint Review happens first thing on a Monday morning. We spend up to 2 hours (as a team) preparing for this on the Friday before. Effectively our sprint ends last thing on Friday, and we can all go home having worked really hard and hopefully having achieved the Sprint Goal. Sometimes it’s a bit more ad-hoc than that; the planning for demos should be a natural end to a sprint, rather than a big event. We try and make Sprint Review as fun and laid back as possible so that people aren’t afraid to give feedback. We start our working week with Sprint Review.
- After Sprint Review (and usually lunch), we head to Sprint Retrospective and discuss as a team how we can improve at least one thing in the next sprint. That “thing” goes directly on the sprint backlog for the very next sprint.
Top tips for planning your Scrum events
1. Stick to your time boxes
No-one likes their events running over time, and this includes the Scrum events. So be respectful of other people’s time and stick to your time boxes. The last 10 minutes of every event should be wrapping up. The reason we have a time box is to make our meetings efficient. If you start off with Scrum and find you are running out of time in all of your events, consider just ending bang on time to help teach everyone that time is important. Talk about your time boxes in your next team Sprint Retrospective.
2. Leave some space between events
None of my events exceed 1.5 hours of continuous work in a row; this is deliberate. People need a break to perform their best, so build it in. I always allow space for people to have a break between meetings.
3. Regular times
Having the same events, at the same time every week helps get people into a state of flow. People know when they’ll be interrupted, so they’ll build a routine around it. It’s also much easier booking things like meeting rooms if you need them the same time every single week.
4. Other meetings are OK, just be careful
The core Scrum events are there to ensure we have a regular time and place to inspect and adapt. That doesn’t mean you can’t have other meetings, but you should be conscious that you might be excluding people; and that might reduce transparency. Not everyone will have a common understanding if they are not invited.
So for every other meeting you have, you should also ask yourself this question:
Could this extra meeting be better covered off in one of the existing Scrum events?
5. The order of the Scrum events important
- You must start with Sprint Planning so that you know what goal you are setting out to achieve in the Sprint.
- Your Daily Scrum is likely to be next — you can discuss any progress towards your Sprint Goal
- As your Sprint comes to a close, you’ll be preparing and performing the Sprint Review with your stakeholders to gather that all important feedback
- Finally we end the Sprint with Sprint Retrospective — inspecting and adapting the team for optimum performance
And remember…
- Backlog Refinement is happening throughout the Sprint — it’s not just a meeting.
📝 Take Notes
As a Scrum Master, I often find it useful to take notes about any observations I’ve made during each scrum event. I then take these notes to Sprint Retrospective to inspect with the team and see what adaptations we can make to improve our effectiveness and quality in the future.
Each event has it’s own purpose, time box, attendees and anti-patterns. As an experienced Scrum Master I know what to look out for, but if you are just starting out, or just like your notes to be ordered, I’ve created a journal you can buy online here:
Summary
I hope this information helps you plan your sprint events with your team.
Sometimes the days/times have changed, or events have moved around a bit; but we’ve settled on this and everyone seems pretty happy with it. That doesn’t mean we won’t change it in the future. The world is changing all the time and we might find better ways of exploring the Scrum events. If I do, I’m sure to let you know right here!
If you’re new to Scrum and want to learn lots more, head over to thescrummaster.co.uk and you’ll find all sorts of courses and practice tests to further your knowledge!
And if you buy it, I hope you find the Sprint Journal useful.
