I frequently get asked if sprints should be required to start on Mondays and end on Fridays. No, absolutely not! Is it common for sprints to align with week boundaries? Sure, but I think that many teams do that for conceptual (calendar) convenience.
Sprints are timeboxed iterations. So one important rule is that after a team decides on its sprint length, unless it has an economically compelling reason, it doesn’t change that length. So, if a team chooses to start its sprints on a Monday and to end them on a Friday, then all of its sprints would start on a Monday and end on a Friday. However, there is nothing in the core of Scrum that dictates when a sprint should start and end. So, does it matter which start and end days a team chooses? Actually, yes it does!
Choosing the Wrong Start and End Dates
If a team chooses its sprint boundaries (i.e., its start and end days) in a way that makes conducting one or more of the core Scrum activities (e.g., sprint planning, sprint review, and sprint retrospective) difficult, then the team chose its boundaries poorly. Trading off the ability to effectively perform Scrum in order to achieve calendar convenience is a bad tradeoff. So, my basic rule for determining sprint boundaries is to determine important constraints on any of the Scrum activities and use those constraints to decide on sprint boundaries.
Which Scrum Activity is the Hardest to Schedule?
Let’s get right to the most important question in determining sprint boundaries – “Which of the Scrum activities is the hardest to schedule?” Is it sprint planning, sprint review, or sprint retrospective? Although time zone differences among members of the same team can influence the answer to this question, there is generally one activity that is harder to schedule than the others. Which is it…?
The sprint review is usually the hardest to schedule because it involves people outside the Scrum team (see blog post “Who Should Attend Scrum Meetings?” for a detailed description of who should be in attendance at each activity). A typical sprint review includes internal stakeholders and external stakeholders who are not members of the Scrum team. The other Scrum activities I mentioned involve only members of the Scrum team, and therefore can be scheduled at the convenience of the team members, typically without stakeholder influence.
Pin Down the Sprint Review and Let the Rest of the Sprint Flow Around It
When determining sprint boundaries, the first thing a Scrum team should do is determine which stakeholders have to be present at the sprint review meeting and then have a conversation with those stakeholders about their availability to attend.
If the team chooses a day and time for the sprint review when the stakeholders tend to be unavailable, then, of course, they won’t show up at most review meetings. If the stakeholders don’t attend, the team loses a valuable feedback loop (i.e., inspecting and adapting the product being built). So, if the team members choose to end their sprints on a Friday, they might learn when they “tell” stakeholders that the review meeting will be 2pm on Friday afternoon that nobody can attend. Alternatively if they tell the stakeholders the sprint review will be Monday at 9am, they might get told: “Don’t ever schedule me in a meeting at 9am on a Monday!”
So, the strategy I am suggesting is that team members ask these stakeholders when they can actually attend the sprint review. If the important stakeholders say Wednesday at 2pm, then the team should pin down that time and let the rest of the sprint flow around it. In this example, that would mean that sprints would start on a Thursday and end on a Wednesday.
Other Influencing Factors
There can be other constraints that influence a proper sprint boundary. Time zone differences among the team members might dictate when certain Scrum activities need to take place, lest some members of the team get blocked.
For example, holding an important meeting (like sprint planning) on a Monday morning in California when half the team is in India means that the Indian team members could be blocked for all of their working day on Monday waiting for sprint planning to take place.
In addition to time zones, the constraints of coordinating multiple teams might influence sprint boundaries. As a rule, most organizations that have multiple teams working collaboratively on the same development effort tend to align the sprint boundaries of the teams. Meaning, that the multiple teams all start and end their sprints on the same days. The desire to synchronize the efforts of these teams could introduce constraints on the specific days sprints should start or end.
For example, I recently worked with a company that was synchronizing the effort of approximately 50 teams. The organization wanted to have a “demo day” where all teams would show their work to executive management. That meant that one day every two weeks the executives needed to be available. So, sprint boundaries were determined to accommodate the day of the week that executives wanted to schedule Demo Day.
Conclusion
Although it is common for sprints to start on a Monday and end on a Friday, there is no requirement that teams do this. In fact, setting sprint boundaries to match up calendar week boundaries might be completely the wrong thing to do! My recommendation is that you review your team’s specific constraints when it comes to scheduling the core Scrum activities of sprint planning, sprint review, and sprint retrospective and use those constraints to determine when sprints should start and end. In my experience, constraints as to when you can schedule the sprint review meeting tends to dominate, so I would start there and let the other Scrum activities flow around it.