I have been tasked with running point on implementing Azure DevOps on my team at work.
We are using the CMMI process and tracking bugs at the requirement level.
Recently, it was brought to my attention that when we marked a Bug work item as active, manually change the state and not drag the card to the next swimlane, it simply disappears from the board. The work item can still be viewed on the task board, but is no where to be found on the requirements board until the state is changed again.
Has anyone else run into this problem and know of a fix?
Thanks
The issue is the configuration of the board itself. The default does not include bugs, so when you create your columns, the bug configuration for "Develop" gets set incorrectly.
Go to your settings for your board by clicking the gear icon in the upper-right of the board
Once into the settings, choose "Columns" from the list of items on the left of the modal window and then choose the column where the Bug items keep disappearing (the Develop column in my case), and you'll see some drop-downs for Bugs and Stories for "State Mapping".
If you change the bug setting here to "Active" and then save, the bugs should reappear on your Develop board. You'll want to do the same check for any other columns.
You can update Working with bugs setting for boards to Bugs are managed with tasks.
You will need team administrator or a project administrator permissions to change this setting:
Related
We moved from on-premise TFS 2019, to Azure Dev Ops version Dev18.M170.6
This resurrected the Blocked state on a bug work item, and people have been setting the status.
What we didn't anticipate though, is those tickets disappearing from the kanban board, as the default columns are New, Active, Resolved and Closed.
When I try to customise the columns and add a new entry for Blocked, it's not an available state from the drop-down.
How do I get Blocked to appear in the drop-down, so I can add a column for it?
Please enter Organization Settings--> Boards--> Process--> enter your process --> select the work item Bug -->State and then add a new state for it:
I have a DevOps account with a project in it. I am using the Agile process. I have work items such as bugs, features, etc. Please notice that I can actually see bugs in my KanBan board as I did the configuration to show bugs in there.
Problem
Problem is that if my bugs have the root area MyArea, they are shown in the board, but if I set a subarea MyArea/Subarea, the bug disappears from the board.
How do I solve this?
That`s may depend on your team settings. As example, you can enable sub-areas in your root area:
Or add every every area to the team areas that you want to see on your board.
On the Azure DevOps TaskBoard for a sprint, it would appear that the only thing I can drag across the board is Tasks. Not bugs. Not Backlog items. Which means if I want to see where a bug is on the board, I have to create a task for it. (Note: My project uses Scrum. Bugs are managed with requirements)
I guess this makes sense. It is a "Task board" after all. But this seems tedious. Most of the time, the bug is the task. I make a bug, make a check in, and mark it done. I would expect to be able to drag the bug itself across the board to mark it done.
And even if I go to the trouble for creating a task for a bug (or a Backlog Item) and then I drag the task across the task board to "Done", the bug's status still stays where it was. It doesn't change to not done. I then have to go to the bug and manually mark it as "Done"
This really limits the usefulness of the Taskboard for our planning.
Am I missing something? Is there way to change this?
You can choose to manage the Bugs with tasks as Daniel commented. And You can use extension Work item form one click actions to assign the Bug to some parent PBI automatically. See below example:
First you need to install Work item form one click actions extension to your Organization.
Then Go to project setting page-->WIT One Click Actions under Extensions-->Bugs-->Create rule group-->New Rule
Triggers: New work item load
Actions: Link to an existing work item(relation type: Parent; Work Item id: Id of PBI)
After above rule is created. The newly created bugs will be automatically added to the parent PBI you specified in above rule.
However, The PBI and Bugs(managed with requirements) can be moved around in Boards. So you can use the filter to view your work items in a specific sprint.
Host Details:
OS Editon: Azure Devops server 2016
OS Build: 1607
Azure DevOps Details:
AZ server: 2019
The issue:
For one Team Project, we are requiring to have three different sub-area paths so we can place work accordingly for each team Properly to follow it.
The three sub-areas were created as follow:
and visible are visible from Bords:
But, and here the issue, the Button for creating New Work Item now is Disabled, as shown below:
Also
How could re-enable this button?
We use this button at daily basis to create New Tasks or as required, is so weird that enabling one functionality we lost other.
It’s possible your workflow has the work item disabled. Check your process and see if the work item type is disabled. Also on the ribbon next to View as Board, hover and click, it will give you a more detailed error message.
If the work item is disabled you will see this message.
Solved by myself
Hello Martin, thanks for reaching me out so swiftly,
I did found the issue, due to a lack in Azure DevOps documentation didn't know that when creating a new Team Project have to create the extra teams within the Project before anything else, and then is that can proceed to add define the sub-area paths in the Boards Section and then is when is possible to have First multiple teams within a team project and Second have enabled the Work Items Button for each team sprint:
See for example this MS official documentation how they don't make any clarification of it: {{ https://learn.microsoft.com/en-us/azure/devops/organizations/settings/about-areas-iterations?view=azure-devops }} :
Also here {{ https://learn.microsoft.com/en-us/azure/devops/organizations/settings/set-area-paths?view=azure-devops&tabs=browser }} :
So MS docs miss that point completaly!
Solved each team is an independent unit and for that each will have their own setup,
Once that is corrected all works fine
I've recently started on a new project with a new firm. The release pipelines, in particular, the release view, is completely different, AND it doesn't work properly. The logs don't load, hardly any of the links work and it doesn't support themes correctly.
Does anyone know how to change it back? I've looked under preview for not only my user but the whole organisation and I don't know what is going on.
The first image is what I am after...
This is what I currently have...
Thanks in advance
They have their account feature flags set to use the old release view. You can override that at the user level by going to "Preview Features" and turning on "New release progress view".