Parallel/branched releases in TFS

Question

What is the best way to structure releases and iterations in Team Foundation Server (specifically Visual Studio Online) where some of the work in an iteration counts towards one release while the rest of the work counts towards another release?

Some background: I'm working with a single team that has 2 code branches: the 1st branch is for maintenance with releases every 2 weeks, the 2nd branch is for a long term "Version 2.0" project (release is in 6 months). We work in both branches in each iteration, and we all work on both maintenance and the "Version 2.0" project.

Our current iteration tree follows the \<release>\<iteration> pattern like this:

• Backlog
  • Maintenance Release 1
    • Iteration 1
  • Maintenance Release 2
    • Iteration 2

The problem occurs when some of the work in Iteration 1, for example, will not be released in Maintenance Release 1 but rather the future "Version 2.0" release.

I would like the structure to be more like this, at least conceptually:

• Backlog
  • Maintenance Release 1
    • Iteration 1
  • Maintenance Release 2
    • Iteration 2
  • Version 2.0 Release
    • Iteration 1
    • Iteration 2

What I've considered trying: Restructuring our team to have maintenance-only and "Version 2.0"-only developers is not an option. Breaking down our iterations to be maintenance-only and "Version 2.0"-only is not realistic (we need quick turn-around on maintenance, so that work needs to be in every iteration). Planning 2 concurrent iterations seems like overkill. I would rather the tool conform to our reality than conform our team to the tool's limitations.

Answer 1

One possible solution would be to take the releases out of the iteration hierarchy and track the releases as tags on the backlog items. Then set up your iteration queries so that the tags appear as a column. This will allow you to see everything in a given iteration at once and see which items within the iteration are going into each of the releases. You can also make queries based on the tags with the iteration as a column, so that you can see which items are needed for the release, and which iteration they are scheduled for.

Answer 2

Disclaimer: I do not use TFS in my project, but I believe my project faces the same conceptual issue as yours.

Problem we faced: Work needs to be planned (and built) but only at a later stage is decided when it needs to be released (if on a shorter or farther release).

Approach used: All build and plan is done regardless of release. Once a task becomes priority, team starts working on it (based on team's capacity, of course). We use Subversion for code versioning and all work is initially built on Trunk. Once the code is stable enough, is decided whether this change needs to be promoted (i.e. manually merged) into future branch / farther release or the branch for the near release is re-created from Trunk.

Problems / drawbacks: Once a build is started, or you roll everything back or you'll be carry on code eventually that's not supposed to be switched on. For this, we use some kind of 'switches' in our code to set a feature on or off.

Success!