Managing Suspicious Requirements with Automatic Flagging

Dirty Flag / Suspect Link is a component of MR Services (formerly called MR Agent) that is used to identify work items that might be affected by the changing of a linked work item so that relevant stakeholders may review the impacted work items. For example, if a user story changes in the active states, then the related test cases would be marked as suspect.
 
The Suspect Link feature contributes to your project’s success by making the impact of Work Item changes both query-able and, generally, more noticeable. You can consider this feature as one method of doing an impact assessment on changing work items within your project.

How does Dirty Flag / Suspect Link work?

This feature works by allowing you to monitor Work Items which meet certain preconditions. When these Work Items change, the monitor feature will mark any linked Work Items as suspect.

Let’s consider an example:

User Story 1 has just been moved to the ‘Completed’ state. If the Suspect Link can be configured to trigger a flag if any changes are made to user stories in a “Completed” state (i.e. a change to a field such as ‘Description’).

This means that if User Story 1’s Description field is changed in the future, it will flag all of the requirements that are linked to it with a Dirty Flag.

This allows your team to easily identify if a requirement that matches a certain set of criteria (which you specify) changes. Once identified, the configured work items directly linked will be flagged by the Dirty/Suspect.

To continue with our example, if User Story 1’s Description field changed, we could Dirty Flag all of the directly linked Test Cases that might need to be changed to test the new criteria changes.

The Dirty Flags that get set on those Test Cases would take the shape of a Work Item tag.

Tags show up in the Standard Work Item editor of Azure DevOps. You can also personalize the Column Options in the Work Items and Backlogs module to view a group of Work Items in which some may be marked by the Dirty Flag.

In the case of the Dirty Flag tag that is set on Work Items, the tag that is applied includes both the changed Work Item’s ID, and revision, so that your team can easily identify which requirement was it that changed and fired the Dirty Tag / Suspect Link functionality.

Dirty Flag tags could be manually removed when relevant stakeholders have reviewed the impact and made necessary updates. The best practices we recommend here is to add another comment explaining that now the Dirty Flag is removed due to necessary updates have been accomplished or no updates are required.  

For more details and the configuration process of Dirty Flag/Suspect Link, please watch the video.

 
Time to Read: 20 minutes

Recommended Posts