Modern Scrum is a wonderful Framework that is designed for one Team producing one Product at one (virtual) Location. When doing real work, in a real Organization, there are three different things that scale:
- When there is more than one Team,
- When there is more than one Product, and
- When there is more than one (virtual) Location.
From now on, I’m going to restrict myself to Software, as these problems have too many variables otherwise…
The last case — more than one (virtual) Location — is easily handled — it won’t work within the same Software Development Scrum Team. You need to add technology so that the Team Members have high-bandwidth communications with each other for at least 3-4 hours a day in order to get the communications between the developers that is needed to develop software. This notion of having 3-4 hours a day to talk is what I mean when I say Virtual Co-Location – and it is necessary.
So, I will focus on the patterns for the first two Scaling Issues: multiple Teams and multiple Products. Also, I’m going to move away from talking about a single Backlog, and start talking about the Value Backlog and Work Backlog. As we see in the picture of Modern Scrum, we have four different Backlog-ey things when looking at a single Development Scrum Team:
- Value Backlog — Prioritized list of Items, represented by a Business Owner, that are up-stream from the Scrum Team. The Scrum Team does not deal with them directly; they are placed on the Team’s Work Backlog by the Business Owner.
- Work Backlog — Prioritized list of Items (including the Scrum Team’s own Improvements and Chores) that are being Refined to become Ready for the Scrum Team to work on.
- Sprint Backlog — the actual Tasks that the Scrum Team is working on now, in the current Sprint.
Let me explain the symbols on the right side of this diagram in more detail:
A Value Backlog is a flow of Items from a “from” entity (the Stakeholders in this case) to a “to” entity (the Business Owner / Project Leader (BO/PL) in this case). The “from” and “to” entities collaborate on the ordering/prioritization of the Value Backlog, and the “to” entity is Accountable for understanding and representing this Value Backlog to the Organization. Generally speaking, the Items don’t change as they move through a Value Backlog.
A Work Backlog is a flow of Items from a “from” entity (the BO/PL in this case) to a “to” entity (the Product Owner (PO) in this case), with the following properties:
- The “from” entity is Accountable for ordering/prioritizing, understanding and representing the inputs of this Work Backlog to the “to” entity.
- The “from” and “to” entities work together to Refine the Work Backlog (with the “to” entity being Accountable for this work) so that:
- The Work Backlog accurately and appropriately represents its inputs.
- The Work Backlog is appropriate for use the “next level down”.
- Note: This Refinement is represented by the tapered shape of the symbol.
- The “to” entity is Accountable for inserting appropriate Chores and Improvements into the Work Backlog — these insertions are represented by the lighter-shaded entities in the symbol.
- I often call both these things Chores in order to indicate that they were introduced to the Work Backlog at this point and were not inputs to the Work Backlog.
- The “to” entity is Accountable for understanding and representing this Work Backlog to the Organization, with particular attention on the down-stream entities.
I’m not showing the Tasks inside the Development Scrum Team, as they are simply a matter of the Team’s Self-Organization.
As you can see, the BO/PL generates a Plan in this diagram. This symbol is used to indicate that a Plan-like thing (Delivery Date, Project Plan, RoadMap and so on) is being produced and updated at this point — and that the entity it is attached to is Accountable for producing and maintaining it.
At the bottom we see the Scrum Team, along with its Product and Sprint Backlog (the horizontal lines on the left). For Teams other than Development Teams, I will use this symbol to indicate the Team’s Backlog because these Scrum Teams have a Backlog separate from theWork Backlog. For example, as we’ll see, a Distribution Team’s job is to manipulate Backlogs, and its work is managed by a separate Backlog.