This is an experiment I’m currently running I’d like to share with you.
You are running a successful Power Platform project in Azure DevOps. Manage your requirements, source code, and deployments using this marvellous tool. You are tracking everything from Epics, User Stories, and Tasks to Builds and Releases. You are already aware of the fantastic traceability features of the platform and how easy it is to relate one Work Item to another.
When the developers commit their code to the repository, they include the Task or Bug id in their commit message, so you know the relationship between Changesets, Tasks, and User Stories, and every time you run a Release, you know exactly what is being deployed.
So, why not try and take it to the next level?
What if you could link any Azure DevOps Work Item to a Table, a Web Resource, or a Canvas App?
What if you could check how many User Stories are impacting a Table?
What if any developer could easily navigate and check the User Stories behind a Power Automate flow?
What if you could know how much time your dev team spends working on that buggy plugin that nobody knows what’s doing?
Well, I think there is a way to do it. Let’s check it out.
Adding a new Work Item Type
If you use Azure DevOps frequently, you are probably aware of the capability of adding new Work Item types.
There are a few Work Items, with their own fields, that come out of the box, but you can extend and create new ones by customizing what is called the Process Template.
Let’s create a new Work Item type called Solution Component. The Solution Component will keep track of every component we have in a Power Platform solution. This Work Item type will store the name, the component type and its id.
To create a new Work Item Type in Azure DevOps follow the steps below:
1. Open any existing Work Item, for example, a User Story. Click on the Actions button and then on the Customize option presented.
2. Every project is based on a Process Template shown at the top of this screen. Click on its name to see a full list of all the Work Item types defined on it.
3. Find the New work item type option located at the top and click on it.
4. Give the new Work Item type a name, Solution Component in this case, then a description, and chose an icon and a colour. Then click on Create.
5. You can add as many fields as you want to this screen, but to keep it simple we will add only two. To do so, click on the New field button.
6. Give the new field a Name, a Type and a Description. Repeat this step twice, once for the Component ID and another for the Solution field.
Every Work Item type is created with a few common fields by default. The name is one of them, so no need to add this field.
7. When you have the fields created, you can position them on the form wherever you prefer.
8. That’s it! Let’s test our new Work Item, and see what it looks like.
To do so, go back to your project and navigate to the Work Items section on the main menu. From there, click on the New Work Item option in the ribbon. You should see the new Solution Component Work Item type we have just created.
9. Give this new Solution Component a Name, a solution and an ID and then save it.
Ideally, to make the linking simpler, you should be using a pattern in the name, for example, [Solution] – [Component Type] – [Component Name]
10. Last but not least, if you want quick access to the full list of existing Solution Components, I recommend creating a query for it.
Work Item Links
That wasn’t too difficult, was it?
But, how do I use it?
In the introduction, we mentioned how good it would be to be able to link our requirements to the assets we produce in our Power Platform projects.
We can do it by using the Links feature available in the Azure DevOps.
From any existing Work Item, I can create a relationship to any other Work Item, Commit, Pull Request, Wiki Page, Test Case or Test Result.
And this is where the real power relies because once I have my Solution Components and I have them linked, I could create queries to extract meaningful information that would allow me to see, for example, the rollup of hours on tasks related to a Solution Component, or the requirements associated to it.
Let’s see an example:
1. If I open any Work Item, for example, a task, I have a tab available called Links. From the links tab, I can add new links.
2. In the dialogue I can now specify the Link Type and the related Work Item. Link Type Related is probably good enough for most cases.
Regarding the Work Items to link, if you follow the naming structure proposed earlier, it will be easy to find things by name.
You only need to start typing the solution name, then the component type and finally the first words of the desired element.
3. When you finish, the new link created will appear on both sides, the Task, in this case, displaying all the related Power Platform components, but also on the Solution Component side, showing all the related Tasks, User Stories, Builds, etc.
You can even tag these items in the Discussions section or the description, to facilitate communication and navigation.
Conclusion
As with my previous posts, I wanted to present the description of an idea that I am currently playing with.
The problems I’m trying to solve with this idea are mainly traceability and estimation.
I believe that as consultants, in our projects we generate a lot of data, but very rarely use it to retrofit future projects and make data-driven decisions.
In the next post, I am planning to show you how to take this a step further, and use a PowerShell script to automatically maintain the Azure DevOps Solution Components using the information available in the source control repository.
I hope you find this article useful. If you have any comments or queries, please leave them below.