SAFe® in Azure DevOps - Area Paths

The next in the series on configuring Azure DevOps for SAFe®. This time we're going to look at Area Paths.

At this point we've set up the Process and the Iteration Paths for our initial PI. Up to this point things things have been fairly straightforward, but now you have some options, and each makes some things more difficult and others more complex. The primary path here both makes it a little simpler to configure a single ART and sets things up in case you need additional ARTs alongside or some teams that are outside of that ART. But there's not really any "right" or "wrong" way to model ARTs in ADO.

As a reminder, Agile Release Train (ART or Train for short) is SAFe®'s term for a Team of Agile Teams which form the Development Value Stream. A particular challenge in an ART is coming up with a good way to see all of the work on the ART and understanding status at a high level. Azure DevOps can be configured to do exactly that.

Introduction to Area Paths

Area Paths are very similar to folder in Windows (or any other directory tree). Every Work Item "lives" in an Area Path. Like we said in the previous article, the Area Path is where the Work Item lives while the Iteration Path is when it lives. Every Area Path has 1 and only 1 parent, and an Area Path may or may not have children (or grandchildren). A Team in ADO (which will be the topic of a future post) is associated with one or more Area Paths.

One thing to know is that the parent-child relationship between Work Items is separate from the parent-child relationship between Area Paths. This becomes important fairly quickly. Imagine a very simple ART that consists of 2 Teams called Team A and Team B. During PI Planning Team A may agree to take primary responsibility for delivering Important Feature, but Team B may need to complete a couple of User Stories as well. ADO allows Important Feature and most of its Stories to live in Team A's Area Path while also allowing a few child Stories to live in Team B.

Area Paths can be used for a wide variety of purposes besides serving as the place for items in the Team Backlog to live, but that's beyond the scope of this introductory post. Let's just say that people can get very creative with their Area Path configuration!

Creating Area Paths for Teams

When creating a Team (which will be covered in a future post), ADO can automatically create an Area Path for that Team. There's nothing wrong with that approach, but setting up the ART requires a few additional steps which might make a bit more sense after learning this approach. So we're going to do things the slightly more difficult way.

The more manual approach to creating Area Paths is to go to Project Settings / Project Configuration / Area Paths.

This is where you manage and manually create Area Paths. As with Iteration Paths, the top Area Path has the same name as the Project. There's nothing you can or should do about that.

In our example we're going to build a really simple ART that consists of 2 Teams. We'll creatively call the Train ART1 and the Teams TeamA and TeamB. In the real world please listen to your Agile Coach and come up with fun and creative names! The reason we're calling it ART1 is because a time may come when the ART grows to the point that it should split or another group is incorporated leading to ART2.

So let's build the Area Paths for the ART and its Teams. Start by selecting the top Area Path and then click New Child. This gives you the chance to come up with a name. After you Save and close the child appears.

When getting started don't waste too much time thinking about the name. It's relatively simple to change it later if you don't like it. The one thing to know is that if you've set up an integration between ADO and other tools (like ServiceNow) then that integration is probably tied to an Area Path using the name, so watch for that.

It's now relatively simple to click on the 3 dots by ART1 and click New Child to create a Sub-Area Path for TeamA.

Repeat the process to create TeamB and now you have the Area Paths for your ART and Teams.

Advanced Area Path Creation

So far we have equated an Area Path with a Team. And that will be obvious in another post. But there are times where Sub-Area Paths underneath the Team can be helpful. Because of the way that ADO Boards work, sometimes it's helpful to build Sub-Area Paths for simple filtering. Other times it's useful for metric tracking.

Let's say that TeamA's responsibility is to build CoolSolution. Normally speaking they have Features and Stories for building new functionality in CoolSolution, and those are managed well during the Sprint Planning cycle. But they're also responsible for Level 3 tech support when the Help Desk and Triage Team just can't figure things out. The tickets that come in are urgent and override the Stories which are planned for the Sprint, and the Team needs to both quickly see them and to be able to get some metrics on them. One option is to mark those tickets in a special way using either a Tag or a Custom Field (which would be configured in the Process). But Tags are always a mess, and the Process may be centrally managed and outside of the Project Administrator's control. Sub-Area Path to the rescue!

We can create a Sub-Area Path under TeamA in the same way we created TeamA itself. One configuration option when we build the Team in ADO makes this very useful!

Other Considerations with Area Paths

There are many other ways to use Area Paths in ADO. There are also plenty of other schemes for how they are organized. This approach is definitely not the only option.

For example, there are plenty of places that use Essential SAFe® and still have traditional projects. Some people use Area Paths to manage those projects. Some people even create a Sub-Area Path under each Team for that specific project work. The one thing to watch for there is that at some point the number of Area Paths and Sub-Area Paths can become huge. ADO won't have problems with that many paths, but the users might get lost in the system!

Conclusion

We're getting close to having actual Boards. And, yes, to some extent doing things this way is optional. But hopefully it helps to connect the dots for the next post on building out the Teams themselves!