Tuleap 16 est là ! Assistez à l'événement virtuel le 17 octobre à 10h30. Inscrivez-vous ici !

    •  
      epic #16683 Program Management
    Summary
    Program Management
    Empty

    Vocabulary

    There are 2 kind of projects:

    • Program (or Train)
    • Teams

    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)
    Progress
    Empty
    Empty
    Closed
    Details
    #16683
    Manuel Vacelet (vaceletm)
    2022-01-13 12:12
    2020-09-10 15:29
    Attachments
    References
    Referencing epic #16683
    Referenced by epic #16683

    Artifact Tracker v5

    epic #14951 Multi project backlog
    story #17878 rename Multi Project Backlog into Scaled Agile
    story #17879 add Teams to Programs
    story #17880 define Program Plan
    story #17882 define cross project hierarchy between Features and User Stories
    story #18388 Scaled agile, have consistent architecture between rest route and UI
    story #18405 distinguish Features and P.I. that comes from a Program in a Team
    story #18408 plan Features in Program Increment
    story #20066 display stories childen of features
    story #20067 move Program out of experimental
    story #20068 Improve program management configuration
    story #20111 change features priority
    story #20119 display progress and dependencies
    story #21368 create mirrored iteration
    story #21385 display Program's iterations
    story #21791 see Programs & Teams in sidebar
    story #21792 define Teams associated to Programs
    story #21793 configure Program Management
    story #21794 display Program Management configuration errors
    story #21795 choose project colors in apperance
    story #22210 select SAFe templates at project creation
    story #22211 restrict activation of Program Management service
    story #22585 improve SAFe templates
    story #22675 replicate program increment changes to mirrored program increments
    story #22681 select a parent from Program for my features/enablers
    story #22687 distinguish projects with an icon
    story #23499 re-synchronize Iterations
    story #24174 add Iteration to ART & Team templates
    story #24175 inform admins about Program Management configuration errors (update)
    story #24194 have a SAFe Portfolio template

    Follow-ups

    User avatar

    The initial scope envisioned for Program Management is now completed.

    There will be evolution of SAFe support as well as generic Program Management but it will be covered in dedicated epics


    • Status changed from On going to Closed
    • Category set to
    User avatar
    Joris MASSON (jmasson)2021-10-14 16:49

    Update iterations graph with up-to-date state. Greyed items are done.


    • Description
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes
    User avatar
    Joris MASSON (jmasson)2021-05-20 16:24
    • Description
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes
    User avatar
    • Description
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes
    • links
    User avatar
    • Description
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes
    User avatar
    • Description
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes
    • Permissions set to all_users
    User avatar
    • Description
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes