• How to divide the scrum teams. We will provide some guidelines for teams to consider.
• How to divide the work across the different scrum teams. In this section, we will discuss how to manage a Product Backlog when working with multiple teams.
• How to overcome challenges around agile estimation. In this section, we will talk about how distributed teams can work to gain a common baseline for story point estimates and we will also discuss ways to estimate the stories in the backlog.

Setting up the teams

Locating team members in the same building, the same floor and the same work area is the ideal scenario for organizing scrum teams. This optimizes the flow of communication and the collaboration between team members.

However, for various reasons, many software development teams are now distributed with members in many different locations. Depending on the geographical locations of these different teams, they will work in one of the following distribution levels:

• Collocated teams: This represents the ideal scenario where all team members are in the same physical location, collaborate and meet face-to-face regularly.
• Collocated part-time teams: These teams have members in the same physical location with some occasionally working off-site, either from another business location or their home offices. These teams experience some of the challenges experienced by distributed teams, however, in general, team members are in the same time zone and can meet face-to-face if necessary.
• Distributed with overlapping work hours: These teams have members in different physical locations, with working hours that overlap one another to some extent. An example of this is a North American team with members in Montreal, Canada (UTC-5:00) and in San Jose (UTC-8:00). The three hour time difference allows a part of the day where team members from both locations are working at the same time.
• Distributed with no overlapping work hours: These teams have members in different physical locations, with no common hours in their work days. An example is a project team with members in Austin, Texas (UTC-6:00) and in Beijing, China (UTC+8:00). These kinds of teams face the biggest collaboration challenges.

Figure 1 – Working hours for a project team with members in four different location

Figure 1 above shows a project team with members in four different locations. When setting up your teams, you want to reduce the distribution level between team members as much as possible to encourage collaboration and communication. In order of lowest to highest distribution level, here are some team configurations to consider:

1. Collocated Scrum teams at each site: If you have enough team members and the right skills mix at each site to build cross-functional feature teams, this arrangement will bring the lowest distribution level for the project teams. The teams in different locations can coordinate using a regular scrum of scrums.
2. Teams with overlapping hours: When you do not have enough team members in one location to build a cross-functional team, you may want create teams by putting together team members that have overlapping working hours between them. With the project team shown in Figure 1, the team members in Texas and California have overlapping working hours, as do the ones in India and China. Assuming these team members have the right skills to build cross-functional teams, you may want to consider creating teams this way.
3. Team members with no overlapping work hours: For the sake of discussion, let’s assume this is a smaller project team with one or maybe two members in each of the different locations. In such a case, a collocated team per location or even teaming members 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

Agile Estimation

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 teams can use to overcome these challenges.

When multiple teams are working with a single product backlog, all teams do need to have a common understanding of the sizing of their work items. Teams need a common understanding of relative size to be able to confidently pull work from the product backlog and the Product Owner needs the same understanding to set the priorities in it.

Why the Team Needs a Common Understanding of Relative Size

For the sake of discussion, Table-1 shows an example where three different scrum teams working on the same project are estimating the same five user stories in their common product backlog. Table-1 below shows the teams are using different scales for their estimates.

Table-1 – Three teams estimating the same five stories in the backlog

If Team B picks a five point user story from the backlog estimated by Team C, then based on their scale, they will believe there is less work involved. They may not realize that for them, the equivalent is a thirteen point story. For Team C, the reverse is true, based on their scale, they will believe there is much more work involved if they pick a five point story estimated by Team B as this is a two-point story for them.

Why the Product Owner Needs Consistency in Relative Sizes

In projects where relative story sizes are inconsistent, the difference in the estimation scales also makes the relative investment for each story unclear. This makes it difficult for the Product Owner to prioritize the backlog.

Creating Consistency

The project team members need to build a common understanding of the estimation scale together. To do this, they must work together to identify reference stories from their product backlog the team can use as a common baseline for estimates. Finding multiple reference stories to use as data points will help the teams estimate stories more consistently.

The project team size and distribution level can help decide on the approach to use to build the common understanding of story points. There are two approaches teams can use:

• Full project team estimation workshops
• Partial project team estimation workshops

Full project team estimation workshops

This approach is for smaller project teams of up to thirty people. All team members involved in the project will take part in a workshop together to estimate a representative common set of user stories.

It is easier to use this approach with collocated project teams but distributed project teams with overlapping hours can use it as well. They can use conference call where team members dial-in either independently or grouped by location. Grouping the team members from the different sites together will increase their collaboration during the workshop. For the voting during the workshop, teams can open a group chat session in an instant messaging tool.

Distributed teams with no overlapping hours need to negotiate a time that will allow all team members to take part in the workshop. Depending on the number of remote team members, it can make the workshop more challenging to schedule.

You can review the pros and cons of this approach in Table-2.

Table-2 – Pros and cons of full project team estimation workshops

Partial project team estimation workshops

This approach is for very large teams, for example, 150 developers and 15 agile teams, collaborating on a project. Each team involved in the project identifies representatives to take part in a virtual group workshop. These representatives need solid knowledge of the product and the right skills mix to produce reliable and consistent estimates.

During the workshop, the participants need to look through the project product backlog, identify and estimate a common set of reference user stories. After the workshop, the representatives will bring these reference stories to their teams and will coach them to use the common estimation scale. The key is looking for ways to bring the larger teams together to ensure a common understanding.

Very large teams are typically not collocated, but if they are, it makes the meeting easier to organize. Distributed project teams with overlapping working hours can identify a common time and use a conference call. To vote during the workshop, the teams can use a group chat session in an instant messaging tool.

Distributed teams with no overlapping hours need to negotiate a time that will allow all the representatives to take part in the workshop. Because of the smaller number of participants (relative to using the full team approach), it can help make the workshop easier to schedule.

You can review the pros and cons of this approach in Table-3.

Table-3 – Pros and cons of partial project team estimation workshops

Estimating using Planning Poker

A common technique used for Agile estimation is a version of Planning Poker described by Mike Cohn in Agile Estimating and Planning. In a collocated work environment, each team member discusses a user story. Then, at the same time, all collocated members display a physical playing card that points out how big they think the story is.

The numbers on the playing cards represent abstract story points or ideal days (Cohn 2006). Story points are an abstract, relative unit of measure. The team asks itself, "Is Story B half the effort of story A? Is story C bigger than both A and B combined? Where does Story D fit? Story D is similar effort to story B". A user story worth two story points is about one-fourth the size of one worth eight story points and twice as big as one worth a single story point. Ideal days are the second method for measuring size. Ideal days represent the time something would take without any interruptions. E-mail, meetings, and other corporate overhead aside, a story estimated at 1 ideal day may take around 2 "real" days to complete.

To apply Planning Poker in a distributed environment, the ScrumMaster can read a user story, the team then discusses it and the team types a number into a group chat window. For new teams, calling out, “Ready, set, go!” will help get team members to type their values into the chat window simultaneously. Getting the estimates together prevents the estimate from one team member from influencing other team members.

Teams more comfortable sharing their opinions with one another do not need the “Ready, set, go!” The ScrumMaster can just ask team members directly for their estimates they will respond with their numbers.

When using a group chat window, you need to define clearly where the set of new estimates begins because a long list of numbers in the chat makes it difficult to understand to which story the estimates apply to.

As an alternative, you can use PlanningPoker.com (Cohn Play. Estimate. Plan. http://www.planningpoker.com/). You may not be able to enter your user stories if security is an issue for your organization; however, the ScrumMaster can verbally identify the stories and the team can respond by selecting cards. PlanningPoker.com has a built-in timer the team can set after discussing the user story to limit time spent on it.

Conclusion

The product backlog is the backbone for agile software development. For teams to deliver great value to their stakeholders, they first need to create, size and prioritize the product backlog and then groom it each sprint.

While it is tempting for large-scale, distributed teams to use multiple product backlogs, we have found that teams that are working together and coordinating to deliver a product are more successful when they use a single product backlog.

Teams also need a common understanding of what a story point is. Depending on the size of the team, they can use full team estimation workshops or partial team estimation workshops to create and maintain a common understanding of story points. Distributed teams can use online planning poker tools or a simple chat to estimate their stories in a virtual environment.