Transitioning between Sprints/Iterations with Team Foundation Server (TFS)

Post updated for and Visual Studio 2013 Update 5:, or VSO, recently added support for the query token @CurrentIteration.  @CurrentIteration can be used in your queries to refer to the sprint or iteration that is currently in process.  This eliminates the need to create your own Current iteration as described in our original post below.  This update is also included in Visual Studio 2013 Update 5 for on premise TFS deployments.

You can read more about this feature here:

Transitioning between Sprints/Iterations when using prior versions of Team Foundation Server (TFS)

Our previous approach to this still works if you are using any prior version of Team Foundation Server on premise:

When transitioning from one Sprint (or iteration) to another it is necessary to modify all “current sprint” queries and any additional custom queries that are sprint/iteration specific. This is not a one time activity per team project but rather something you have to do after every sprint.

One way to eliminate this step is by creating a “release” called “Current” and moving the specific current sprint (Sprint 1, Sprint 2, or 2012-02-06 for example) under this release. The current sprint is simply moved from its defined release into the Current release when the sprint starts. When the sprint ends, the sprint is moved back to its original release and a different sprint moved under the Current release. Then, by changing all the sprint specific queries to select item under Current release, it is no longer necessary to change the queries every release – they just work.

Here are the steps in more detail:

  1. To create a new release for Current, use the Areas and Iterations dialog and add a new Child Node.
    Open Areas and Iterations DialogOnce created, we position Current as first in the list. The dialog below shows Current and Sprint 1 as a member, indicating that Sprint 1 is the current sprint.
    Insert Current release node into Areas and Iterations dialog
  2. Next, all the queries defined under Current Sprint are modified to use the “under Current” clause. This modification only needs to be made one time when the project template is being configured. Below is a screen shot after modifying the Sprint Backlog query.
    Update TFS work item query to use Current release node.
  3. When moving from one sprint to the next, simply change the sprint hierarchy so that the new sprint (Sprint 2 for example) appears below the “Current” release and the previous sprint (Sprint 1) is returned to the correct release structure.

With these changes in place, the queries will just work as is when you transition from one sprint to the next.  Furthermore, this technique is valid and expected to work for TFS Preview, TFS11, Microsoft Visual Studio Scrum 1.0, and MSF for Agile.

(Note: Releases are not required, you can just have a parent node (Current) that appears anywhere in the hierarchy and move the Current Sprint below that – with corresponding queries to match.)

Join the Conversation

  1. Mark Michaelis


Your email address will not be published. Required fields are marked *

  1. How do you account for branches? Since we use a check-in policy to ensure that check-ins occur on the proper branch, and there is a correlation between branch and iteration path, I’m curious if you’ve seen or done something similar.

  2. Great post Mark. We’ve implemented it and the the Excel workbooks work well with the approach. We take the same approach with a future iteration and we move seemlessly between sprints.



  3. How do you recommend populating the Iteration Path in the work item. Do you update it to “IntelliTrec.ARCGIS\Current” for when it is the current sprint, then change it back to the actual Release/Sprint after the Current Sprint is over.

    1. Hi Kimberly,
      I assign the work item iteration path to the specific sprint (not just to ..\Current). That way, I don’t need to change every work item. I just move the sprint from under ..\Release to ..\Current. At the end of the sprint I move it back to ..\Release and move the next sprint under current.

  4. Excellent workaround. This is so much better than updating queries every new iteration. Thank you!

  5. A very efficient way to get the information we need, while TFS team implements some kind of dynamic filter. I like it because if you have many queries there’s no need to ever change them. We have created three iterations of 1st level: “Done”, “Current” and “Planned”, and then move each sprint throughout these iterations. Very good job! Thank you! ;)