Removing Assigned To Rule from Bug

Dan Hellem

In Azure DevOps, there are many hidden state transition rules scattered across the different work item types. These rules are system generated and cannot be edited or removed. Most of them are necessary to track when a work item is activated, resolved, or closed. For a few of the rules, the value is less obvious, and in some cases are a cause of customer dissatisfaction with the product. Even though they made sense years ago, these rules have outlived their usefulness and it is time for them to be removed.

In this blog post, we wanted to share the impact of the first rule being removed. We also have a work around for those customers who still want to use the rule in their projects.

Assigned To rule

Although there are several hidden system rules across the different processes (Agile, Scrum, CMMI), the one rule that gets the most negative feedback is on the Bug work item type in the Agile process.

This rule states..

When the bug moves to Resolved then automatically set the Assigned To value to the person who created the work item

Image bug wit rule

On the surface it makes sense to assign the bug back to the person who created it. They need to validate the bug is fixed. But in reality, teams don’t always work this way. Because bugs are a heavily used work item type, it makes sense to remove this hidden rule and keep things simple.

This is the first rule to be removed.

Customer impact

The rule will be removed from the Bug work item type in the Agile template starting in the Sprint 177 deployment (starting the week of October 19th, 2020). All projects using the system Agile process or an Inherited Agile process will be affected. Once the deployment reaches your organization, the rule will be removed from all bugs on all projects.

If you are using Hosted XML, no changes will be made to your process templates and the behavior on the bug work item type will not be affected.

Using a custom rule

For customers who like having bugs automatically assigned to the person who created them, you can create a custom rule. To do so, make sure you have created a custom inherited agile process. Then go into the Bug work item type and create a new rule. Below is a screen shot of the specific rule you can use to set the Assigned To value to Created By when the state is changed to Resolved.

Image bug state rule

Other rules

This is the first rule we are going to remove. It is by far the most problematic for customers. We would love to hear your feedback on what other rules are causing you pain and why. Based on that feedback we are open to removing them in future sprints.

2 comments

Leave a comment

  • Avatar
    Tharakan, Mary

    This is one of the features which was really annoying our teams. Good to know there are changes coming in.

    @hellem dan
    We are using Azure Boards. We already have templates setup for our various projects to auto create work items within the respective projects. We want to take this further where when we create work items in the primary project , the tool auto creates successor work items of the same type in multiple secondary projects. All these projects are using the same process. I am trying to find a way to do this the above operation via templates or some other method.