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.
Related
I am using Area Path in Azure DevOps for categorization rather than breaking into separate Teams. So I can't see all the Work Items underneath the Default Backlog. I go into Settings and choose "Include Sub Areas" and I get the following Warning:
Are you sure you want to include sub-areas?
You have selected the root area path as your team's work area. This
causes two things to happen:
All work items that appear on any team backlog will also appear on
your team's backlog.
All work items under this area path will be updated, which might
impact the performance of your server until the changes are complete.
Are you sure you want to do this? If not, choose Cancel, and the
change will not be made.
#1 is what I want, but what are the implications of #2? What is updated on the Work Item? Will the Assigned To user be emailed of the change?
For #2. The items will be stackranked again to define the backlog order for all work items in the selection. I've seen instances that had millions of work items and the recalculation of the backlog priority field and mapping to your team's custom board columns may take a while in that case.
This field is excluded from the standard email notifications.
It's possible to drag and drop a task from one userstory to another userstory in Azure DevOps Boards. Is it possible to prefent this?
I expect that a task stays in the original Userstory it's made.
We can prevent the task from being dragged and dropped from one user story to another by setting permissions. But permissions can only be used for the whole work item, not only for changing links(Task is linked to userstory as child related work). This means that although drag and drop can be prevented, other fields of the work item cannot be modified.
When you don't want the tasks to be dragged, you can set edit work items in this node permission to Deny. Note: Make sure the work item is in the area you set, and the permission will take effect.
Project Settings -> Boards Project configuration -> Areas -> '...' -> Security :
When you need to modify the work item, you need to open the permission again. This may be a bit of a hassle, but I cannot think of any other better way at the moment.
I've done some searching but can't find an answer to this. In our current Test Case Management System, we have an option to archive Test Cases which are no longer relevant (eg because an API or UI option was removed). The TC still exists, but just cannot be executed in any Test Suites any longer.
However, I cannot find any such option in Azure DevOps ... is there ? The closest I can find is deleting a work item, but that's obviously not what I'm after. I know that other work items (stories, epics, bugs etc) have a defined beginning and end, but TCs tend to stay around as long as they are relevant (for automation/regression testing etc), so I feel they should have a slightly different lifecycle than other work items.
Anybody found a way of doing this in Azure DevOps or found an alternate solution ?
There is no out-of-box features for that. You may try on of these suggestions:
Just add new tag "Deprecated" or "Archive". Add work item tags
Add area path "Archive" and move work items to it. Define area paths
Edit your process template and add new state "Archive" to "Remove" category in the test case work item type. Add a workflow state
I am using the Agile Process on my project and have a question regarding how to handle bugs on my boards. I have been using the option "Bugs are managed with requirements" because this seems to be the only way bugs are visible on the board. When you use this option, bugs appear as separate work items on the board. (essentially they are treated like User Stories) and can be moved around the board independently. Screenshot of my board
This is OK, but I would rather have them act like Tasks and be grouped together with their parent user stories. This is how tasks appear:
Screenshot of a story with it's associated tasks
One would think then that selecting "Bugs are managed with tasks" would do this, but it does not. By selecting this option I would expect to see somthing like this mocked up image here:
Screen mock of what I would expect bugs to look like using this option
Instead, when I select "Bugs are managed with tasks" they no longer appear on the board at all. screenshot of my board when "Bugs are managed with tasks" is selected
Is this the desired effect of this option? If I select "Bugs are managed with tasks" where do I interact with bugs? Clearly not on the board...
Am I missing something? Again, what I would love to see is this: Screen mock of what I would expect bugs to look like using this option
where bugs are truly treated like tasks, and are shown on the user stories cards on the board.
Thanks for any input/insight you may have.
For anyone else that happens upon this, I'm including a straightforward answer. I realize that at the time the answer was posed, things worked a little differently, but as of 2021 this works (and has for at least the last year or two I would say).
"Bugs are managed with tasks" results in this:
and in the sprint:
However for the above to work, the bug must be a child of the user story.
If the bug is not the child of the user story, the bug will show as unparented, like this.
"Bugs are managed with requirements" results in this:
and in the sprint:
You cannot manage the bugs with requirements and tasks at the same time.
"Bugs are managed with requirements" makes the Bugs have the same
level with PBIs, so bugs appear as separate work items such as PBIs
on the board.
"Bugs are managed with tasks" makes the Bugs have the same level
with Tasks, so you can treat Bugs as Tasks in Backlog.
The feature you requested is Enable/Disable annotations (Kanban boards) in Azure DevOps.
Not sure where did you find the screenshot you provided: Screen mock of what I would expect bugs to look like using this option. As far as I know we cannot add "Bug" annotation to cards for now. No such a built-in feature.
However there's already some user voices submitted to suggest the feature, you can go and vote them up to achieve the feature in future release...
Add annotation for bugs on feature board
Add a "bug" annotation to feature cards on the features backlog
board
This is a bit late so you probably already resolved, but this just in case it's not....
you wrote:
'Instead, when I select "Bugs are managed with tasks" they no longer appear on the board at all. screenshot of my board when "Bugs are managed with tasks" is selected
Is this the desired effect of this option? If I select "Bugs are managed with tasks" where do I interact with bugs? Clearly not on the board...'
If bugs are managed at the task level, then it would be quite messy to see all tasks on a PBI board. Instead, you might want to look at the Taskboard (under Sprints). This tracks one level deeper and provides PBI to task item mapping and status.
Regarding the annotation, yes you can add Bugs to the PBI card. From the Board, click on the gear icon and select annotation option Cards.
I still didn't get it.
Where do complete backlog stays if we have to plan for new sprint and pick items from backlog. Like I can see stories/features but what about all bugs/issues, where they can be seen?
I don't want to search for all items in queries/work items. How can I bring all work items in backlog?
Sounds like you're using the Agile template, which doesn't put everything on the product backlog by default. You can edit the backlog settings to put the bug workitem on the backlog. You can find this setting in the Backlog customization screen, as long as Bug is configured to show up as a requirement, it should show up on the product backlog:
Since issues follow a completely different workflow, they cannot be placed on the product backlog. I would guess that they're being used as something else than what they were meant for. But you'd have to help me with additional information. The Issue work item type is the scrum equivalent of an Impediment. Anything that is blocking the team from progressing effectively. These aren't part of the work that goes into the product and are not managed on the same list.
If you're using the Issue work item as a different kind of Bug/Defect then I recommend either creating a custom field on bug to signal the bug type or create a new work item type that is a copy of bug to start with, that way it starts out with all the fields required for it to show up on the backlog.