SAFe® in Azure DevOps - Risks and PI Objectives

This is the last in the series on one approach to configuring Azure DevOps for SAFe®. So far we've covered:

• Project and Process

• Iteration Paths

• Area Paths

• Teams and Boards

• The ART and Program Board

This final step is optional, but it provides a way to track Risks and PI Objectives. It's going to use a little bit of everything that's been learned so far, and some of the more detailed instructions can be found in those earlier posts.

We're going to add something SAFe® doesn't explicitly call for in the form of Impediments (blockers). By default ADO has a Work Item type called Issue, but that word could have multiple definitions, so we're going to go with the less confusing Impediment instead. Risks that materialize should either converted into Impediments or linked to a new Impediment, depending on how your RTE likes to run things.

Speaking of things that SAFe® doesn't talk about, we're going to put all of these things on Kanban boards. Huh? Risks on a Kanban board? PI Objectives on a Kanban? Granted, it may seem a little different at first, but why not give it a try? It sure beats yet another Risk Register in Excel that no one ever looks at.

Coaching tip - Risks, Impediments and PI Objectives in Syncs and System Demos

One nice thing about having everything in a single tool is that it simplifies review. It can now become natural to review Risks in every Scrum of Scrums or ART sync - it's easy to flip from the Feature Kanban to the Risks Kanban. And while by the book SAFe® says to review and score PI Objectives during the Program System Demo as a part of the I&A workshop, we're finding that Business Owners appreciate the opportunity to review them throughout the PI rather than attempting to remember their thoughts several weeks later.

Adding Risks and Objectives to the Process

The first step is to go back to the Process and add Risks, Impediments, and Objectives. You can modify the States however you see fit, but generally speaking the default of New / Active / Closed is good enough.

Let's start with Risk.

SAFe® calls for ROAMing Risks, so we're going to go to the Layout tab and Add a field

We'll call the field ROAM and make it a Type of Picklist (string) and then enter the values.

Our experience has also shown that it's a good idea to be able to differentiate between a Program Risk and a non-Program (as in, a Team specific) risk. A second custom field works for this.

If you want to add additional fields to give a sense of probability and impact, there's nothing wrong with that. It's up to you whether those are Integers, Picklist (integers), or Picklist (strings). Each has its own benefits and potential uses.

Now let's create an Impediment following the same steps. Impediments usually have an impact, so let's add a field for that. Since ADO already has a Priority field, we can re-use an existing field.

Impediments can happen at all levels like Risks, so let's re-use the field from Risk. (In retrospect, it might have been better to create the field as "Program Level" or similar.)

Finally we can create PI Objective. This time we're going to re-use Start Date and Target Date, just in case people want to use those.

We're also going to create 2 new fields: Planned Business Value and Actual Business Value. Make them Picklist (integer) fields and enter values 0-10.

Since SAFe® differentiates between Committed and Uncommitted (formerly Stretch) Objectives, make a Boolean field for Uncommitted.

Now we create 2 new Backlog levels, one for Risks & Impediments and another for PI Objectives. This will allow us to show them on their own Kanban boards.

Building the Kanban Boards

The good news when it comes to Boards is that they're essentially already built. They just need to be enabled for each team. This brings up another decision: in what Area and Iteration Paths should these Work Items live? Since we created a custom Program Risk field, it makes sense for Risks to live in the default Area Path for the team that raised the Risk or Impediment. The Iteration Path can be any Iteration in the PI; there's nothing wrong with it being the last Sprint unless there's a reason to think it will materialize sooner. The Iteration Path for the PI Objective can be the Iteration when the Objective is expected to be met.

To add the Backlog level go to Boards; select the appropriate Team; then click the configuration wheel. Selecting Backlogs shows that you now have new options.

And now there are new levels to choose from in the upper right hand corner.

This has to be done for each Team and the ART. We also configured the ART board with a Style so the Program level items pop out. Some people might prefer a different color coding scheme to indicate ROAM.

Which means that it's now very easy to review Risks and Impediments during the syncs.

Similarly, look at these PI Objectives from the different teams! And if the RTE wants to create aggregate PI Objectives for the entire ART, they can easily do so and have them live in the ART Area Path.

And to take things a step further, Teams can link Objectives to Features if they want!

So there you have it. Azure DevOps is a fantastic Agile Lifecycle Management tool. It can be used to manage work for Teams while allowing the RTE and Product Managers to quickly manage scope, progress, risk, and objectives. And while it took several articles to cover configuration, it really doesn't take that long to have a fully formed and functional ART represented in ADO.