Distribution Team

Dan Rawsthorne//January 31, 2019

Pattern: Distribution Team

This is the simplest Scaling Pattern, often used when there are multiple Scrum Teams working on the same Product.

Problem:

You want to split a single Backlog into multiple sub-Backlogs.

Context:

This is a generic Pattern, and is applicable in many Contexts, including (but not limited to):

  • There is a Value Backlog representing a Project that is going to be worked on by multiple Development Scrum Teams, who each need their own Work Backlog.
  • There is a Value Backlog being split into two Value Backlogs to be fed to two different Entities; an example is splitting a big Value Backlog into two little Value Backlogs for different Organizations to work on.
  • We could have a Development Team split into two smaller Teams, and thus need to split its Work Backlog into two different sub-Work-Backlogs.

Solution:

Assume that the “Parent” Backlog (Backlog-A) is represented by Owner-A, and that the “Child” Backlogs (Backlog-1 through Backlog-n) will be represented by Owner-1 through Owner-n. Then, assemble a Scrum Team, called the Distribution Team, with the following properties:

  • Owner-A is the Distribution Team’s Product Owner,
  • Owner-1 through Owner-n are members of the Distribution Team (they are probably Virtual members)
  • The primary purpose of the Distribution Team is to decide which Items from Backlog-A will go to each of Backlog-1 through Backlog-2.
  • (for each i) Owner-i is Accountable for representing and explaining Backlog-i’s Items to the Organization.
  • (for each i) If Backlog-i is a Work Backlog, then the Distribution Team will help Owner-A and Owner-i Refine and Order the Work Backlog, and add any necessary Chores.– Owner-i is Accountable for the Refinement and for adding the Chores.
    – Owner-A is Accountable for explaining the Items from Backlog-A that are being Ordered and Refined.
    – The Distribution Team is merely helping…
  • If Owner-A is also a Project Leader, the Distribution Team will help Owner-A update his or her Plan every Sprint.
  • If Owner-i is also a Project Leader, being on the Distribution Team will provide useful information for updating his or her Plan every Sprint.
  • The Distribution Team has its own Backlog that describes how it will carry out these Responsibilities.

Distribution Team Pattern - 3Back Scrum Pattern Library

Discussion, including examples:

This Pattern is fairly straightforward, but here are some comments:

  • Since this is a Scrum Team, there shouldn’t be more than 5 (or so) outgoing Backlogs; otherwise the Distribution Team could get too large to be an effective Scrum Team. In other words, this Distribution Team may have its own Scaling issues.
  • Luckily, these Distribution Teams can be layered, allowing a Backlog to be split many different times, solving the Scaling problem mentioned above.
  • Since this is a Scrum Team, and thus a Well-Formed Team, the Distribution Team may need additional Subject Matter Experts to help with the splitting of the Backlog. These SMEs could be Architects, Business Analysts, experts in the Business Domain – whatever is needed.
  • Since the Distribution Team is a Well-Formed Team, it must do its due diligence in its work, making sure its results meet appropriate Standards of Care–In particular, this means that this Team needs to be able to Develop and Maintain any relevant Project Plans, and that any Project Leadership must be good Project Leadership – there must be no coercive or predictive behavior.
    – I summarize this concept by saying the we must “value Predictability, not Predictions…”
  • These Distribution Teams often turn into Management Teams because this splitting is an implied hierarchy (see the Management Team Pattern).

This is a simple, but powerful, Pattern. It’s primary strength is that it brings the right People together to Split the “parent” Backlog.