Olha KurishkoScrum is a popular Agile software development framework that helps teams manage their projects. This framework can also be useful for remote workers, but it’s important to adjust some practices for a scattered team to be successful.
We’ve put together this guide to help you manage your distributed Scrum team more effectively. We also explain how to handle Scrum events to highlight priorities and capture any problems or new ideas on the fly.
Table of Contents
Distributed Scrum Team — How to Organize and Manage It
A distributed Scrum team is either fully or partially remote. The main difference from the in-house team, which holds meetings next to a physical whiteboard, is that the remote Scrum team uses online collaboration tools to track issues, send messages, and hold ceremonies and brainstorming sessions. Furthermore, much of the Scrum’s defined set of rituals and roles can be adapted to a remote work environment, including Scrum ceremonies.
Thanks to regular and well-planned meetings, the distributed Scrum team is clear about where it stands, and the product owner gets prompt feedback from each member. This refers, above all, to daily standups, where you can learn if anyone on the team has any difficulties or blockers preventing them from meeting deadlines.
Here’s what to pay attention to when managing a fully or partially remote Agile team:
1) Daily standups are limited to 15 minutes
The Scrum Master should make sure the daily stand-ups are brief. No interference from anyone if a team member is giving status. If any issue requires further discussion, the team members concerned should book an additional call outside of the daily stand-up. The Scrum Master should also make sure that such discussions happen afterward.
2) Asynchronous stand-ups may be an option for teams working in different time zones
If a team is distributed in different time zones, they can hold asynchronous meetings, post them on a dedicated Slack channel, and collect comments from other participants. This will also reduce Zoom fatigue.
Optionally, each team member fills the status updates template and sends it before daily stand-up.
3) Using online Scrum boards to track sprint progress ensures transparency
The team should use a tool like Trello or Jira to manage sprint tasks. The Scrum Master maintains the board, ensuring that tasks and cards are updated as they are completed. The task list should be organized so that anyone can see the team’s work status during each sprint. This ensures transparency and gives everyone insight into what steps remain before a deliverable is complete (and when it will be ready).
4) Agree on communication channels to ensure the team and the product owner understands the usage of each communication tool
The Slack workspace usually has several channels, so the Scrum Master should explain what situations each channel is used for. Also, before sending a chat message, the team should consider using less distracting methods like emails or issue trackers. Interrupting others less frequently will make it more likely you’ll get attention when you need it.
In all other respects, managing a distributed Scrum team is no different than managing an in-house team. The Scrum Master plans sprints, collaborates with the product owner to ensure a more transparent product backlog, and shields the team from outside stakeholders who might want to expand the project’s scope.
Browse 500+ Dev Teams Available for Hire
Scrum events and how to handle them remotely
The advantage of regular Scrum events is to capture any problems or new ideas on the fly, adapt the work to new conditions, and improve communication and teamwork.
The Scrum framework is not about bothering engineers with huge piles of documentation, but about addressing more issues with regular conversations and highlighting priorities in the short term. Let’s take a look at the main Scrum team meetings and how to manage them.
Sprint Planning
Sprint planning is an event that ensures that the team understands the sprint goal and direction on what to work on in the next few weeks. It encourages the team to frequently review and identify, and possibly undertake, the most strategically advantageous developmental work.
The sprint planning meeting is usually divided into two parts to discuss:
- What needs to be built during the sprint
- How the team will build it
A Scrum Master can ensure all participants follow Agile methodology and give developers the freedom to decide which user stories, according to priorities, they will take on to fulfill the sprint goal. Let’s look at each section’s challenges and who is responsible for them.
- What needs to be built during the sprint
The product owner usually provides story overviews. They are in charge of explaining the sprint goal.
The team usually commits to the scope that they are taking into the sprint. The team members ask the product owner questions to get a clear picture of what should be created and decide on which items should be moved from the product backlog to the sprint backlog until the developers find it quite achievable. The team can also help the product owner refine and prioritize the product backlog before the sprint planning meeting.
- How the team will build it
In this phase, which is mostly handled by developers, the team discusses, in more detail, how they will deliver the selected product backlog items. User stories are broken down into tasks to be completed, which may include design, coding/implementation, research, or quality assurance.
The outcome of the sprint-planning meeting is the actual sprint plan that can be looked at in the daily Scrum.
Daily Stand-up (Daily Scrum)
According to a Scrum Guide, daily stand-up creates focus and improves self-management. It concentrates on progress toward the sprint goal and produces an actionable plan for the next day’s work. Actually, the purpose of daily Scrum meetings is to:
- point out blockers;
- talk about difficulties and request help;
- share valuable information
Distributed teams without overlapping work hours may use asynchronous stand-ups. They can create a dedicated Slack channel or comment on their work board to share updates as they come online.
If the remote team does decide to have daily video calls, the Scrum Master should make sure that they are productive. Rephrasing status updates that can be seen on the work board is useless. Also, sometimes developers start discussing technical implementations or bug fixes in detail. In this case, everyone else on the team not involved in the feature or technical stack just zones out after 30 seconds and may not return even when the team moves on to the next topic or developer.
Sprint Review
During the sprint review, the product owner discusses the product’s current state, gets feedback from stakeholders, which may include product managers, designers, and business analysts, aligns the product backlog with the feedback received, and adapts it with budgets and market changes.
In general, the sprint review can be divided into two phases:
- Review what’s “Done” and “Not done”, and demonstrate the work. For example, if you’re producing smartphone apps, you should distribute developer phones to everyone at the meeting. These phones should have the latest version of the app on them so that the stakeholders can try out new features.
- Observe and discuss whether the work done resolves the customer’s problem, how the marketplace or potential use of the product has changed, and what needs to get done next.
The most important thing during refinement is listening to feedback from stakeholders—and not simply showing each team member’s results.
Sprint Retrospective
While the sprint review is primarily concerned with maximizing product value, the sprint retrospective meeting is a problem-solving session attended by scrum team members. The team identifies what went well, what should have gone better, and what they should try to do differently during the next sprint regarding interactions between members or tools and development practices.
Sometimes stakeholders want to participate in retrospectives or at least see the summary notes to understand current areas of improvement better from the team’s point of view.
For this type of meeting, the Scrum Master will need to create an atmosphere of openness and appreciation. It’s not an environment for placing blame, but for drawing conclusions, making improvements, and taking subsequent actions for the team. It’s meant to be a forum for getting better with each Sprint.
The Scrum Masters usually follow the five phases of retrospective meetings suggested in “Agile Retrospectives“:
- Set the stage
Give people time to “arrive” and get them ready to participate.
- Gather data
Create a shared pool of information to make sure people are working with the same set of facts. - Generate insight
Why did things happen the way they did? Identify patterns to see the big picture. - Decide what to do
Pick a few issues to work on and create action plans of how you’ll address them. - Close the Retrospective
Clarify the follow-up and express appreciation.
The most difficult part is probably gathering and processing information. The Scrum Master may want to know about how to collect and use data in problem-solving. They can start with a general set of questions:
- Who cares about this issue?
- What other effects can we observe?
- How does the issue impact a particular person or group?
- What is the impact on our organization?
and then dive deeper and get more specific:
- When does the problem occur?
- How frequently does it occur?
- Which factors might contribute to the problem?
- What other events might influence the context?
- Is this common, or was it an exception?
If the Scrum Master knows there are several issues to discuss, then it is better to do a separate problem-solving session for each issue.
Also, some problems may require additional coaching or more in-depth training, but what’s important is that retrospective meetings not only point to a solution, but also encourage the members to reflect and learn.
Backlog Refinement
The product owner and development team may initiate backlog refinement as a formally scheduled meeting, but it is usually an ongoing activity to add details, evaluations, and for ordering user stories in the product backlog.
Backlog refinement helps to keep the team on the same page with the product owner and product team. Its main objectives are to:
- Clarify priorities
The team will focus on what’s important and look beyond at least one or two Sprints.
- Maintain sprint velocity
Even before the team gets to the sprint planning meeting, there should be well-defined tasks ready to be moved to the sprint backlog. That way, all the thinking and planning have already been done.
- Conduct efficient meetings
Sprint planning is short and transparent because backlog items have already been prioritized and evaluated.
Teams can initiate refinements by themselves if they lack the product vision or are uncertain about some functionality details. The Scrum Master should also participate in such meetings to get an overview of the current situation with sprint goals and, based on the retrospective outcomes, help the team define what is most feasible.
It is also better to invite QAs for refinements, even if they are a separate team and have their own procedures. It will improve synchronization between product development and QA teams.
The main refinement activities are:
- grouping the backlog into near-term and long-term items;
- creating new user stories in response to newly discovered needs;
- splitting user stories into smaller, more precise items;
- assigning or correcting estimates;
- removing items that no longer appear relevant;
- closing issues beyond the team’s long-term capacity, flagging them “out of scope” in the team’s issue tracker to use for research later;
- re-prioritizing items due to customer feedback, requested features, and refined estimates.
We hope this article has given you new ideas for managing a distributed Scrum team. If you also need to better understand which Scrum tool will fit your project best, read our blog entitled Top 11 tools for Agile project management.
Artem Vasin
