Overview

Iterations are optional in Program Management, if they are used, it's the downstream level of Program Increment. A Program Increment is made of N iterations however there is not strict enforcement of dates (ie. a Program Manager might define timeframe for Iterations that are outside of the boundaries of Program Increment).

Program Increments artifacts have an _is_child "forward" link to Iteration artifacts:

graph LR
    pi["Program Increment"] -->|_is_child| iteration["Iteration"]

Terms

For the sake of clarity, there should be some renaming:

• What is called "Mirrored Milestones" as of today should be known as "Mirrored Program Increments"
• The new concept will be called "Mirrored Iterations"
• The shared concepts between "Program Increments" and "Iterations" should be called "Timebox"
• The shared concepts between "Mirrored Program Increments" and "Mirrored Iterations" should be called "Mirrored Timebox" (the type of artifact link is not renamed)

Expected behaviour

The existing REST route PUT /projects/{id}/program_plan is modified to allow configuration of the "Iteration" level:

• Which tracker is selected as Iteration
• What are the custom labels (if any)

Creation preconditions

The creation of a new Iteration is done in the corresponding "Iteration" tracker. There are guards to ensure the consistency of the creation. It's the same that applies for Program Increment:

• The following tracker semantics must be compatible:
  • Title
  • Description
  • Status
  • Timeframe (either all trackers have start / end dates or they all have start date / duration)
• Synchronized fields are derived from those semantics.
• There are no required fields outside of synchronized fields.
• "Open" values for Status semantic are compatible (all Team trackers can have more "open" values than Program tracker but not fewer)
• Tracker workflows are compatible = no synchronized field is used in workflow, no synchronized field is used in date rules and no synchronized field is used in list rules.
• The current user (the user who is creating the Iteration) must have permission to submit in all mirrored trackers
• All synchronized fields can be "submit" and "updated" by the current user.
• Iteration and Mirrored Iteration trackers all have an Artifact link field, and it can be "submit" and "updated" by the current user.

In addition to that, the Agile Dashboard configuration of each Team project must have at least one "2nd level" planning (eg. Sprint planning). If there is more than 2 level it's not a blocker (but it will not be used FWIW).

If one of those checks fails, the user will not be allowed to create an Iteration

Creation of iteration

When all the preconditions are met, the creation of an artifact in the Iteration tracker will automatically create the mirrored iteration in associated Teams projects. The mirrored iteration is created as a child of the mirrored program increments (⚠️ this is an additional step when compared to the behaviour of Mirrored Program Increments).

Modification of Parent Milestones

This was a forgotten AC in the previous implementation. When a Parent Timebox (Program Increment or Iteration) is modified at the Program level, the mirrored timeboxes must be "re-synchronized" (if necessary) on the following semantics:

• Title
• Description
• Status
• Timeframe