Ask Women in Product: How do you manage Scrum for multiple teams within the same cycle?

Image by MichaelModePhotog via Twenty20
Image concept by scrum.org

The First Case: several small Scrum teams

In smaller companies, you’re likely to have small teams of up to 6 people, with developers, quality assurance (QA), UX designers, and a Product Owner (PO) in each team. This case is closer to the iconic Scrum, and it’s easier to build this type of team in a small company. Teams like this easily act as one system — one heart beating. In this case, using one sprint size and a common sprint start date for all teams is the best solution because it synchronizes the teams in the organization. Synchronizing the teams also makes it is easier to deploy a solution and launch new products. Small, self-organizing teams can handle communications between themselves without any defined process, which is wonderful.

Case 1. Alignment is maintained by the Product Owner. Image by Lilia Gorbachik

The Second Case: mixed types of teams

A more complex case from the product owner’s point of view is that of a larger company with a more diverse product portfolio.

Case 2. Multiple communication channels are used to keep teams aligned. Image by Lilia Gorbachik
  • Common product backlog. It is great to have a common product backlog. It helps keep goals and priorities clear.
  • Separate sprint backlogs. Each team has a separate sprint backlog to work with. The team-specific backlog will set clear goals for the team and make their scope visible. At the same time, it is useful to see if the individual task has a linked task in another team.
  • Separate burndown charts. Keep this chart per team, because each team tracks their progress individually inside the group.
  • Common Retrospective. We work based on one product–one goal, so having a common retrospective for multiple teams is a good idea. A common retro can be a place for larger discussions, such as which forms of communication work and which do not. Also, common retros will allow everyone to feel attached not just to their team, but to the company and product as well.

The Third Case: loosely-coupled, tightly-aligned teams

There is a third team structure that you may be working in, one that has been popularized by Spotify. In this structure, each team acts as an independent business unit within the organization. At the same time, other virtual units are created that connect people based on other properties, such as:

  • a feature
  • the platform (mobile app, desktop app, etc.)
  • the technology
  • an idea (security, scalability, etc.)
  • a department (front-end development, QA, back-end development)
Case 3. Loosely coupled, tightly aligned teams. Image based on Spotify’s Engineering Culture video

In Closing

If you need to further customize the frameworks above because of a specific need or limitation, simply keep the following set of principles in mind:

  • You will always need to rely on a role or goal or principle around which all work is organized. Everyone needs to know what that organizing principle is so that teams are aligned as they make progress on their respective backlogs.
  • The communications channels are tailored to each specific configuration because you want there to be enough flows of information for teams to stay in sync, but not too much that people are spending time on non-essential busywork.
  • Consider the best use of each Scrum artifact for your particular scenario and decide if they should remain at the team level, or if they should be shared across teams.
  • Finally, never stop sharing best practices and lessons learned, so that everyone keeps getting better together.
  • Team Setup
  • Backlog Management
  • Stakeholder Management
  • Technical Considerations and Tools

Team Setup

Why are there multiple Scrum teams? Is it a case where you are the product manager over different products, or is your one product so large that you need multiple teams?

  • Are the teams using the same sprint start and end dates? If so, how is that working for the teams? It can be a challenge for a product manager when multiple teams have ceremonies on the same days, but not impossible.
  • Can the teams conduct their ceremonies at different times of day, so that you can attend both? The advantage with this is that you get all your ceremonies done, with the rest of the sprint left for you to divide your time between your two teams.

Backlog Management

What’s the situation with the backlogs? Do the teams have separate, distinct backlogs? Are both teams pulling work from a single backlog?

Stakeholder Management

What are the expectations of your stakeholders? How involved are your stakeholders in the day-to-day work of your team? Do stakeholders require your teams to be on the same start date, have a shared showcase, etc.?

Technical Considerations & Tools

Are your multiple teams working in the same code base? If so, do they have a defined branching and merging strategy? What is your approach to QA/testing and fixing defects/bugs?

You Can Do This!

If you are the product manager for multiple teams, you can absolutely drive success for both your teams and your product(s). While it usually isn’t an ideal situation, you can — with proper organization, documentation, and time management — deliver awesome products while having some fun along the way!

Use these resources to learn more

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store