No way to group work items into releases in TFS 20

Question

My team is just now starting to use TFS 2015 Update 1 on premise to manage their development process. I have set up the server and defined some custom states and transitions for work items to better map to our process. To start with, we will only be taking advantage of the Kanban board and are not attempting to use iterations for a variety of reasons I won't get into here.

My problem currently is using TFS to plan releases. Specifically, I don't see any way to group Features and User Stories into a specific release. All of my googling has turned up many articles involving Microsoft Release Management, so I installed and configured it, but it is absolutely overkill for what my team is trying to do right now. I'm not trying to automate deployments to different environments at the moment, I just need a way to group work items into a something that encapsulates the concept of a release in TFS. Is there no way to do this? The best I can come up with right now is to further modify the work item templates to either provide a simple "Release" field with a pick list, or define another type of work item that I can group the others into. This seems like a glaring oversight by MS from my perspective, so I'm hoping I'm just missing something.

Answer 1

Answering solely based on your question around planning releases, then:

1. Create a custom work item template, called 'Deployment'.
2. When planning of a release begins, create a new 'Deployment', let's say, called 'MyProduct v1.1'.
3. In your planning meeting, create Features and User Stories appropriately, and create a relation to the 'MyProduct v1.1' Deployment, by opening the User Story and adding a Link (using the Deployment Work Item number) as 'Related'.
4. To monitor Deployments, create a custom Work Item query targeting the new 'Deployment' Work Item template. You can configure this to display on your dashboard.
5. Follow whatever release procedure you like based on the 'Deployment' and its' relations.

You should follow a naming convention when creating 'Deployments' for consistency.

p.s. I recommend using the extension 'Work Item Visualization' in this instance. It'll nicely map out the 'Deployment' related Work Items.

If you want to use TFS to actually build an and create a Release, then Release Manager is worth considering.

TFS 2015 Update 2.1 now includes a built-in version of Release Manager. It's much more user-friendly and simple to configure when compared to Release Manager standalone installations.

To group work items into a 'release', you can do the following:

1. Create a build definition for the repository you're working with - see Build Def creation docs
2. Create a Release definition - see Release Def creation docs

Once you have these definitions created, the working process would be:

1. Developers work against work items
2. Commits are made against the WI number (or tasks)
3. When it's time to create a release, start a build on the definition you created. In doing so, WIs will then be associated with a Build Number.
4. When the build succeeds, start a new Release from the definition you created.
5. You have have a set of work items associated with a release, see screenshot:

Note: You can enable CI builds and releases, although the above is based on manual triggers.

You can also directly call the Release API to locate WIs associated with Releases, however you'll need to obtain the actual Id of the release first.

You are currently limited however to viewing these relationships based on knowing the Release. In a real world scenario, it's more realistic to look at a Work Item to see when it was release. To do that, there's no built-in functionality at present, however my own-answered question will guide you - see here.

Answer 2

Grouping work into releases can be done in a couple of ways, just remember that the concept of a "Release Plan" doesn't explicitly exist in TFS. Release management covers the "Release to Production", but doesn't cover any planning.

Ways to plan releases:

• One way is to create a Release Iteration, this works when you're not working on multiple releases in parallel and truly finish one release before working on the next. The Release iteration used to be default, but has been removed from the product in favor of teams delivering sprints and teams doing continuous delivery.

  Project Root
  + Release 1.2
    + Sprint 1
    + Sprint 2
  

• Another option is to use Tags. You could tag work items with a tag that signifies it's targeted for a specific sprint.

• Use a Marker workitem, on the backlog place one work item which clearly stands out ### END OF RELEASE 1 ### Any workitem below it is not part of that release. This technique fits a more agile way of working and more clearly shows that the contents of a release are a floating thing.

• Create a custom Release Workitem, link your other workitems to this work item to target it for that release.

• And your option to create a picklist on a *Custom workitem field** is another option.

Answer 3

Additional to the methods explained by jessehouwing there exists also several 3rd party tools which can integrate with TFS/VSTS and provide advanced planning features. See VSTS Marketplace for an overview.

Answer 4

Alternatively you could also use the Area Path in much the same way as Iteration Path. By using the Area Path you have the benefit of not having a sprint tied to one specific release.

It is not the best solution but could be the solution in some cases.