Sprint planning for remote teams
The spring planning is the ceremony that kicks-off the next upcoming sprint. It is the event where the whole Scrum Team debates over the work that will be the focus point of the next few weeks, depending on the sprint duration and the sprint goal.
Sprint planning happens at the beginning of the sprint. However alot of teams are preparing the backlog and remove uncertainty during a ceremony called the Backlog Refinement Meeting. During this section we will focus on the key elements of a remote backlog refinement process. These tips, however, can be applied during the Spring planning as well.
Backlog refinement is an agile ceremony, usually taking place at the mid of the sprint. The Product Owner or Scrum Master facilitates the meeting. The purpose is to prepare the backlog for the upcoming sprint planning. Backlog refinement ensures that important tasks stay on top of the list. With team discussion, there is alignment over the feasibility and effort of each task.
During a backlog refinement meeting, team members discuss the user stories or tasks over the following scopes:
- Keep most important items to the top, as candidates for the upcoming sprint planning.
- Remove unrelated or obsolete items.
- Create new user stories if needed.
- Break down items into smaller ones, to keep the scope small enough to match the sprint’s length.
- Align the whole team over the effort required to get things done.
What a backlog refinement session offers is a shared understanding of upcoming work for the entire team. For example, a Product Owner can see the technical limitations or technical refactoring required to deliver a new feature. Or, for an engineer to understand functional requirements or needs for infrastructure upgrades.
Sharing different perspectives – from product, development, QA, and DevOps – helps to create a common understanding of a work task. With more clarity, the Product Owner can understand the effort required for each task. With all this data in mind, the Product Owner can take an informed decision over the value vs. effort, and prioritize or deprioritize a user story for work.
Usually, a backlog refinement session is done over a synchronous meeting. The whole team gathers, and the Product Owner brings items for discussion and clarification on the expected outcome.
When a task is clear, the team can size the effort on delivering that task from the backlog. The sizing process has the following outcomes:
- It fosters discussions to better understand the requirements of the goal.
- It surfaces different perspectives on the implementation difficulty. For example, a member might say that a task is “easy” to build but forget to include QA or updates to the documentation.
- Hard to complete tasks, break down into smaller independent tasks. Small independent tasks ensure continuous delivery and incremental releases. A continuous delivery flow is reducing the development risk, shows progress over time, and makes the team happy with the work done.
The most common sizing technique is the planning poker activity. During the activity, the Development Team is estimating the effort required over a metric, for example, “small”, “medium”, “large”, “extra-large”, or using a Fibonacci scaling, such as 0.5, 1, 3, 5, 8, 13, 100. When all members align over the sizing effort for a task, this task is refined and the team moves on to the next task. In cases of big diversity in effort sizing, for example, if someone says “small” and another says “large”, a discussion starts to clarify further.
In a remote setting, the activity is asynchronous, to span many timezones. In that case, the estimation can happen over a tool, like Slack or Microsoft Teams. In such cases, team members estimate a set of user stories at their pace. Then, a discussion can take place asynchronously as well, if required.
A combination of sync and async refinement process is also possible. Starting off by providing a set of tasks to estimate at their time. When everyone has voted, a synchronous meeting takes place to discuss uncertain items and come to a common plan.
The backlog refinement session has a few key challenges for both the Product Owner and the Development Team:
- Decide on priorities based on the customer value vs. the effort required to get it done.
- Be able to size the complexity and the effort based on what is known. Are there rabbit holes ahead? Is there unknown technical debt lurking around the corner, putting the endeavour at risk?
- Ensuring that user stories or tasks are clear enough so that everybody on the team has a common understanding of what is at stake during the discussion.
- Remove bias over the sizing of the work. Everyone should be able to equally contribute from their perspectives, without senior people exclusively setting the tone, and driving the discussion.
In a remote setting, challenges have the potential of opportunities. Given the async nature of a remote team, written clarity over the work to be done is becoming more important than ever:
- Using digital backlog management software, the Product Owner can describe user stories. With clarity, there are no loose ends, so the Development Team understands better how to refine the work for that user story.
- The team can use digital planning poker tools, to size items, without creating bias.
- The Development Team can “buy” time to prepare beforehand, and make a better contribution to the refinement process.
This guide is inspired by a combination of our own expertise and application, as well as from our customers consultation, expertise, and usage of our service, Team O'clock.