While a novel approach, this is not a good use of Azure DevOps as presented to us in its default state. Instead of assigning multiple identities to the User Story and other work items, you are supposed to create separate work items as child items to the User story and assign those items to the individuals. Then you assign those tasks into Iterations/Sprints. From the User Story point of view, even if you are using the User Story kanban board instead of the task board.
You can't conditionally show different fields depending on their swimlane, not out of the box. I do have a separate solution but first lets consider how DevOps wants you to use it...
(multiple) "People Assigned" is a Red Flag in Azure DevOps, you will be swimming upstream if you continue with this line of thought.
The visual on the card of who the item is assigned to is only part of functionality, even if you could achieve your request on each board we can apply filters by user and this will only operate on the "Assigned" user field.
A User Story (or Product Backlog Item or Requirement depending on your process), has a single conceptual "Owner". This is the person assigned to the User Story, I will assume that this is the "Biz Architect" in your process as they are most likely the product or the requirement owner.
In a practical sense, this is the user who all questions, queries and issues about any of the child items will be directed to, this is the person who is responsible for managing the user story, for verifying that it is complete and should be the only person who can "Close" a task.
Developers are assigned to development Tasks, use the Activity field to determine if the task is a development task or not.
When a developer finishes their task, they drag it to the Resolved column of the sprint. Once all the dev tasks are complete the owner or Scrum Master can initiate any processes required to deploy or begin the process of testing. This involves dragging the User Story to the Testing in STG column in it's board, on the task board, this just means that the testing tasks can be assigned. (If they are not already)
- In a project similar to this, many process related tasks like testing, and UAT are not assigned to the sprint if they are pre-defined, (or they are assigned to a holding sprint) then when the User Story is transitioned to Testing phase, at that point those tasks are created or assigned to the current sprint.
Testers are assigned to the specific tasks listed for testing, you can use Activity to specify that these tasks are for testing if your process is not using Tests natively.
Just like other tasks, test tasks start in the New column, are Active while they are being tested and set to Resolved when they are done. There may not, and should not be a 1:1 correlation between the development tasks and the testing tasks. It is valid for 1 test to cover many tasks, the outcome of a Test task might be to push some dev tasks directly back to Active, or to create new dev tasks.
- Depending on your process, you might allow testers to close dev tasks as they verify them... But that is better left to UAT.
- As with the dev phase, there might be a process to initiate communications and deployments before the User Story is officially transitioned into UAT.
UAT Reviewer... you can see where this is going ;) Create a task with activity type called 'UAT Review' and then someone assigned to that task will be the UAT Reviewer
- Once all tasks are in the resolved state, then the User Story owner is responsible for reviewing all the associated tasks and choosing if they can be closed or not and what the final state of the user story will be.
This is how the kanban boards will now work for you so you can see the users who have been assigned. I would customise the board by using different colors on the cards based on the Activity field.
It feels a bit like micro-managing, but this plays well into the built in tools for estimating sprint and user capacity and effectively captures everything in a way that you could compile timesheet entries retrospectively with little additional effort.
The point to this is that to DevOps, why the user is assigned is not important, what is important is that only one person is assigned. This supports a workflow for instance where the developer assigned to a task stays assigned to that task and we can go back to a previous sprint and "Know" who was the developer assigned. If you change the assignment so that after dev, the task is owned by the user who will test and then review, we actually lose a lot of critical project management information that would otherwise only be known through analysing logs.
Many of these tasks will continue in parallel, so it makes sense to keep the tasks separate. To facilitate discussions between multiple tasks you can link them as Related or can #mention them in the discussion
The type of granular assignment described here sounds to me like the CMMI process template might be closer to your actual development process. Have a look at that process if you have not already ;) You cannot change the process template but if you haven't gone too far creating a new project might still be a viable option
What you can do, but it will take some scripting or manipulation... and it makes a mess of the analytic logs... and I really do not recommend it... you can show each of these identity fields as optional in the cards by de-selecting the show empty fields checkbox:
This way the field will only be shown if it has a value, so you could script logic as part of the state transition to clear out the fields for the non-active state. To set up rules for this will require you to have 2 sets of fields, one for the definitions, this can be the current one, then the other for the current value that the rules can set.
