Vocabulary
There are 2 kind of projects:
A Program aggregates the work of one or several Teams. A Team can contribute to one or or several Programs.
At Program level
there 2 kinds of Backlog Items:
- Features
- Program Enablers
and there are 2 levels of Milestones:
- Program Increment (aka P.I.)
- broken down in Iterations
Those milestones are mirrored in all the Teams that are aggregated with a given Program. At the end, all Teams are synchronized in term of Program Increment and Iterations. The actual backlog of each Team is, of course different.
At Team level
there are 2 kinds of Backlog Items:
- User Stories (that might be broken down in tasks for instance but it's not SAFe business)
- They are child of Program's Features
- Team Enabler
as well as the 2 Milestones types of the Program Level.
A Team will contribute to at least 1 Program but could contribute to more.
A Team might also have it's local agenda, not shared with any Program (like a technology provider Team that would release maintenance version of it's product that doesn't exactly fit in one Program).
Backlog Management
This epic introduce the need of cross project parent/child relationship for trackers as Features and Program Enablers belongs to Programs and User Stories (as well as Teams Enablers) belongs to Teams.
Note: For the sake of readability, in this section, we will only write about Features/User stories but same should apply to Program Enablers/Team Enablers. We might also have to deal with Bugs at the same level as Features but that's not completely clear how ATM.
Program level
At Program level, in Planning view, we will see Features.
The Features can follow the "maturation" model allowed by explicit backlog (created with a "Sandbox" state, broken down in User Stories and whey declared "Ready", appears in the top backlog for planning in P.I.).
At Program level, in Planning view, when Features are "expended", we can see the User Stories that comes from the various Team backlogs.
Team level
Important: Teams can be aggregated into Programs but they can also have their own "local" backlog and milestones, not at all connected to any program (think of a compiler that ships 2 versions of its technologies to 2 different programs but that also does maintenance releases of the technology itself).
At team level, we have the regular backlog management (with explicit backlog). User Stories can have parents:
- in a Program project (cross project)
- or in the Team project (like regular epics).
However, one User Story can have only one Parent.
At Team level, in Top Backlog Planning view, there is a "selector" in order to choose what to display:
- The local backlog & milestones
- The Program 1..N backlog & milestones
Milestones Management
Milestones are created and controlled by the Program. This is based on the concept of "mirrored milestones":
- The creation of a milestone a Program level triggers the creation of mirrored milestones at Team level. Those mirrored milestones will have the same name, dates, etc.
- When something is planned at Program level, the mirrored milestones are updated with the content that correspond to their Team (more on this later).
At Program Level
At Program level, Program Increment and Iterations are created. They trigger the creation of mirrored P.I and Iterations in aggregated Teams.
When a Feature is Planned in a Program Increment, each Team's Program Increment will be updated with the User Stories of the Feature. Example:
Given a Program with two Teams (blue and red), A Feature A with 3 user stories in blue or red:
Feature A
|-- User Story A.1 (Team blue)
|-- User Story A.2 (Team blue)
`-- User Story A.3 (Team red)
When Feature A is planned in Program Increment "Station alpha"
Then, in Team blue's "Station alpha" Program Increment we can see:
- User Story A.1 (Feature A)
- User Story A.2 (Feature A)
And in Team red's "Station alpha" Program Increment we can see:
- User Story A.3 (Feature A)
In term of permissions:
- The content of Program Increments can only be managed at Program level (add/remove Features, change of priorities, etc)
- Teams cannot change by themselves the content of a Program Increment at Team level
- The content of Iterations is managed at Team level. Given a "fixed" backlog for a Program Increment, Teams are free to organize themselves at will to schedule the User Stories in the Iterations.
Configurability
While the module is designed to best fit the SAFe concepts, it should be possible to change the names of the elements to adapt to other usage:
- Milestone trackers might be named "Release" and "Sprint"
- Backlog trackers might be named "Requirements" and ...
Iterations
Program Management will also allow to manage Iterations. Here is the breakdown for now:
graph TB
config("Know which tracker is Iteration")
base_app("Base of the new Iteration View (frontend)")
verif("Run checks before creating an Iteration")
replicate("Duplicate the Iteration in the Teams<br>(create Mirrored Iterations)")
modif_sync("Copy Iteration modifications in Mirrored Iterations")
list_iterations("Fetch and display the Iterations (blocks on the right)")
backlog("Fetch and display the #quot;backlog#quot; view (left)")
iteration_content("Fetch and display the contents of an Iteration")
modif_sync_PI("Copy Program Increment modifications<br>in Mirror Program Increments<br>(and remove the warning)")
verify_update_PI("Run checks before updating a Program Increment")
verify_update_iterations("Run checks before updating an Iteration")
modif_sync_PI --> replicate
modif_sync_PI --> verify_update_PI
replicate --> modif_sync
replicate --> verify_update_iterations
config --> verif --> replicate
base_app --> list_iterations --> iteration_content
config --> list_iterations
replicate --> iteration_content
iteration_content --> backlog
classDef done fill:#c5c5c5;
class config,verif,modif_sync_PI,replicate done;
SAFe versus Multi Project backlog
Multi Project Backlog (MPB, art #14951) is a generic approach of management of backlog in different projects. This requirement arise when organisations grow, regardless of their process (agile, waterfall, etc). However, in the generic implementation, fitting SAFe is a bit cumbersome.
With a closer SAFe compliance, those abstraction would not be necessary and new comers will understand easily how things are organised. However it will be harder to do "not SAFe" with this module. At a later point we might need MPB as originally intended for those use case.
What is kept from Multi Project Backlog ?
The whole Milestone management doesn't change. We still have Milestone driven by the Program Project and replicated in the Team Projects with the "Mirrored milestone" mechanism.
Team projects still have the possibility to create their own "local" milestones.
What's new/change ?
The big changes are on the Backlog Items management because we need to manage Features (and Program Enablers) at Program level. That bring main differences with MPB:
- There is no need to manage "explicit backlog" between projects (for User Stories). User Stories will no longer "travel" between projects. They will be visible at Program level via their parent Feature.
- The cross project parent/child relationship can be restricted to SAFe module if needed
- There is a need to manage a Planning configuration at Program level (to associate Features => Program Increment)