SAFe® in Azure DevOps - Iterations

This is part of a series on how to configure Azure DevOps Boards for the Scaled Agile Framework. The first article set up the Process which includes various Work Item Types and Backlog Levels. Now we're going to look at Iteration Paths.

SAFe® Iterations

The Scaled Agile Framework has two cadences:

• Iterations (Sprints) - relatively short time periods for planning and execution. Iterations begin with Sprint Planning; have a Daily Standup (or Daily Scrum); and end with a Sprint Review (Demo) and Retrospective. The cycle then repeats the next business day. The default duration of an Iteration is 2 weeks, and once that duration is set it doesn't change unless that change is planned in advance (in other words, we don't keep the Sprint open an extra week because we didn't get the work done).

• Program Increments (PI's) - medium time periods for planning and execution. PI's begin with PI Planning (Big Room Planning); have periodic cross-team syncs through the PI; have a program-wide, integrated System Demos following every Sprint, and end with a Program-wide System Demo of everything completed in the PI; and then an Inspect & Adapt workshop which is essentially a program-wide retrospective. The default duration for a PI is 10 weeks consisting of 4 regular Iterations and 1 Iteration which is dedicated to innovation and planning (IP) during which PI Planning for the next PI takes place.

It's worth noting here, because this will come into play later, that good Product Management calls for building out roadmaps of work that might be planned in the future. SAFe® recommends that no work is committed outside of this PI and that the timeframe for roadmaps gets broader the further out in time we're looking.

In SAFe® all Teams on the Agile Release Train (ART) follow the same cadence meaning that Iterations start on the same day and end on the same day. All of the Teams on the ART participate in PI Planning together, so their PI starts and ends at the same time, as well. These cadences are represented by this part of the Big Picture.

Iteration Paths in Azure DevOps

Every Work Item in ADO has two key pieces of information. One is the Area Path (which will be discussed in a future post) which is where the Work Item "lives." The other is the Iteration Path which is essentially when the Work Item "lives."

Iteration Paths, as you might guess, are designed to represent periods of time. In a Scrum environment each Sprint (SAFe® Iteration) is represented by an Iteration Path. It's worth knowing that, unlike Jira, ADO doesn't have a different default configuration for Kanban Teams versus Scrum Teams, and configuring ADO for pure Kanban Teams is beyond the scope of this post.

Here are a few key things to know about Iteration Paths in ADO:

• Iteration Paths can have date ranges associated with them

• Date ranges are optional for Iteration Paths

• There is a hierarchy to Iteration Paths, but as of June 2022 it is only really used in queries

• An Iteration Path has 1 and only 1 parent and can have many children

• A Work Item is associated with 1 and only 1 Iteration Path

• Iteration Paths should be added to a Team

• Iterations (once assigned to a Team) just automatically start and end based on the dates (unlike Jira there is no starting and ending Sprints)

• Either a parent Iteration Path or a child Iteration Path can be assigned to a Team.

Building Iteration Paths in ADO

While the Process is built at the Organizational level, Iteration Paths are configured at the Project level. You may need to expand the left hand panel to see Project settings at the bottom of the page.

Clicking on Project configuration will bring up the are for configuring Iteration Paths and Area Paths. Iteration Paths comes up first.

This is where you build the Iteration Paths for the entire Project. While it's possible to also build Iteration Paths for each individual Team, that's generally not a great idea since all Teams should be on the same cadence. The Release Train Engineer (RTE) typically ensures Iteration Paths are build, updated, and assigned, although they may trust someone else to make the actual updates in the tool

Building PI's and Sprints

One thing to know in ADO is that it doesn't do well with Iterations with overlapping dates. You can build them all you want, but the Boards, metrics, and a few key plugins may get confused or even crash if you have Iteration Paths with overlapping dates assigned in just the wrong way. So generally speaking, it's just easier to never create Iteration Paths with dates that overlap so you're unlikely to run into those weird scenarios.

With that being said, let's get started. Here's our scenario:

• PI 1 starts on June 1, 2022

• 2 week Iterations

• 10 week PI's

Click the 3 dots to the right of the Iteration Path name to edit. You cannot rename the top Iteration Path - it will always have the same name as the project (this is ensures unique top-level Iteration Paths across all Projects in your Organization which, theoretically, could be useful). You also cannot delete this Iteration Path.

For the reasons given above, there's no reason to add dates to this Iteration Path, so we're just going to leave it as is.

Now let's get rid of that first Sprint that ADO helpfully built for us. Selecting the 3 dots and then Delete gives us a warning. This matters more if you've been working in the Project for a while, so read the documentation carefully if this applies to you.

Now we can highlight the top level and click New Child. Let's call this PI 1 and leave the dates empty.

Now we can select PI 1 and create a child. You can call your Iterations whatever you want; this is the prototypical SAFe naming convention.

The nice thing is that when we create the next Iteration (either by selecting 1.1 and clicking New or by selecting PI 1 and clicking New Child) and manually select the Start date ADO automatically selects the end date based on the duration of the previous Iteration.

It doesn't take much at all to build out the first PI

Now let's build some placeholders for future PI's. To help build out roadmaps, we're going to build a few PI's and then some larger periods so we can build SAFe style Portfolio Roadmaps.

Note a few things here:

• No overlapping dates

• No unaccounted for dates (2023 H1 starts in 2022) - not a big deal and you could just end the previous PI later

• Increasing durations further out (for roadmaps)

Just before PI 2 Planning the RTE needs to make some changes. Remove the dates from PI 2 and build out the individual Iterations as a child. Again - no overlapping dates. The final result will look like this (which will be un-done for the rest of these articles).

And there you have it! Now the first few PI's and Iterations are built. Of course, on their own Iteration Paths don't do anything. They have to be associated with Teams, but that's a topic for a future post.