Iterations with multiple releases in TFS

1
votes

How should releases and iterations be structured in TFS (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, but without duplicating the iterations:

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

3
tfsazure-devopsrelease-management

3 Answers

2
votes

Ultimately you need to solve this by not having two branches. You should have a single good version of your product and hide features for v2 behind feature flags. You can then add any work, feature or maintenance, to each increment and ship at the end of every sprint. At that point you choose which features you ship with the maintenance work.

Your problem as described then just disappears.

Oh, you might want to use Tags to tag your maintenance (Opex) work for later.

1
votes

I've worked around this limitation by iteration splitting the branches into different child nodes of the iteration. After all, there isn't really the concept of "type" in the tree, so the nodes can be anything you want.

  • Backlog
    • Version 2.0 Backlog
    • Iteration 1
      • Maintenance Release 1
      • Version 2.0 Roll-up
    • Iteration 2
      • Maintenance Release 2
      • Version 2.0 Roll-up
    • Iteration 3
      • Version 2.0 Release

Also, I keep a separate backlog for the branch work.

1
votes

It seems like you are artificially tying your iteration structure to your branch structure.

If you do work in Iteration 1 for both "Branch 1" and "Branch 2", then why not use a single iteration, but two area paths? That way, you can have user stories and tasks for both areas within the same iteration.