It’s fairly standard for Scrum ceremonies to be arranged according to the work week. Sprint Planning and Kickoff on Mondays, grooming sessions in the middle of the week, Sprint Demo and Retrospective on Friday. But is this the best sprint alignment for your team?
When planning team sprint ceremonies, take a lesson from vacationing on the beach. What do we do at the beach? There are two types of vacationers: outing goers and beach-sitters. I’ll speak to the latter, since that’s what I know best. Beach-sitters, as we are in my family, go to the beach to sit, swim, and snack. A typical daily schedule looks like the following:
- Wake late
- Don a swimsuit
- Sit on the beach, swim, and snack until late afternoon
- Come in, shower
- Get dressed in clean clothes for the evening
- Eat a leisurely dinner
- Go to bed
Notice that beach days are inverted compared to a typical personal routine of showering and dressing in the morning. If the beach goer puts on fresh clothes every morning and fresh clothes after showering before dinner in the evening, they will go through at least two outfits daily. Not very efficient! Fresh clothes donned each evening, and the evening’s slightly-worn clothes donned the next morning make for a much more practical routine. When in Rome…
So how does this relate to sprint teams? There are many reasons why one might want to start and stop sprints on days other than Monday and Friday. These reasons can be roughly bucketed into the following categories:
- fixed concerns: e.g. weekends and holidays
- variable, but semi-predictable concerns: e.g. PTO, WFH, all-hands
- stakeholder concerns: e.g. standing executive meetings and availability
- collaborative concerns: e.g. adjacent team sprints
- continuity concerns: e.g. at-work time to think and plan
Having identified these categories, how do they apply? Fixed, variable-but-predictable and continuity concerns are generally good reasons to not schedule major sprint ceremonies for Monday and Friday, while stakeholder concerns will vary according to the company and executive context. Collaborative concerns can be more complicated to address. For example, say you have two teams: design and engineering, working on the same product or feature. Design has to be a step ahead of engineering, so when engineers kick off implementing a feature, there already exist designs ready to be translated into code. It’s also common for collaborators to be present at their sibling team kick-offs or demos, so it’s good to stagger their sprints to avoid standing conflicts.
Continuity concerns are also more complex. Look for a follow-up article regarding Sprint Gaps, which will talk about how to give your team time to recover from one sprint and be ready to thoughtfully start the next. Ending one sprint on a Friday and starting the next on a Monday can be a great way to lose continuity, flying by the seat of your pants from sprint to sprint.
That is a lot to weigh, and good stewardship of a project team is no trip to the beach. There are pros and cons to any sprint alignment. However, decision-making grounded in the values of per-sprint predictability, sprint-to-sprint continuity, and cross-team/stakeholder collaboration should result in a workable, or better yet an optimal, solution. But if you need a tangible reminder of how to flex your schedule to fit the context, I recommend booking a flight to your favorite tropical destination.