The Sprint is the heartbeat of Scrum. It is a timeboxed event where the Scrum team plans, executes, collects feedback, and delivers. Scrum is made up of five events.
The Five Scrum Events:
The Sprint: A time period for the Scrum team to plan, execute, and deliver the product increment.
Sprint Planning: A meeting that kicks off the Sprint where the Scrum team selects what to deliver and plans how to deliver it.
The Daily Scrum: A daily meeting lasting no more than 15 minutes where the Scrum team plans the next 24 hours of work.
The Sprint Review: A meeting where the Scrum team and stakeholders go over the product increment and collect feedback.
The Sprint Retrospective: A closed door meeting where the Scrum team reflects on how they worked during the Sprint and identify items to improve during the next Sprint.
It could be challenging to hold these events in a remote Scrum environment. The facilitation, communication, and coordination to make them work present a new challenge to Scrum team members trying to work remotely. The good news is that holding an online Scrum Sprint could be just as effective as face to face events. Below are a few tips that can help with your next remote Sprint execution:
1- Consider holding short Sprints. A properly planned Sprint is key to meeting your Sprint Goal. The Scrum Guide recommends that a Sprint Planning event be no more than eight hours for a four-week Sprint. This time allocation should be proportional to the length of your Sprint. Therefore, the shorter the Sprint, the shorter the amount of time you will spend as a team in Sprint planning. Holding a two-week Sprint allows you to have no more than 4-hours allocated for your next Sprint planning. This could be an advantage when everyone is dialing into a remote meeting since the focus time could be limited. So, try holding two-week Sprints and schedule shorter Sprint planning sessions.
2- Create smaller Scrum teams. The optimal development team size consists of five members. This is because the communication channels increase significantly as teams get larger. A team of 10 has 45 possible unique channels of communication. This becomes a problem, especially in distributed teams, when we must be deliberate about how we communicate. Therefore, keeping your teams small will allow them to self-organize better and be more effective at communicating remotely. Keep the size of the development team to no more than five team members and be sure to have a dedicated Scrum Master and a dedicated Product Owner, for a maximum of seven members.
3- Schedule a weekly Product Backlog refinement session. In Scrum, Product Backlog refinement is considered to be an activity that happens on an ongoing basis. This activity is the responsibility of the Product Owner. The PO usually enlists the help of the development team to reach a “ready” state for the product backlog items. The development team, however, should not spend more than 10% of their time refining items, so it’s important for the PO to maximize their time to refine. Schedule the session to happen during a fixed time once a week and timebox the time spent on each item. This will allow the PO to refine the product backlog items on a regular basis.
4- Spend 2-4 hours on Sprint planning. I have observed that teams tend to spend too much time in Sprint planning working on refining product backlog items that could have been addressed earlier. By keeping a “ready” product backlog, the team will be able to focus on the “what” and the “how” of the Sprint instead of trying to define the work from scratch. This optimizes the precious time that the team has together in remote sessions.
5- Break user stories into tasks so that they can be tested earlier. This allows the QA folks to jump right into action instead of waiting for larger stories to be completed before they can test them. If your backlog items are too large, it will take a while before QA can spring into action. Make them small and break them down further by creating four to eight-hour tasks.
6- Create short acceptance request videos. I also suggest that QA records a quick video of the feature they test. This allows the product owner to understand the work that was done and accept the items. It reduces the need for another meeting.
7- Hold a daily 15-minute Triage. Teams that squash bugs during the Sprint are more successful than teams that rollover bugs from Sprint to Sprint. Doing this with a distributed team can be challenging unless you schedule a time to do so. The best time to do this is right after the Daily Scrum. It’s important to be deliberate about how the team processes bugs found during the Sprint. Once you close out your stand-up, start a new 15-minute segment to call out the new bugs and determine their severity. The Product Owner can confirm the priority of each bug and the team can agree to swarm on critical ones. This will allow the team to get right to solving them before they become an impediment in accomplishing the Sprint goal.
8- Have a team working agreement. Working from home creates a new set of considerations for the team to work effectively. The Scrum team should co-create a new set of working agreements that address the environment. These are a few of the points for getting everyone on the same page in order to have effective collaboration. Some things to consider:
What tools will be used for ad-hoc communication?
Is everyone expected to share video?
Should everyone provide a written answer to the stand-up questions ahead of the session?
Will meetings be recorded?
9- Keep an open online meeting. Meeting platforms like Zoom allow you to create a perpetual or recurring meeting. This meeting can act as the conference room for the team. Whenever there’s a need to meet or for you to find someone, you can just dial into the meeting and ask others to join the room. This takes the pressure off scheduling a session and sending a meeting invite. It can also act as a social place for team members to join and turn on their camera.
Some of these remote Scrum tips might work better than others, depending on your needs and environment. So as with anything we do in Agile, be sure to inspect and adapt. You may also be practicing additional techniques that could help other Scrum teams be successful in a distributed environment, so feel free to share your findings.
Comments