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
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.
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.
Light
Dark
5 comments
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.
Sorry this is not possible with templates. You will have to continue to use a custom tool 🙁
Hello,
unfortunately, the removed feature is not working in our organizaction. We are on Azure DevOps Services, we use Inherited Process (from system Agile Process), but the Bug still changes the value of Assigned To to Created By user upon State change to Resolved or Closed. Is this new “feature” already installed on all organizations within the Azure DevOps Services?
Thank you for your reply.
Dominik
Sorry about that. We found that the change did not propagate to all organizations for some reason. We are in the process of fixing that and the change will get in the sprint 179 rollout starting this week.
Great, thank you very much.
Regards,
Dominik