Azure DevOps Tutorial:
An Introduction to Requirements in Azure DevOps

Everything you need to start requirements work in ADO

If you have recently decided to move your Requirements Management team to Microsoft’s industry-leading Azure DevOps then congratulations! 

You have just made the decision to bring your team into the only single-source of truth models that exists for requirements management. You’ve signed up for a world where Developers, Requirements Management, and Quality Assurance Teams all working and collaborating in the same space!

With over 150 million users, Azure DevOps already supports many teams who are using Microsoft’s industry leading ALM platform to host Code Repositories, or Test Plans. But to move your Requirements Management Team into Azure DevOps alongside these existing teams can take a little planning. 

In this article I will cover how your Requirements Management team can get started working in Azure DevOps faster than ever before. 

These are the topics we will be covering:

  • What is a Process Template? 
  • Setting up a Process Template
  • How much customize-ability is there in Azure DevOps?
  • How do you Manage requirements as your project progresses?
  • How do you add and interact with Requirements you create in Azure DevOps?
  • How do Developers interact with your Requirements?
  • Is it possible to facilitate Reviews in native Azure DevOps?
  • What else can Azure DevOps do? 

As we go through this article, there will plenty of Azure DevOps tutorial videos provided for you to follow along and get started with Azure DevOps quickly! 

So get a coffee, grab a free Azure DevOps account, and take the first step to enjoying projects with a single-source of truth.

What is a Process Template?

The first step to understanding Azure DevOps is to recognize and discuss this thing called the
Process Template

Is a Process Template difficult to grasp?

Not really. 

Think about the names your team currently gives to requirements. 

If you are an Agile shop, your team likely recognizes requirements as Epics > Features > User Stories. 
If your team follows SCRUM, then you may be more familiar with Epics > Features > Product Backlog Items.
For Waterfall & Compliance teams, you are likely used to the lowest level requirements being called Functional & Non-Functional Requirements. 

So what is a Process Template?
It is what Azure DevOps uses to define your requirements at each level.

If your team wants to use an Agile Process template, that’s perfectly doable. Simply add that your Backlog should contain Epics as the top level, Features in the level underneath, and User Stories underneath that. 

But what if you want custom properties?
That’s easily done by customizing your Process Template too!

You can add whatever customizations to your project that you want and it is really not that hard. 
See the video below for setting up a custom Azure DevOps Process Template. 

Setting up a Process Template

Setting up a Process Template allows your team to take full control of the Requirements / Work Items in your project. You can alter the Properties of Work Items and even add Rules and Custom Triggers. 

 

Can I customize my Azure DevOps project?

Absolutely. 

The power of using Azure DevOps for Requirements Management comes from the concept of being flexible to a fault. 
Any and every team that handles requirements can use Azure DevOps to do so. Does it always work straight out of the box? No it doesn’t always, but that doesn’t mean it can’t.

For many Azure teams the basic Process Templates provided by Azure DevOps will allow theme to accomplish their entire Requirements Workflow without needing to make custom changes. 

But every team has their knacks and some may want Azure DevOps to support them – I’m looking at you folks who use Rejection Criteria over Acceptance Criteria. 

Yes, you. 

The good news is that your project can be customized as heavily as needed by editing your Process Template. But, you should always gather your team together before doing so and nail down exactly what your process looks like, and how it should be reflected in Azure DevOps. 

Quick Aside (shameless plug incoming): 
Azure DevOps also has a tonne of addins that can change your interactions with your project heavily. 
One such addin is our Modern Requirements4DevOps solution which turns your Azure DevOps project into a complete Requirements Management Platform. Our tool brings all of the assets you already make outside of Azure DevOps, into your project. I’m talking Documents, Diagrams, Trace Matrices, Reviews and Approvals (with e-signatures), Baselines and more.

Check us out if you’re interested!

 

Adding and Interacting with Requirements in Azure DevOps.

In my time as a Solutions Consultant for Modern Requirements4DevOps, I recognized that many teams wanted me to answer one question before discussing anything else. 

How do I add Requirements, and then how do I interact with them? 

My response – “Great question!”
Microsoft’s Azure DevOps allows you to create and connect with your requirements in a few different ways. 

After you have setup your Azure DevOps Process Template, you are ready to add requirements into a project you create. The typical place to add requirements in native Azure DevOps is the Backlog View. 

The Backlog supports the ability to create requirements at different levels of the hierarchy. 

The Azure DevOps Backlog

Click the image to the right to see how a fully filled out Backlog looks in Azure DevOps. 

(click to expand image)

When you built your Process Template you were able to choose how your Backlog is Structured (seen below).

By creating the structure of your Backlog, you are effectively creating how your requirements will decompose in the Backlog. In the Agile example above, the requirements are structured as:

Epic > Feature > User Story

This means that we can view and visit three tiers of the Backlog. 
We can view our requirements from the highest level by selecting the Epic level in the dropdown on the top right. We could also choose to see our lowest level requirements, which might be helpful when moving requirements into an iteration, by visiting our lowest level requirements (in this case User Story from the same dropdown).

At each level you are able to create a new Work Item by clicking the aptly named “New Work Item” button above the list of requirements. 

If you create your top-level requirements, you are then able to breakdown that requirement into it’s “sub requirements.” You do so by selecting the “+” button beside your newly created requirement.

Adding Requirements (Video)

Click the video to the right to see how you can easily add and interact with requirements that you create directly within the Azure DevOps Backlog. 

 

Now that we can see that creating requirements is simple, I should point out that the operation of adding requirements to Azure DevOps can be performed from the Backlog, Queries, or Sprints tabs of the left. This means that you can compose new requirements and break them down into their sub-requirements quickly and easily. 

How do Developers interact with Requirements in Azure DevOps?

The best part of using Azure DevOps as a Requirements Management Solution is that it provides a single-source of truth for your developers, requirements team, and quality assurance. 

But knowing how your developers can connect with your requirements is the first step. 

In Azure DevOps your developers can build Task Work Items which can be connected directly to their development work. If they are using the “Repos” functionality of Azure DevOps, they can add their Github or TFVC repository to their project to make it easily accessible. They can then tie their pushes, pulls, branches, commits, and more to their Task Work Items (or any other Work Item!).

As teams tie their development work into part of the process, they can make their development more visible and traceable to requirements themselves. 

But. 

Development work is usually initiated by a “thing” that must get done. 
That “thing” is a requirement that developers will interact with from Sprints/Iterations tab of Azure DevOps. 

Developers will visit the current iteration, find out what needs to get done (requirement) and turn it into how it is going to get done (task). In the below video I describe exactly how this process looks.
I have also included a quick video on setting up Dashboards and Sprints in case you are interested! 

Setting up Dashboards & Sprints

Setting up Dashboards and Sprints is a good starting point when handling requirements in Azure DevOps. This allows both Requirements teams and development team the chance to get started. 

 

How Devs Interact with Requirements

This video outlines how your developers can easily interact with project requirements and break them down into the associated tasks.

 

Can I do Reviews/Approvals in native Azure DevOps?

Teams often need a method of reviewing requirements to see what changes need to be made.
Often teams will require some sort of sign-off for the changes that have been made, or they will simply use reviews to facilitate discussion and collaboration.

In Azure DevOps, the method of facilitating changes top requirements includes emailing lists of requirements to the interested parties using the email feature within the Queries tab. While this feature does have some limitations, it does allow your team to exchange requirements and collaborate before making final change. 

Looking for better reviews?
Need compliant e-signatures?
Interested in automation tools?

When teams send requirements to internal team members, or to external Stakeholders, they are able to have documents reviewed and looked at before a change is finalized and made. To see this in action watch the quick video below:

Reviewing Requirements

In this video we cover how your team can send requirements to internal and external members of the team for review.

 

What else does Azure DevOps offer?

Azure DevOps offers plenty of functionality for both Development and Quality Assurance teams. 

When it comes to Azure DevOps however, your team may still feel like more can be done. That’s exactly why we’ve partnered closely with Microsoft and have become their go-to partner for Requirements Management tools. 

Our solution is built to offer teams using Azure DevOps the ability to do everything they need for Requirements Management within their project. We allow you to create a single-source of truth model for your team by helping your team create the assets they already use from within their Azure DevOps project!

Want to learn how your team can create: 

  • Documents, Diagrams and Question Lists from within your project?
  • End-to-end Traceability Matrices in 30 seconds or less?
  • Baselines that help you identify and manage changes to requirements?
  • and more?
Try Modern Requirements4DevOps today and experience the benefits of having one single-source of truth model for all of your teams working within the same space!
 
Time to Read: 15 minutes

Recommended Posts