Large-Scale Distributed Agile Teams – Creating, Sizing, Prioritizing and Grooming the Product Backlog


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

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.