I have worked with TFS, VSTS and now Azure DevOps for several years now on projects of various delivery approaches, size and setup. I often received questions about how to setup Azure DevOps for a single Scrum Team (various level of maturity) or in a multi-team environment.
So here I am with a first post around simple setup and my recommendations based on my personal experience!
Introduction
While Microsoft has added a tremendous number of new features on the ALM suite, it is pretty easy to get along with the latest version – named Azure DevOps (formerly Visual Studio Team Services).
It is now composed a full set of features to cover the Application Lifecycle Management of a software product from Product Backlog Management, Automated Builds, Deployment Pipeline, Automated Releases, Testing and more.
You can find a lot of existing material on Microsoft website:
Microsoft introduces new features on a 3-week release cycle for the online tool with lots of good features popping up in beta or release version!
Let’s get started!
Assuming that you already have a Azure DevOps account, you can create a new project and fill in the project details with within minutes you have a new Project space (or “Product space” we should really say for an Agile delivery).
For how to create a new project click here!
If you are totally new to Azure DevOps you can create a new organisation account here.
Sorry for the links, I am not going to repeat what has been already covered…
Now, the interesting part is that often the organisation account is managed by your global IT team which for compliance and security reason tends to keep things closed 
My first recommendation here is ask your internal IT team to create a new project space for you with the details you want and to add your account to the newly created project as Project Administrator!
This will allow you to configure your project space as you need and also be able to create all your repos, builds and releases in the future… and avoid countless back and forth request with your IT Team.
Project details
- Project name: <my product name>
- Visibility: Private (default)
- Version control: Git (default)
- Process Temple: Scrum (default)
Personaly, I have used the default settings on all projects I have worked on in the past couple of years and this suits me well for Scrum Teams. However, I have also helped teams using the Agile process template in a very similar way. I haven’t used CMMI for years!!!
Warning:
The “project” terminology here is a bit confusing! If you are used to work on an Agile environment, we tend to talk about Product. Here the project is a workspace to manage your Product with one Product Backlog that can be shared across multiple teams and with potentially several project initiatives in the lifetime of your Product!
Through this blog series, my aim is to give better view of how to set this up…
Boards configuration
So now, you have a brand new Azure DevOps project ready to be setup. For the purpose of the blog series I have created the ADO-Demo project as below:
Project configuration
The first step, we are going to look at the Boards configuration, so click on the Project settings on the bottom-left panel and navigate to Project configuration in the Boards section.
The Project Configuration allows to set the Iterations and Areas for your Product Backlog. You will use both fields with your Product Backlog Items (PBIs). They are directly used by the various pages to filter your backlog.
Iterations
The Iteration field defines your “delivery cycle”. By default you will get something close to this:
This is a good start, but you can also create sub-levels if you want to have releases, versions or even projects (for more hybrid-agile environment) as below:
Note that the display order is alphabetical until you set the dates of your iterations.
This is the main difference between Project and Product! You can easily manage the development projects of your Product within the same Product Backlog and Azure DevOps project space. Again, think about it as your Product timeline.
More on defining iteration paths…
Areas
The Area field is another way to categorise your Product Backlog. Each PBI has an area path that you can set. It is commonly used for features or technology layers in single team environment. For multi-team environment it allows to split the backlog for each team, but I will write another blog post on this soon…
From the Project configuration again, you can set you areas. My personal preference is to keep things simple and start with domain features like in the example below:
Note the area path is a hierarchical structure so it can be used for more complex setup if you wish.
A great alternative of areas is the use of Tags! Tags can easily complement areas as they are more flexible to set and can be still used for filtering and queries. However, they cannot be used to define your team setup… I will talk more about the Tags when looking at the backlog!
Team configuration
Alright, now that we have set the areas and iterations for the project (or product!), let’s have a look at the Team configuration.
Note that when you create a new Azure DevOps project space, a default team is automatically created with the name of the project (ADO-Demo Team in my example).
Lot is already available on the links I provided, so the important parts are:
- How do want to organise you backlog? PBIs, Features + PBIs or Epics + Features + PBIs
- How do want to work with bugs? Bugs like PBIs or like Tasks?
There is nothing black and white here, it’s a lot about your context, level of maturity of your team with Scrum and obviously your personal preferences 🙂
Warning:
Another common confusion (or topic of lengthly discussion) is the terminology used for Epics, Features and PBIs (aka backlog items). Let say another product (JIRA) has only 2: Epics and Stories, and it is sometimes difficult for people to embrace change – it is only a way to organise your backlog. Microsoft has followed the SAFe approach here! (no comment!)
Based on my personal experience starting with Features + PBIs and Bugs at the same level as the PBIs (default setup) work well for Scrum Teams. This allows to decompose user scenarios (Features) into smaller stories (PBIs) and deal with in-sprint and out-of-sprint defects in your backlog.
I have also used Epics for larger cases where we wanted to manage Product initiatives or Portfolio Management.
Iterations
Now let’s look at how to define the iterations for the team!
Since Azure DevOps backlog and board views are filtered based on the iteration and area fields, it is important to set them properly or you won’t see your backlog items
With the default configuration, all iterations are assigned to the default team. If you have changed the iterations in the Project configuration, it’s better to review the assignment in the Team configuration.
Let’s say we work on a 3 Sprint initiative, I can remove the Sprint 4 to 6 and hide them from the Team views, without physically deleting them from the Project configuration. Still following? 🙂
You can add (or re-add) additional Sprints (iterations) by clicking on Select iteration(s) as below:
Note the new addition where you can add several iterations in one go with the +Iteration button. Still a bit cumbersome, but at least we don’t do that too often 🙂
Areas
Same story with the areas, you need to assign them to your team. So, if you have added sub-areas like I did in the Project configuration, by default they are not assigned to the team which means the backlog items set with “New customer onboarding” won’t get displayed!!!
For a single team environment, the easiest is to include sub areas in the context menu or clicking on the “…”
All backlog items from all areas will get displayed going forward – hence the confirmantion message below:
You can exclude the sub area and manually assign the areas later if you wish.
Boards
Shew! The Project settings are set, we are ready to look at our Product Backlog and Kanban Board.
Workflow
Just before jumping in creating all your PBIs, have a think about your story workflow. Azure DevOps backlogs and boards use the backlog item State and Board Column fields.
By default, both State and Board Column values are the same. The terminology of the Committed state hasn’t been changed, so read it as Forecasted!
It is important to understand those few states as, again, they drive the story workflow and boards:
- New: added to the backlog, we don’t know much about it yet
- Approved: deemed valuable by the Product Owner (the Product Owner did not say “No!”) and will likely be done at some point 🙂
- Committed: forecasted by the Development Team in the current Sprint
For more on the workflow states check here…
Kanban Board
In the old TFS days, we used to fully customised the workflow states, today we tend to keep them as they are and play with the Board Column instead. It is way simpler and allows to set a story flow that fits the team on the Kanban Board.
As mentioned earlier, initially the Board Column values reflect the State values. Here is your opportunity to change the flow for the team.
The first thing I do is to rename the columns prefixed with an order number that will be handy for graphs and charts as they are alphabetically ordered.
For this, click on the “gear” on the top-right corner and navigate to Board > Columns settings:
From here, rename the columns and save the changes…
Note that you can also set your WIP Limit, split the column into “doing” and “done”, add new columns, associate the State to the Board Column and describe the “definition of done” of each column from the settings page.
In this example, I have renamed the columns as:
- 0-Backlog: new story in the backlog, we don’t know enough yet
- 1-Approved: approved by the Product Owner
- 2-In Progress: forecasted by the team in the current Sprint
- 3-Done: and done!
The 2-In Progress can be decomposed a bit as everything will be “in progress” once the team has forecasted its Sprint Backlog! So let’s add a new column for the same workflow state: Committed.
- 0-Backlog
- 1-Approved
- 2-Forecasted: forecasted by the team in the current Sprint
- 3-In Progress: the team currently working on it!
- 4-Done
Ok, that’s better!
What if we want a ready state? You can add a “ready” column once the item has been approved (with Approved state), such as:
- 0-Backlog
- 1-Approved
- 2-Ready
- 3-Forecasted: forecasted by the team in the current Sprint
- 4-In Progress: the team currently working on it!
- 5-Done
Note that you should still be opened to add a PBI to your Sprint even if it is not “ready” as long as the team feels confident enough that they can forecast it for the Sprint!
Now, we are ready to work! 🙂
Product Backlog
After adding few Features and PBIs, we are in a position to look at our Product Backlog.
The latest UI looks “disturbingly” similar to JIRA with the Planning panel on the right! But once we get use to it, the new look & feel makes it pretty easy to forecast the Sprint and move the items around.
There are still few things we can change to make it easier to work with.
First, let’s review the Column options by clicking on the “…“.
My recommendation is swap the State for the Board Column which will provide a better view of our new flow set on the Kanban Board. If you have added sub areas, it would be also useful to add the Area Path column. Finally, I tend to keep the Value Area (“Business” and “Architectural”) to potentially highlight architecture, infrastructure, NFRs type of PBIs that could end up in the backlog.
Same idea in the Kanban Board, you can add fields to the PBI cards in the Settings.
Another super handy feature on the Backlog is to turn on the Forecasting in the View options in the top-right corner which allows to forecast your future sprints (and release plan) without having to assign the PBIs to a Sprint in advance!
It gives a great view to the Product Owner and everybody else about the state and progress of the Product delivery at any time.
johonline's blog 
1 thought on “Starting Product Backlog Management with Azure DevOps (formerly VSTS)”