SAFe® in Azure DevOps - The ART
This is part of a series on configuring Azure DevOps for SAFe®. At this point we've looked at Project and Process, Iteration Paths, Area Paths, and Teams and Boards. Now we move on to SAFe®'s Teams of Teams concept of an Agile Release Train.
Building the ART Team and Assign Iteration Paths
The primary way to create Boards and Dashboards as well as to gather metrics in ADO is by creating Teams. In short, any time you want a Kanban Board in ADO you need to build a Team. (OK, there is a plugin that allows you to build Boards from Queries, but that's not a great solution.) So it's not unusual to have a number of "Teams" in ADO that aren't really Agile teams at all, but there shouldn't be any confusion at all with ARTs since they're just teams of teams to begin with. It's important to know that an Area Path can be assigned to multiple Teams or to no Teams at all. Anyway, let's build an ART!
Building and configuring an ART is just like building and configuring a Team, so read that post for a little more detail.
Create a new Team called which we'll call ART1. Again, do not allow automatically create an Area Path.
Assign the Iteration Paths just like they're assigned for the individual Teams, including each of the Sprints.
Assigning Area Paths to the ART
This is where things get a little different. If you recall the advanced configuration when configuring Teams you recall that you can select one or more Area Paths including or not the Sub-Area Paths. We are going to use that same technique now with the same decisions to consider.
First, select the ART1 Area Path to be the Backlog Area Path. Then you have a couple of options.
Option 1 - the easy way, using Sub-Area Paths
The good thing about this approach is that it's really simple, assuming you build the Area Paths as recommended. Simply select Include sub areas.
The plus side of this approach is that if you add every new Team underneath the ART Area Path, then they are automatically added to the ART.
The downside of this is that you now include every sub-area path. So if a team wants to hide Work Items in a Sub-Area Path, then those would be included.
Option 2 - manually assign each Area Path
This option takes a little more time to set up initially, and you have to remember to update the ART when adding new Teams. This is also the option to choose if you choose to build your Area Paths differently from our recommendation.
In this configuration we have added the Area Paths for both Teams, and since we know that we want to include the Sub-Area Paths for TeamA we included sub-areas.
ART Backlog Levels
Update the Backlog levels. If your organization has a real LPM group, then they may manage the Portfolio Epics, but in this case the ART is going to manage those.
The ART Boards
Now you can access the ART1 Board and see all of the Work Items from all of the Teams on the ART.
More importantly, though, is the Backlog view
In the Backlog page go to Column Options and add a rollup column based on Work Item progress.
This setting allows this view.
Which means that at any time you can see percent complete of known scope. (Always keep that in mind in an Agile world. The scope could change at any time, but this is still a useful bit of data to have.)
And check out the view at an Epic level!
Agile Gantt Charts
OK, that title probably just scared some people. Perhaps you should think about it as Roadmaps.
The Delivery Plans module in ADO offers some nice functionality.
Delivery Plans Option 1
There are a couple of options for configuring Delivery Plans. The first is purely at an ART level.
Here we are only looking at Features, although you could certainly select Epics as well.
Option 1 shows ALL Features for the ART in one view.
Delivery Plans Option 2
You could choose to select each Team individually.
This looks more like a Program Board.
Key Information for Delivery Plans
Regardless of how Delivery Plans are configured, here are a few key things to know for a Feature (or other Work Item) to appear or be modified in the Delivery Plan:
The Work Item Level must be selected. If you want Stories, then the Story Backlog must be selected
The Work Item's Area Path must be assigned to the Team that's selected
The Work Item's Iteration Path must have dates on it. In our scenario, anything assigned to either the default Iteration Path or to PI1 would not appear
By default the Iteration Path marks the end of the delivery
You can modify the start and target (projected completion) dates in the Feature itself or by grabbing the ends of the Work Item and dragging
And you can add dependencies and have them appear (although they don't all appear at once like an ideal Program Board)
Conclusion
So there you have it - a fully functioning ART in Azure DevOps Boards!
Comments