PowerObjects Blog 

for Microsoft Business Applications


Tagging In Azure DevOps


Tagging In Azure DevOps

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.

Why Tag?

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.

How Do You Tag?

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.

Tagging Tips & Traps

Don’t let tags trip you up. Note well…there are some considerations when tagging in ADO:

  • Short tags are best because you want to focus on a key characteristic to differentiate some work items from all the others. Short tags are also easier to remember. And since spaces are not allowed in tags, a short one- or two-word phrase (with an underscore) keeps them readable.
  • More than 100K tags in the project will impact performance and make them essentially unusable. Besides how could you possibly use 100K tags effectively?
  • 100 is the max number of tags for any single work item; otherwise, you won’t be able to save the record at that point. If you need to add that many tags to a single work item, maybe the work item should be broken up into child items. The number of tags should be limited much like a user story shouldn’t exceed 8 story points.
  • Users cannot delete a tag from an ADO project, only from individual work items. If no records contain a tag previously used, then the tag itself will be deleted from the project automatically.
  • The right license (Basic which comes with a fee) is required to create new tags in the project, but any user (even the free Stakeholder license) can use an existing tag. This limitation may help with governance and prevent proliferation, but that is only if the Basic/Basic + permissions are limited to experienced taggers. True governance is the only sure-fire way to manage tags: Set goals, define usage standards, and curate the list periodically.

When to Use/When Not to Use?

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.

Articles

If you’re looking for more in-depth instructions on tagging, Microsoft has what you need:

Happy Agile’ing!

Joe CRM
By Joe D365
Joe D365 is a Microsoft Dynamics 365 superhero who runs on pure Dynamics adrenaline. As the face of PowerObjects, Joe D365’s mission is to reveal innovative ways to use Dynamics 365 and bring the application to more businesses and organizations around the world.

Leave a Reply

Your email address will not be published. Required fields are marked *

PowerObjects Recommends