Azure DevOps Boards for Dynamics 365 or the Power Platform – Part 1 – STRUCTURING REQUIREMENTS

Sydney – July 2016

I’ve just entered one of the office towers in the city. I am meeting with my new client’s Product Owner and the Lead Business Analyst to discuss requirements that they have envisioned for their Dynamics 365 implementation.

Katie, the Product Owner, greets me at the reception and walks me to our meeting room. It’s a sunny day and the views of the city are stunning from Level 27 of the office tower.

While we wait for Jessy, the Lead BA, to join us, Katie opens the requirements spreadsheet. It feels like the spreadsheet is loading forever. After some time, Excel freezes.

Katie closes Excel and reloads the sheet. “It happens all the time lately and it’s getting worse as people keep on updating the sheet”.

The sheet finally opens, and my fears are confirmed. The sheet has 20+ columns and the list of requirements appears to be endless.

“Ok, let’s start”, Katie says with a smile.

As we go over each requirement, I notice that multiple columns are used to gather comments from the different departments. The filters on some of the columns have duplicate or blank values and Katie struggles to filter requirements by priority or readiness.

Different colours and formats are used everywhere and when I ask what the colours mean, Katie smiles and replies “I am using yellow when I need to confirm a requirement or an assumption, as for the green, purple and blue, I have no idea”.

After a long 3 hours of reviewing the list, I ask if I can suggest a more efficient way of managing requirements based on my experience. After the struggle we had, both Katie and Jessy are eager to find a better way.

I proceed by showing them how I typically structure requirements as Epics, Features and User Stories in Azure DevOps Boards. Once they get the concept, the relief is palpable (not the least on my side!) and working on the requirements goes relatively smoothly from there on out. I can only imagine the train wreck we would have had if we’d kept working with that excel.

Since reviewing/gathering initial requirements is something you do in the beginning stages of a project, you have an opportunity early on to set your project up for success and build trust with your customer.

Below I’ll share the structure I recommend and how I map the requirements to that structure.

Product Backlog in Azure DevOps Boards

Whether you are involved in the initial requirement gathering with your client or if you get a list of requirements from them, you will need to create an initial “Product Backlog” so that you can have a starting point and better track what is being delivered over time.

To create the initial Product Backlog, I personally use Azure DevOps Boards.

Azure DevOps Boards let you plan, track, and discuss requirements across teams.
The Product Backlog consists of a list of work items where you can share information, collaborate with team members, track dependencies and organize work.

Requirements or user stories gathered by analysts can be created as work items manually or via Azure DevOps’s team integration with Excel or Microsoft Project. Product owners or stakeholders are able to state the priority of items and the order in which they wish for them to be developed.

What is Azure DevOps and can it help with user adoption?
Tricia Sinclair – Customer Service Lead – Europe at Avanade and Microsoft Business Applications MVP.

There are many ways to capture and manage requirements using Azure DevOps Boards. Each client and project have different requirements and stakeholders, so we need to remain flexible and adapt how we work with Azure DevOps Boards to meet the project specifics. However, when I have the chance to start a new project where I can advise my client how to structure the Product Backlog, this is how I typically do it.

Where do we start? – Create your Azure DevOps project

1. Create your project in Azure DevOps account

If you have never used Azure DevOps before, you can sign up for a new account: Azure DevOps Services | Microsoft Azure.

After you have created your account you will need to create your first project.

You must be a member of the Project Collection Administrators group or have the Create new projects permission set to Allow. If you’re the Organization Owner, you’re automatically added to the Project Collection Administrators group. If you aren’t a member, get added now.

For more information, see Create a project in Azure DevOps.

2. Configure your Azure DevOps project

After your project is created, make sure that you are using the Agile or SCRUM process. By default, Azure DevOps will create your project using the Basic process which I find to be too lightweight for a Dynamics 365 or Power Platform project implementation.

Most businesses have a standard process they already adhere to. Whether it be a clearly defined and well known methodology e.g waterfall or scrum, a hybrid (e.g for lack of a better term “wagile”) or a custom methodology that their consultants or project team are familiar with.

Azure DevOps Processes: Part 1
Tricia Sinclair

To check that you are using the correct process:

1. Click on the Azure DevOps logo in the top left corner.

2. Then click on Organization settings.

3. Then click on Boards 🡪 Process.

4. Then under the Team projects column, click on the number.

5. Then click on the … next to your project name and click on Change process.

6. Select the Agile, Scrum or CMMI depending on your preference. I usually use the Agile process unless my client is familiar with Scrum.

More details about the different processes available in Azure DevOps Boards.

• Tricia Sinclair’s blog posts about the Azure DevOps Processes: Part 1
• How to Change process from Basic to Agile – Azure Boards | Microsoft Docs
• All the existing processes available to use – Choose a process like Basic, Agile, Scrum, or CMMI – Azure Boards | Microsoft Docs

Understanding the Product Backlog structure

Once you have your project created, you can start creating you Product Backlog structure.

However, before doing so, let me explain how I usually structure my Product Backlog. For the purpose of this article, I am describing how I use the Agile process, however, the same tips apply if you were to use the Scrum or the CMMI processes.

The below diagram represents the item types and their relationships that I use to structure my Product Backlog.

A typical product backlog would look like the example below. In this scenario, we have a fictitious Product Backlog for a university that wants to implement Dynamics 365 Customer Service to manage student enquiries.

Creating your initial Product Backlog structure

Now that we understand the structure, we need some high-level requirements to get started.

If you don’t have high level requirements

If you don’t have requirements at all, you can use the “Value Stream Mapping” to start building them. Refer to my article about how to use Value Stream Mapping – For your Dynamics 365 or Power Platform project.

When using the Value Stream, use the value stream steps as your Epics as shown in the diagram below.

When you are done with the Epics, you can use the output of the “How” to help generate our list of Features.

Creating User stories and Tasks is out of scope of this article and we will cover those topics in a later article.

If you get a list of requirements from your client

If your client provides you an initial list of requirements, you will need to map and translate them into something that Azure DevOps Boards can work with.

Try to map your Epics by understanding the high-level business process that your client is trying to solve using Dynamics 365.

As for the feature, I usually read the requirements and try to group them into Dynamics 365 or Power Platform functionalities.

See the example below where I use the categories provided by the client as Epics and then group the requirements into features that map into Dynamics 365 or Power Platform capabilities.

Other tips when creating your Product Backlog structure in Azure DevOps Boards

Use a logical ID to refer your Epics.

If an Epic is called Student self-service I would give it a logical ID like E01 Student self-service. I find this helpful when discussing the Epic or giving a status update. Ex: You can then say “The analysis of the complex requirements of Epic E01 needs to be pushed to the following iteration.”

Connect the WIKI to your Epics or Features.

I tend to connect to a wiki which has an overview of what we’re looking to build and where more info can be found. It helps testers and devs to validate their understanding as they estimate and build features.
Requirements can also have the same location store in the WIKI which helps streamlining the alignment.

Tricia Sinclair

Add custom fields to your Epics or Features.

I usually add a new custom field called URL to Documentation to my Epics and Features. See the documentation on how to add new fields.

The field allows me to store a URL to a SharePoint folder where I can store all the relevant files regarding the Epic or the Feature. I personally don’t like to attach documents directly into Azure DevOps items as you don’t get the same collaborative and versioning features that SharePoint provides. For example, you can’t have multiple people working and editing the same document and you will need to re-upload each version as separate attachments.

However, the downside of above approach:

Attaching documents directly into Azure DevOps is useful to allow customers to attach documents that will support the epic or work item as it will be traceable and accessible to everyone.

Tricia Sinclair

Change columns on your “Backlog”

When working with the Product Backlog, I usually add a few more files like the Effort and the Business Value. However, you can add any fields you like as long as those fields are part of the Epic or the Feature items.

More info on how to change column options.

What’s next

I hope that you enjoyed this article as much as I enjoyed writing it. I initially intended to have 1 or 2 articles related to Azure DevOps Boards but as I was writing, I realized how much more dept and detail could be covered related this subject. I now have decided to split the article into a series of articles.

Below are some other topics I am planning to cover in future articles about how best to use Azure DevOps Boards for your Dynamics 365 or Power Platform projects.

Articles related to this serie:

• Azure DevOps Boards for your Dynamics 365 or Power Platform project – Part 1 – STRUCTURING REQUIREMENTS (This article)
• Azure DevOps Boards for your Dynamics 365 or Power Platform project – Part 2 – CAPTURING REQUIREMENTS
• Azure DevOps Boards for your Dynamics 365 or Power Platform project – Part 3 – REQUIREMENTS LIFE CYCLE

Let me know in the comment section below if there are any other topics, related to Azure DevOps Boards, that you would like me to write on.

If you would like to get notified when I publish a new article about Azure DevOps Boards, subscribe to my mailing list here.