In this webinar, our experts showcase a variety of demo use cases of how different components of the...
What is Tagging? Tagging has long been a term used to describe a kind of graffiti to mark public spaces. In Azure DevOps (or ADO), tagging is similar because it can serve as a colorful label for work items to visually distinguish one epic from another, isolate a critical user story from hundreds of others, and so on. The big difference here is that tags in ADO should be encouraged (though controlled). And while tags on the London subway are unauthorized, tags in ADO could make you as famous as Bansky.
In its simplest form, a tag is a label on a work item in ADO. It can serve as metadata to help you sort, organize, and find records. The metadata is stored in the header of each record, allows free text entries, can be leveraged in the basic modules of ADO, and is part of the core elements within ADO. Note that the Tag field is a restricted field in ADO, so it’s not like other out-of-the-box fields that can be tailored, customized, moved, and renamed. Tags stay in the header; they cannot be moved to the record form, and they cannot change their data type. Furthermore, new tag definitions are limited to the Basic user license, though Stakeholder license users or higher can assign them to records. Despite these restrictions, tagging is a highly useful feature in ADO.
If your ADO project only has a few hundred work items, then you may not need tags. But what if your project has a couple hundred new items created each sprint or your program intakes hundreds each week. Then you’ve got a problem if you don’t have a way of managing those work items. Backlog grooming can bog you down if you’re scrolling through more than a couple dozen items. Tags can rescue you from the ADO quicksand.
Tags are nearly the easiest thing to create. You simply click in the header on the Add Tag button (first time) or the Plus sign + (after the first tag is created) and start typing. If you want to add a tag that has already been used, then you may only need to type a character or two before ADO prompts you to insert a previously stored tag. Yes, it really is that fast! They can be removed just as quickly by clicking on the X next to the existing tag. And just like that, the tag is removed from the work item.
But creating or removing the tag is just the start! The Tag field can be added to boards, queries, and backlogs. Why is that so important? Because these tags now become a powerful mechanism for filtering and sorting your work items. When it comes to queries and such, the Tag field is just like any other field. You can use the same Column Options feature in ADO to add the Tag field to a display. But unlike other fields, the Tag field also is available in the quick filters (above the summary listing of work items).
When you’re able to filter 732 work items down to a list of just 49, well, then you can really groom that list for sprint planning and daily scrums. Additionally, you can customize the styles associated with the tags by adding color. This makes those related items really pop when viewing a Kanban board. Simply go to the board you want to customize, click on the Settings icon in the upper right of the screen, select Tag Colors from the left navigation pane, and style to your heart’s content. Note that you must have permissions (Basic user license or higher) to associate a color with a defined Tag.
Once you start using tags, you may discover that you have too many to be useful or that a tag that was once meaningful has lost its importance (perhaps the context is no longer valid). When that happens, you can and should engage in some general ADO housekeeping just as you would with other data. Tags can be bulk removed from records (or bulk added) using the same bulk edit tool that you use for other fields. Simply select several records in a list view, right click, select the Edit option, select the Tag (Add) or Tag (Remove) option for the Field* value, type the Tag definition in the Value field, and click the OK button. Don’t forget to use the Save Work Items button on the list’s menu bar after you’re done to commit the changes in ADO. This maintenance is essential; careless tagging can leave you and your team mired in ADO quicksand.
Don’t let tags trip you up. Note well…there are some considerations when tagging in ADO:
Question to Ask Yourself | Tag or Not to Tag |
Will I need to use this label for future metrics? | Yes, then use a custom or default field instead.
No, then tag it! |
Will I need to display the results in a dashboard widget? | Yes, then use a custom or default field instead.
No, then tag it! |
Is it a permanent label? | Yes, then use a custom or default field instead.
No, then tag it! |
Are there lots of records that could be better identified through a common characteristic? | Yes, then use a custom or default field instead.
No, then tag it! |
Is the label unique to a few records or a situation? | Yes, then update the description field or post a comment in the discussion thread instead.
No, then tag it! |
Will I want to search for related items? | Maybe. If it’s more permanent/long term, then consider using a custom or OOB field to aid in searches long term for your project.
If the need to find the related records is short lived, then yes, tag it. |
Is it something that will help me sort records? | Maybe. If it’s more permanent/long term, then consider using a custom or OOB field to help with sorts long term for your project.
If the need to sort is short lived, then yes, tag it. |
If you’re looking for more in-depth instructions on tagging, Microsoft has what you need:
Happy Agile’ing!