Is there anything wrong with making a Bug work item the direct Child of an Epic work item?
We are using the "Bugs are managed with requirements" configuration in Azure DevOps so we prioritize bugs alongside requirements and create tasks under them.
It seems in this configuration all the documentation show bugs being children of features as the logical parent, or unparented. I can link an Epic as the parent of the bug, and nothing is wrong (it actually works great on the Delivery Plans).
But of course, you cannot:
Use the mapping pane in the backlog to map a bug to an epic (this also is only designed to allow you to map to a Feature)
See these bugs in the Epic view of the Boards (kanban) area
What I'm trying to avoid is creating an unnecessary feature work item as a layer in the hierarchy, say if:
Epic - version 1.0
Feature - feature a
Requirement 1
Requirement 2
Bug 1
Bug 2
Feature - feature b
Feature - service pack <--- unnecessary layer, especially in rollups
Bug 1
Bug 2
Where instead I could do:
Epic - version 1.0
Feature - feature a
Requirement 1
Requirement 2
Bug 1
Bug 2
Feature - feature b
Bug 1
Bug 2
Example Parenting Bug Under Feature
If I parent the bug directly under the epic, I don't have the extra feature, which is great. The screenshot below shows the default configuration of parenting the bug under the epic, which creates 2 features instead of 1.
Related
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.
Within our software, we want to implement a grid-style "Editor" for filling in information for various components. This Editor is itself a feature, and is expected to do several things out-of-the box. Most of these of these behaviors are simple and work well as Work Items.
However, one feature of the Editor that we want to implement is an auto-fill button for a particular column. This auto-fill feature is fairly involved and will really require multiple work items of its own. So it's essentially a feature within a feature.
However, from what I can tell, DevOps doesn't play very nice with features within features. You can do it, by creating a Work Item under a feature and then converting it to a feature. But then you can't drag to re-order those sub-features like you can sub-Work Items.
So, what's the "proper", best-practice, officially-supported way to handle "features of other features"? Just create the sub-features at the same level as the main feature? This seems very unorganized... but I don't know of a better fully-supported way...
EDIT: To clarify, one of the reasons we'd like to have "sub-Features" at the same level as "sub-Work Items" (in addition to just grouping everything relating to the parent feature together) is so that we can re-order and prioritize sub-Features amid the rest of the sub-Work Items for the parent feature.
Agree with Daniel,creating a new backlog level between Epics and Features is a solution.
To do it , first，your project needs to use a inherited process . You can create inherited process in the Process of Boards in Organization Setting.
Then in the inherited process, you can create a new work item type as a backlog level between Epics and Feature.
I come from using Rally and Pivotal Tracker. In both I could assign work items to Releases as a planning tool, and to have a historical record of those work items that were deployed.
Even with all the highly-specific guidance from Microsoft about Azure DevOps, it is silent how to organize work against future Releases. I can't see a place to even associate a work item to a Release. Is there something I am missing in all the documentation, or is there some workaround strategy more robust than just using tags to pro-actively plan against releases? Or is Microsoft's expectation that I use some separate product management tool to manage work items against Releases?
There are multiple techniques employed to accomplish this, not "one way":
use a parent iteration path that groups the iterations you plan against a certain release. This works best when you completely finish one release before starting the next. Otherwise, it usually becomes a mess with multiple active iterations.
Backlog Iteration
+ Release 1.0
+ Sprint 1
+ Sprint 2
+ Sprint 3
+ Release 2.0
+ etc
-
use tags for releases. Add a tag [Release 1.0] top all work items that are included in that release, this is one of the most flexible options.
use Azure Pipelines to keep track of which Work Items were associated to which Git commits and thus was included in which Build artifact. Track the build artifacts across environments to see which work items were deployed to an environment by looking at the intermediate builds.
add a custom work item field to the work item types you want to track. You can change the work item process being used and you can add a field to the work items in which you can specify the release name/number. There are custom controls available that can scope the version numbers to a specific list or can fetch the allowed values from any REST API.
Azure DevOps is more flexible in the usage patterns as you can see, but it also means that sometimes you need to "figure out what works best" for your team.
Another extension you may be interested in is the Bravo Notes extension. Or one of the other extensions that can generate Release Notes based on you work item data, commits and/or pipeline artefacts.
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.
We are using TFS 2017 as our project management system, and I'm missing a functionality that seems to be available in most other solutions: it's the ability to regroup tasks/user stories/bugs/etc into a single set (called Milestone in Github, or Version in JIRA) to be able to track the work done and remaining for the release of a defined set of functionalities.
Does TFS provides an equivalent to those Milestones/Versions?
It sounds like a sprint / iteration to me.
Since Iteration path is hierarchical you can create nodes that represent Releases or Milestones (versions are a bad idea) and then have your Working Time as Sprints under them.
Release 1
Release 1\Sprint 1
Release 1\Sprint 2
Release 1\Sprint 3
Release 1\Sprint 4
release 2
Release 2\Sprint 1
You can then have a variable number of Sprints inside of each Release. If you are in VSTS you get good visual planning tools to help you plan across releases or sprints...
Another options would be to add a custom field for the data that you want to track.
Usage of Iterations is typically the way to go. However, you can also use Tags and Queries to create release or milestone lists that are either flat or hierarchical. If the queries are flat, you can create graphs/charts and dashboard them as well.
Delivery Plans also add yet another alternative to help visualize timelines and create markers for important dates/milestones.