When is a good day in the week to start a sprint?
Answer: Any day but Monday. Sounds crazy? Not as much as you may think.
~ 2 minutes read
no time? jump to the conclusion
Work weeks in most work environments start on a Monday (as always exceptions apply). Also the ISO_8601 standard defines weekday number one for Monday.
Scrum is one of the popular and widespread agile methodologies. A sprint is a defined time frame in which a product increment is produced. Apart from one, all environments I work in so far started the sprint on Monday’s.
When I had the chance to set up an agile process from scratch I focused on reducing the disadvantages of Monday started sprints.
When a sprint starts on a Monday, it ends effectively on a Friday. That means you’ll have to complete the sprint goals on Fridays. Does this work all the time?
In scrum theory – yes. In reality: not so much.
The result I observed was: some of the team members were stressed on Fridays to complete the sprint. Regular stress on Fridays just demotivated people. Demotivated team members even were even less incentivised to complete the sprint and thus worked even less than on other working days.
After a sprint has been completed, people enjoy the weekend and start the next week with sprint planning activities. Some forgot most of the context from the past sprints because the sprints were “done”. I observed to little understanding that sprints are just a tool to separate a list of work items into small time frames with a focus on a product increment that shall provide user value.
Don’t deploy on Fridays
… unless you have a lot of automation and monitoring plus rollback capabilities in place. We did focus so much on features that we could not rely on enough automation. As a result Friday deployments increased the stress level even more.
Sprint Start Mid-Week
We started iterations mid-week Wednesday when I was able to design an agile workflow from zero earlier this year.
Please note: we started iterations (and not sprints) because I wanted to be able to pick any working item from methodologies – agile or none agile. Also I did not want to bind the team way of working to a specific (agile) methodology.
The biggest improvement was Fridays. Team members could finish their Friday work day according to their flow. Very rarely we had to sync on Fridays to release in order to prepare a review, test or presentation. The Friday stress level was more or less gone because everyone could start their weekend when their planned Friday tasks are done without the need to sync to finish the iteration.
Iterations ended on Tuesdays and new iterations started on Wednesdays. We got flexibility to move end and start dates around within the same work week. The context of the previous sprint was present in people’s minds after an iteration had been finished on Tuesdays and the subsequent iteration started on Wednesdays.
What about the stress of finishing the sprint?
We often set ourselves ambitious iteration targets. That resulted in increased stress levels in some cases because we realized we could not achieve the targets all the time. However, I rarely observed such a quick product delivery pace than in this team setup.
The stress mitigation that helped most was: Tuesday before lunch was release time. Everything we were comfortable to release was released to staging latest on Tuesday (engineers were also free to release earlier). After lunch we tested the new release and found issues and sometimes bugs. Only the bugs that could be fixed within Tuesday afternoon were fixed. Everything else was input for the subsequent iteration.
Start your sprint mid-week (Tuesdays, Wednesdays, Thursdays). Your team members enjoy the weekend much better due to the decoupled start of the weekend and sprint finish.
On top you gain better connections between the iterations because iteration end and start of the next iteration is just one workday away or on the same workday.