My last Azure DevOps post focused on the process. And if you are still stuck deciding which process to use, this post might help tip the scales. Do you need more work item types than the Basic process has to offer but Agile isn’t quite right? ADO provides a solution for this problem by allowing you to create work item types. This post will explain how to customize work item types so that you can get the most out of ADO. Read on to learn more.
Early in my ADO journey, I read this article on Medium. I thought the content was useful, so I copied and pasted some of the content into our ADO wiki for later reference, specifically this part….
Epics declare initiatives important the organizations success. They may take several teams and several sprints to accomplish, but they are not without an end. Epics have a clearly defined goal. Once attained the Epic is closed. The number of Epics in progress should be manageable, to keep your organization focused. Epics are broken down into Features. Many organisations introduce a level above Epics called Initiatives, Initiatives break down into Epics.
https://medium.com/webill/epics-features-and-user-stories-21be70d1ac17
Now, I didn’t need initiatives. I stuck to Epics, Issues, and Tasks, but a couple of months later, one of my colleagues read the wiki and decided he wanted to use Initiatives, and so I thought a post on creating custom work items made sense.
Creating Custom Work Items
How To
Work items attach to the process. Processes are configured in Organization Settings. Go to Organization Settings > Boards > Processes > Select your process. Then, you should be at the work item types screen. From here, you can create a new work item type using the button shown. But, you aren’t done yet.
![](https://www.bigmountainanalytics.com/wp-content/uploads/2022/02/how-to-1024x670.png)
This is the dialog for creating the new work item. Very simple.
![](https://www.bigmountainanalytics.com/wp-content/uploads/2022/02/create-initiative.png)
After creating the work item, ADO takes you to this screen based. You can build this out now or come back to it later, but you must go back to a previous screen.
![](https://www.bigmountainanalytics.com/wp-content/uploads/2022/02/build-out-initiative.png)
Go to the Backlog levels screen. You’ll see that the Initiative work item type I created is sitting under Other work item types. ADO puts all newly created work items types here. You have to move them to the backlog. If I were to go to my Backlog at this time, the Initiative wouldn’t be above the epic. We need to set that up by clicking on the New top level portfolio backlog link.
![](https://www.bigmountainanalytics.com/wp-content/uploads/2022/02/more-config.png)
As you can see, there are three types of backlogs – Portfolio, Requirement, Iteration. Put your custom work item types within one of these backlogs. To my knowledge, you cannot create backlog types.
Now, clicking New top level portfolio backlog brings you to this configuration dialog where you tell it the Initiative should be in the Portfolio backlog, and that it should be the default work items. Setting the Default work item type to Initiative means that when you are in the backlog and click on the add new work item, it will default to adding an Initiative. Previously, it would have been Epic.
![](https://www.bigmountainanalytics.com/wp-content/uploads/2022/02/configure-backlog-level.png)
After clicking Save, the Initiative shows up at the top of the backlog. The Initiative sits above the Epic in the hierarchy. If I were to create another work item type and add it to the Portfolio backlog, it would be placed above the Initiative. This means that if you add an Initiative to the portfolio backlog and later decide you want something between Initiative and Epic, you would need to remove the Initiative, add the other work item, and then add Initiative back.
![](https://www.bigmountainanalytics.com/wp-content/uploads/2022/02/new-backlog-level.png)
Conclusion
And that wraps up this post on how to customize work item types in Azure DevOps. Check out my other posts in the series.
Other Azure DevOps Posts in the Series
- Managing Analytics Assets with ADO (aka how my org works and why we need ADO)
- Azure DevOps Terminology and Structure (so you know what we are talking about)
- Questions to Ask and Answer Before Configuring DevOps (so you don’t have rework like I did)
- Configuring Microsoft Azure DevOps (configuring Teams, Area Paths, …. )
- Clone Processes to Unlock Customization in Azure DevOps
On what version of AzureDevops it was done? was it on MS Cloud service or on prem ?
MS Cloud. Not sure about the version when I wrote it. We may have upgraded since I wrote it and I’m not involved in the upgrades. Apologies I don’t have a solid answer for you.