TL; DR: A Remote Sprint Planning with a Distributed Team
We started this series on remote agile with looking into practices and tools, followed by exploring virtual Liberating Structures, and how to master Zoom. We had a look at common remote agile anti-patterns, and we analyzed remote Retrospectives based on Liberating Structures. This sixth article now dives into organizing a remote Sprint Planning with a distributed team: practices, virtual Liberating Structures, and lessons learned.
Do you want to get this article in your inbox? You can sign up here and join 26k other subscribers.
The Purpose of the Sprint Planning
The purpose of the Sprint Planning is to align the Development Team and the Product Owner on what to build next, delivering the highest possible value to customers. The Product Owner introduces the business objective the upcoming Sprint is supposed to meet, the Scrum Team collaboratively creates a Sprint Goal, and the Development Team forecasts the work required to achieve the goal by picking the appropriate items from the Product Backlog, transferring them to the Sprint Backlog. Also, the Development Team needs to come up with a plan on how to accomplish its forecast as well as pick at least one high priority improvement issue from the previous Sprint Retrospective.
According to the Scrum Guide, the Sprint Planning answers two questions:
1. What can be delivered in the Increment resulting from the upcoming Sprint?
2. How will the work needed to deliver the Increment be achieved?
Given the relative distance between the members of a distributed Scrum Team, the task of aligning everyone becomes even more crucial for a remote Sprint Planning as is the determination of the Sprint Goal:
During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.
By comparison to a co-located Scrum Team, the preparatory work, for example, regular Product Backlog refinements, keeping track of technical debt, and preserving a high-quality Definition of ‘Done’ is paramount to securing a successful outcome of the Sprint.
Source: Scrum Guide, 2017.
Virtual Liberating Structures for a Remote Sprint Planning
To ensure that the physical barrier is not impeding a remote Sprint Planning, and similar to the remote Retrospective, we once again turn to virtual Liberating Structures to include and engage all Scrum Team members, ensuring that everyone has a voice.
For a remote Sprint Planning, the following Liberating Structures microstructures have proven to be supportive:
- The Celebrity Interview is a useful way for the Product Owner to introduce the upcoming Sprint’s business objective. Working in the whole group, use mute and video off to distinguish between the Product Owner, the interviewer—a member of the Development Team—and the remaining members of the Scrum Team. Gather additional questions through the chat channel from the listeners as the interview proceeds. The interviewer should pass on these new questions in due time. (During the discussion, the Product Owner should not read these new questions at the same time.)
- Use a Conversation Café to discuss the purpose of the upcoming Sprint: Create groups with the breakout room function, and identify a host for time-keeping. During rounds 1, 2, and 4, where one participant is talking while the others are listening, use mute for the listeners. Once the timebox has expired, the previously talking participant “hands over” the microphone by calling out the next one in line and then muting him- or herself. As the facilitator, also consider providing a matrix — rounds by speakers with checkboxes — to the hosts to ensure that everyone has a fair share of airtime.)
- Consider running a Mad Tea to identify a Sprint Goal based on the business objective and the introduction of the Product Owner. Of course, we cannot recreate two concentric circles of attendees facing each other. However, what we can do is use a prompt—a half-sentence that the team members shall complete—and the chat channel to create a quick picture of the team’s sentiment on the Sprint Goal. As the moderator, prepare a few prompts in advance regarding the topic of the upcoming Sprint, for example, “I think the Sprint Goal should be…” Then post that prompt to the chat and ask the participants to add their answer(s) but not to hit enter. That is done simultaneously by all attendees when the host asks for it. The result is a bunch of suggestions on the Sprint Goal. Repeat the exercise if no suggestion finds unanimous support.
- Alternatively, a 25/10 Crowd Sourcing can also support the creation of a Sprint Goal: This microstructure belongs to those that are hard to replicate online with the currently available tools. The following prototype is not yet satisfactory but pointing in the right direction: Use a form application to collect both suggestions from the team members on the subject in questions as well as their names. Once all participants have filled out the form, export the answers as a CSV-file and import this file into a FunRetro.io board. (The board has the voting disabled, and the number of votes is hidden.) As the facilitator, distribute the answers in packs of five to new columns and allocate the “name tags” of the participants randomly to each column in an even distribution. Then activate the voting and ask all participants to vote on the answers in the column they have been assigned to before. (Hence the “name tags.”) Set the number of available votes so high that every answer in a column can be awarded from 1 to 5 votes. Once the voting has ended, move all answers to one column and activate the “vote count.” Finally, sort that column by votes. (There are many issues with that process. For example, you have eight suggestions for the next Sprint Goal, not ten.)
- Min Specs: Min Specs is an excellent exercise to focus the whole team on the essential work to accomplish the next Sprint Goal. In a remote setting, it is a sequence of individual work and group work based on breakout rooms, aggregating findings in shared workspaces to be shared with the whole group in the end. Min Specs work well with embedded 1-2-4-All and Shift & Share, see below.
- If you need to balance the demands of the Product Owner for new features with the necessity of the Development Team to keep technical debt at bay, probably already a latent conflict, consider running an Integrated~Autonomy session and ask “How is it that we can be more integrated and more autonomous at the same time?” As Integrated~Autonomy builds on a sequence of small group work based on 1-2-4-All, breakout rooms, and a shared workspace to visualize the outcome, it is also well-suited for a remote Sprint Planning.
Supporting Liberating Structures
Three Liberating Structures can support a remote Sprint Planning with a larger team: 1-2-4-All, Shift & Share, and Lean Coffee:
- To cover 1-2-4-All, we need breakout rooms and a place to aggregate the findings. We start with everyone in the whole group for a minute in silence; then, we split the whole group into pairs using Zoom’s breakroom feature for 2 minutes. After that round, we merge two pairs into a group of four for five minutes—this has to be done manually by the host–and the group aggregates its findings, for example, on a Google sheet prepared for each group in advance. We can introduce each group’s findings to the whole group by screen sharing in a Shift & Share.
- Shift & Share: Each workgroup presents its findings to the whole group by screen sharing. Alternatively, if the shared workspace has been created in advance, for example, Google Slides with a slide per workgroup, the moderator can share his or her screen while someone from the team is explaining the findings to the whole group. This reduces the stress of switching screen sharing on and off among several groups.
- Lean Coffee is an excellent example of a workaround for virtual Liberating Structures. Gather all the input in the usual way, for example, engaging in 1-2-4-All, and gather those on a FunRetro.io board while voting is turned off. (Use several columns if the whole group is large to speed up the gathering process.) Then ask the whole group to cluster similar topics, then turn on the voting and order the remaining entries by votes. For here, you continue with a whole group discussion, or you engage smaller groups with breakout rooms.
Remote Sprint Planning Antipatterns
There are plenty of Sprint Planning anti-patterns in general. However, I want to point at a few anti-patterns of Scrum Masters that are particularly relevant for a remote Sprint Planning:
- What are we fighting for? The Product Owner cannot align the business objective of the upcoming Sprint with the overall product vision. (Alignment is a challenging endeavor in the best of times; at a remote Sprint Planning, it is essential to preserve cohesion among the team members. A serious goal answers the “What are we fighting for?” question. To a certain extent, it is also a negotiation between the Product Owner and the Development Team. It is focused and measurable, as the Sprint goal—based on the business objective—and Development Team’s forecast go hand in hand.)
- The remote Sprint Planning is ignored: The Development Team is not participating collectively in the Sprint Planning. Instead, two team members, for example, the “tech lead” and “UX lead,” represent the team so the others can “work.” (The remote Sprint Planning is a critical opportunity for alignment between all team members, the product vision, and the business, and therefore mandatory. As far as the idea of one or two “leading” teammates in a Scrum Team is concerned, there are none, see above. And unless you are using Nexus or LeSS—no pun intended—where teams are represented in the overall Sprint Planning, the whole Scrum Team needs to participate. It is a team effort, and everyone’s voice hence needs to be heard. Otherwise, transparency suffers, and flawed decisions might be made, reducing value creation and increasing risk.)
- Planning too detailed: During the Sprint Planning, the Development Team plans every single task of the upcoming Sprint. (This might be triggered by a subconscious fear of loss of control due to the remote nature of the work. However, as in real life, there is no need to become too granular. One-quarter of the tasks are more than sufficient to not just start with the Sprint, but also start learning. The Sprint Backlog is emergent, and doing too much planning upfront might result in waste. Just embrace the Prime Directive.)
- Too little planning: The Development Team is skipping planning altogether, as working as a distributed team led to everything being now well-documented in the Product Backlog. (Skipping planning is unfortunate, as it is also an excellent opportunity to talk about how to spread knowledge within the Development Team, where the architecture is heading, or whether tools are adequate. For example, the team might also consider who will be pairing with whom on what task — which is even more essential in a remote working environment. The Development Team planning part is also well-suited to consider how to reduce technical debt.)
- Over-commitment: The team takes on way too many tasks for a distributed team and moves unfinished work directly to the next Sprint. (Over-commitment is problematic for co-located teams, but it becomes even more pressing for distributed Scrum teams, as the additional overhead needs to be considered. If two or three items spill over to the next Sprint while the Development Team meets the Sprint Goal, so be it. If regularly 30 to 40 percent of the original forecast is not delivered during the Sprint, the Scrum Team may have created a kind of ‘time-boxed Kanban.’ Maybe, this is the right moment to ask the Scrum Team whether moving to Kanban might be an alternative. If the team considered Scrum still to be its choice, I would recommend to put more energy into Product Backlog refinement and creating meaningful Sprint Goals.)
Read more: 21 Sprint Retrospective Anti-Patterns Impeding Scrum Teams.
Conclusions
Garbage in, garbage out: The task of aligning everyone becomes even more crucial for a remote Sprint Planning by comparison to the planing of a co-located Scrum team. The good news is that virtual Liberating Structures can help to overcome this communication disadvantage of a distributed agile team by visualizing issues and giving every member of the Scrum team a fair share of airtime.
What kind of remote Sprint Planning have you organized? Please share it with us in the comments.
✋ Do Not Miss Out and learn more about the Remote Agile Retrospective: Join the 7,400-plus Strong ‘Hands-on Agile’ Slack Team
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
📺 Remote Agile: Practices and Tools [Replay of a Live Virtual Class]
At the end of March, we ran a Remote Agile Practices & Tools live virtual class with about 30 participants from all over Europe, the Eastern Seaboard, and Canada. The participants agreed on recording it and make it available to the agile community. We edited the recording slightly; for example, we removed the waiting time during the exercise timeboxes. Otherwise, the video accurately reflects how one way of collaborating with a distributed team using Zoom breakout rooms may work.
Except for three teaching blocks of about 20 minutes in total, the whole Remote Agile Practices & Tools class of 2:45 hours comprised of interactive work:
If you have any questions regarding the class, please let me know via the comments, or contact me in the Hands-on Agile Slack community.
If the video snippet does not play, please watch the video on Youtube: Remote Agile (1) Replay: Practices and Tools for Scrum Masters, Agile Coaches, and Product Owners.
Remote Sprint Planning: Related Posts
Remote Agile (Part 1): Practices & Tools for Scrum Masters & Agile Coaches.
Remote Agile (Part 2): Virtual Liberating Structures.
Remote Agile (Part 5): Retrospectives with Distributed Teams.
Scrum: 20 Sprint Planning Anti-Patterns.
Liberating Structures for Scrum (2): The Sprint Planning.