CODEWITHSUNDEEP
azure-devopstfs-workitemproduct-management
Max
Max

Reputation: 121

Cannot Assign Work Items to Releases in Azure DevOps

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?

Upvotes: 4

Views: 1637

Answers (2)

Louise
Louise

Reputation: 1451

In addition to the answer by @jessehouwing I can add

  1. Instead of parent iteration path I currently use a parent intiative. Below that you can group epics, features and items of the planned version.

However, this has drawbacks, as do the other variants. In my experience (tried 1, 2, 5, currently setting up 3):

  1. As Jesse wrote ... this is almost perfect, also with regards to queries and dashboards - unless work overlaps, which (I think) occurs naturally towards the end of one release cycle and the start of another. In my experience, clean cuts along sprint cycles are ... non existent :) For general purposes (dahsboards) this might not be important, but for other uses, this is to fuzzy.
  2. Lots of work keeping all tags up to date, especially when items shift. Prone to "missing something". However, easy to use in queries/dashboards and would be most flexible - the only variant here that can handle items being part of more than one release, I think.
  3. This is probably the most precise regarding the actual delivery (when all linking is done correct), but doesn't help in planning future versions.
  4. Manual work as with tags, but possibly more pronounced/obvious and can be enforced (required check). We haven't tried this one yet, because it requires negotiation with Azure admins and possibly other teams. All other options work out of the box with standard rights.
  5. Almost like 1. but without the fuzzy overlap (good), but can't really be queried (bad). I searched for a query like "all below parent X", but didn't find a solution. And Initiatives then have the meaning "version", which is fine for us, but others may want to have other semantics, like "Big Topic A", regardless of what goes into which release.

So... I'll probably try 4. next and see where that goes :)

Upvotes: 0

jessehouwing
jessehouwing

Reputation: 115037

There are multiple techniques employed to accomplish this, not "one way":

  1. 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

-

  1. 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.

  2. 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.

  3. 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.

Upvotes: 4

Related Questions