- with overlapping working would create teams too small to deliver any value. The only remaining choice is to build a single scrum team with the members spread across the different locations.
Skills are also an important consideration when building teams. You need teams to have all the skills needed to deliver features for the project. This is desirable because ideally, you want any team to be able to pull the next highest priority work off the product backlog in their sprint planning meeting.
When a team in one location is lacking some skills, you must find ways to help them build up the expertise to help make them more independent. From our example in Figure 1, let’s assume the team in California is lacking some expertise for the project. They could identify a team member to pick up this knowledge and pair that person with a subject matter expert in another team to do some knowledge transfer. You can speed up the learning process by sending the team member to work face-to-face with the expert for a fixed amount of time.
Organizing the Product Backlog for Multiple Teams
One area teams working at scale commonly struggle with is how they organize their product backlog for multiple scrum teams.
A common anti-pattern that we have seen with large-scale teams transitioning to agile development is that they will break down a single product backlog into multiple, independent product backlogs each for a different agile team.
Figure 2 –A single backlog broken in five separate backlogs for five teams
Figure 2 shows a product backlog with five themes and five scrum teams. Because each team will focus on a different theme, they decide to split up the original backlog into five different smaller ones to have one per theme. This approach gives greater autonomy to each team, reduces dependencies and limits the need for the different teams to communicate and coordinate. Essentially, they are doing this because they want to reduce the pain of working in a large-scale distributed environment.
The truth is they are more likely to have slight differences across the product, duplicate effort and they may face issues when integrating their work. Distributed teams need to communicate effectively and work together to deliver good quality working code that meets the needs of their stakeholders. Splitting the product backlog into multiple product backlogs will not solve any communication and collaboration issues the team is having.
As is true for a single scrum team, multiple scrum teams coordinating to deliver a product should use a single product backlog to hold all the work items for the product. Ideally, as in figure-3 below, each agile team will pull the next highest priority work off the top of the product backlog and into their sprint backlog during sprint planning.
Figure 3 –Multiple teams working from a single backlog
Relative size of user stories is one of the factors the product owner will consider when setting priorities in the product backlog. Large-scale, distributed teams commonly struggle with deciding how to use agile estimation when multiple teams are coordinating to deliver a product.
In a simple agile scenario, all 5-9 agile team members directly take part in discussing and estimating every user story as well as coming to agreement on their relative sizes. In a large-scale environment, teams can easily diverge in their understanding of a story point. It is not practical, efficient or effective for all 150 members of a project team to discuss and play planning poker for every story in the Product Backlog. There are some techniques large