How to use Azure DevOps with SAFe - Part 3 (Projects)

A project provides a repository for source code and a place for a group of people to plan, track progress, and collaborate on building software solutions. It represents a fundamental container where data is stored when added to Azure DevOps.

When you connect to Azure DevOps, you connect to an organization or project collection. Within that container, one or more projects may be defined. At a minimum, at least one project must be created in order to use the system.

Lets start by creating a new Project under our Organization using the SAFe process template that we created.

Make sure that you choose the wokr item process as SAFe. Click on the Create project button to create the new Azure DevOps project

Once the project is created you can navigate to the project to see the services, like Boards, Repos, Pipelines etc.

The project settings menu can be accessed from bottom of the left menu on the project page.

Adding Teams

When you create your project, a team of the same name is automatically created. For small teams, this is sufficient. However, for enterprise-level organizations, it may be necessary to scale up, to create additional teams. New Teams can be created by choosing Teams menu item from the project settings page.

• Click on New Team to add a team

• Choose a name for the team and add Team members for that team (the members are available from the users list in the Organization)

• Make sure that you uncheck the 'Create an area path with the name of the team' option when creating a new team. We'll define the area paths and team associations later when we move into Team Configuration.

You'll be creating the portfolio, program and feature teams from page.

The portfolio team is the default top level team and is responsible for controlling the portfolio that consists of strategy determination and financing of investments, Agile portfolio execution and Lean Governance. This team is responsible for initiating a set of development value streams (Epics).

The program level contains the roles, activities and processes for a group of Agile teams to continuously deliver solutions via the Agile Release Train (ART). The Features are created and managed at this level.

The feature teams work on user stories at the Sprint level and focuses on delivery of Customer value in the context of the ART.

Define team area paths

To support the team hierarchy, the next step is to configure Area Paths in Project configuration.

From the Project Settings page, choose Project configuration and then Areas. You'll see that this has only one item with the default team name. We'll now define the team hierarchy with Portfolio team area on the top and then Program and Feature teams.

Now navigate to the Team configuration from the project settings to select the areas for each team. From the team name drop down select a team and then set the default area for that team. You can select multiple areas other than the default team area for the team to work on as given below. Make sure that for the Portfolio and Program teams the include sub areas option is not selected.

When finished, your area path structure should appear similar to that shown in the following image.

Define iteration paths

Iterations are used to track the team's progress towards Releases. Iterations are the basic building block of Agile development. Each iteration is a standard, fixed-length timebox, where Agile Teams deliver incremental value in the form of working, tested software and systems.

Unlike area paths, multiple teams can share the same iteration path structure. Sharing the iteration structure lets multiple teams work in the same sprint cadence towards the same release trains. You'll want to create an iteration structure that supports your entire team structure, not just one team.

• From the Project Settings page, choose Project configuration and then Iterations.

• Under the default iteration, create child iterations that will represent your Program Increments (PIs). Add a start and end date for the PI.

• Create a child iteration for each Sprint within the PI. Set dates for these sprints to correspond your Agile teams' cadences.

• When finished, you should have a structure similar to the image.

Team Configuration

Now that your teams, Area Paths, and Iteration Paths are defined, the next step is to configure each team. You'll want to configure the following settings for each team.

• Active backlogs - Setup which backlog levels the team mananges (for e.g Epics for portfolio team, Features & Epics for program teams etc.

• Working with bugs - Whether the team needs to manage bugs as part of the backlog or not (Only feature teams need to have the option Bugs are managed with requirements selected. For portfolio and program teams Bugs are not managed on backlogs)

• Default Iteration Path - New workitems that are created from the team backlog are assigned to which iteration. The default value is @CurrentIteration

• Backlog Iteration - Workitems assigned to these iterations only appear on the teams backlog. (For e.g. Portfolio and Program teams work on PI levels and Feature teams have iteration paths with Sprints & PIs)

Next we'll see how to make use of the Azure boards and backlogs to create Epics, Features and User Stories and how to make use of Boards, Queries and Plans to track the progress of the Agile teams.