Having difficulty making remote Scrum teams collaborate effectively? Try shorter Sprints.
Sprints are the heartbeat of Scrum. They set the pace for sustainable and continuous delivery. In each Sprint, we plan, create, and collect feedback, allowing us to plan and pivot more frequently. They also allow us to reflect on how we can improve our collaboration the next time around. In summary, Sprints make the teams more efficient and effective at delivering value.
Although the Scrum Guide allows Sprints up to four weeks long, most of the industry today is practicing 1-2 week Sprints. In a recent survey of Distributed Agile teams, 88% of participants were practicing 1-2 week iterations, with only 7% of the teams practicing 2–3-week iterations. The data also suggests there is a strong correlation between shorter iterations and effective remote collaboration. Out of the 47 teams that practiced 1-2 week iterations, 89% self-assessed to be effective collaborators.
The key to successful distributed collaboration is continuous valuable communication. In a distributed environment, when teams plan individual work too far ahead, collaboration is often left out of their schedule, which can interrupt the team workflow and decrease efficacy. This is because members that commit to a larger chunk of work may isolate themselves to complete it, potentially missing chances to inspect and adapt based on the people, process, and product.
When teams schedule short work iterations, it creates more opportunities for communication and collaboration, preventing reworks, or wasted time from silo operations. Below is a recipe for a one-week Sprint you might want to try.
Sprint Planning (2 hours) - One of the big advantages of shorter Sprints is the ability to limit the Work in Progress (WIP) and increase productivity. By holding a weekly Sprint Planning and only committing to one week at a time, we can increase the predictability rate of delivery. It also allows the Product Owner to connect with the team more frequently to articulate the objectives and address any misalignment that may occur in a remote setting.
Daily Scrum (15 mins) - The Daily Scrum should not change, regardless of the length of the Sprint. This is the opportunity for the developers to plan the work for the next 24 hrs. The Daily Scrum becomes that much more critical in a remote setting as it can also help team members feel connected by interacting with each other daily.
Sprint Review (1 hour) – Building trust with stakeholders can be tough for remote workers. Trust increases when the Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed regularly. This also allows the Scrum Teams to pivot quicker and reduces waste.
Sprint Retrospective (45 minutes) - Shorter Sprints will give teams the freedom to reflect periodically due to more frequent Sprint retrospectives. This offers the perfect opportunity to discuss and improve how the team works during the remote Sprints. It gives the team more frequent opportunities to inspect people, relationships, tools, and the process.
+ Social Time – (30 minutes). This is not a core Scrum event, but just because everyone is remote, it doesn’t mean we can’t have fun together. The retrospective marks the end of the Sprint and it is a perfect segue into a social gathering to kick back and have watercooler conversations.
Shaving some time off your Sprint length might prove to be a remote worker’s best friend but be careful not to change the length of your Sprints sporadically. In other words, pick a Sprint length and stick with it. Also, be sure to revisit your Definition of Done (DoD) to ensure that the committed work is truly “Done” at the end of the Sprint. Oh, and don’t forget to retrospect on how the change is working.
