Table of Contents
What Events Should We Put in Place For Iterations (Sprints)?
One the key tools that we use when we work an Lean Agile (Scrum) implementation is the notion of a “cadence”. See What is the Benefit of Having a Cadence of Meetings Etc? for more on why this is important.
The following notes gives you some ideas of what your calendar looks like for a Team would look doing a “normal” Iteration (or Sprint); what meetings you should consider.
Assumptions
Note that there are a couple of assumptions here:
- Make sure that you understand the purpose of the meeting so that the meeting ends up having value. There is nothing worse than setting up a series of meetings and people just go through the motions.
- Some of these, like the Iteration Planning (Sprint Planning), the Daily Stand-up (Daily Scrum), the Iteration Demo (Sprint Review) and Iteration Retrospective (Sprint Retrospective) are pretty much “standard Scrum”. Others a “good ideas”. Even if you are not doing Scrum, you will often find the meetings still make sense. Use what makes sense in your situation.
- If you are starting out with a new implementation, you might want to look at setting up all these meetings and then paring back (or trying new meetings) as you learn. For these situations it is usually better to learn by doing instead of deciding upfront “we aren't going to need / do that”.
- The setup specifies “max” time for the meeting. This is your time box. You don't have to use all the time. Its OK to reduce the time if you have completed the result.
- The setup shows a standard two week Iteration (Sprint). Your Iteration (Sprint) might be longer / shorter. Adjust your time boxes and calendar accordingly:-)
Events
When you set up an Agile Team you will see the following events for a 2 week Iteration (Sprint):
| Meeting | Cadence | Length | Purpose | Comments |
|---|---|---|---|---|
| Iteration Planning (or Sprint Planning) | First day of the Iteration | Max 2 hours | Team makes a reasonable commitment to complete a set of work by the end of the Iteration | For the next Iteration (Sprint), this can be scheduled either on the same day or the day after the Demo and Retro depending the timing of the demo. See How Do We Run Our First Iteration Planning (Sprint Planning)? for more information. |
| Daily Standup (or Daily Scrum) | Every day of the Iteration | Max 15 mins | Team synchronizes their efforts in order to meet Iteration Goals | See What is the Purpose of a Daily Stand-up (Daily Scrums)? for more information. |
| Mid-Iteration Review | Middle day of the Iteration | Max 1 hour | Team determines whether they are on course or whether they need to adjust | Most teams do not need this. It is used in environments where there is a lot of change. If teams do this a lot, they might want to consider 1 week iterations (or sprints). If used, it is combined with Backlog Refinement |
| Backlog Refinement | Middle day of the Iteration | Max 2 hours | Team looks ahead to next Iteration to see if they are ready for Iteration Planning | Team works to get their stories to Definition of Ready (DoR)? |
| Iteration Demo (or Sprint Review) | Last day of Iteration | Max 1 hour | Team provides “objective milestone” of progress and gets feedback from stakeholders | Create specific meeting that includes your stakeholders. See How Do We Run Our First Iteration Demonstation (Sprint Review)? for more information. |
| Iteration Retrospective (or Sprint Retrospective) | Last day of Iteration | Max 1.5 hours | Team reflects on how to become more effective and adjusts its behavior accordingly | This event typically runs after the Demonstration so you can incorporate stakeholder feedback in your Retrospective. See How Do We Run Our First Iteration Retrospective (Sprint Retrospective) for more information. |
Calendar of Events
The following calendar shows the basic setup for a Iteration (Sprint) of 2 weeks.
Note that we try to set up Iteration (Sprint) so they start / end in the middle of the week …
Why Do We Start and End Iterations (Sprints) Mid-week?
Or “Why Don’t We Just End the Iteration of Friday, and start again on Monday?”
For many, it would be logical start and end an Iteration (Sprint) around week boundaries. In general this should be discouraged as:
- Holidays and vacations: Most long weekends and other holidays happen on a Monday or a Friday. If we were to have events like Iteration Planning, and the Retrospective scheduled for a Monday, then we would end up rescheduling a lot of these. We might even feel we should shorten or lengthen the timebox, the iteration, which is poor practice.
- This situation is made worse when you incorporate significant timezone differences within a Team. For example, planning for an Iteration to finish on a Friday (US time) means that someone is staying up late in Australia or India, and that on a Friday night. While this might be possible in the short term, it is not sustainable in the long term.
- To avoid the “billiard ball” pattern: If you set up Iterations so they start and end around the weekend, it reduces the smooth movement from one Iteration to the next. The Monday becomes “oh we have to get started again” and in the end reduces the smooth flow of value. The metaphor comes from a picture in your head: the weekend becomes like a one billiard ball smacking into another.
- To avoid burnout: If you start and end around the weekend, people (i.e. intelligent, motivated knowledge workers) will start to treat the weekend like a buffer. Increasingly people will say to themselves “I'll just finish this on the weekend” which will result in a pace of development that is not sustainable. This happens less with a midweek start.
It should be noted that some of this discussion is moot if you are on a Team which is part of a larger team-of-teams (Train) structure. In these cases you will need to align your cadence with that of the larger structure to ensure you can synchronize your activities with other members of the Train. That being said, the same thinking applies to Trains as Teams - we should avoid stating and stopping train event on weekend boundaries.