How to deal with the current sprint/iteration in TFS queries?

During my work as an ALM consultant, I get a lot of questions about how to define a stable iteration (and area) path structure in your TFS Team Project. I thought it would be helpful, to share with you one of the things I always discuss with teams that are working with the SCRUM or Agile process template; dealing with the current sprint/iteration.

So what’s the problem?

Once teams are working with the Agile planning tools of TFS, most of the (shared) work item queries they are working with, are related to the current sprint/iteration they’re working on. Think of a query which shows us the open defects of the current iteration. Or take for example the set of default SCRUM queries that are delivered when creating a new Team Project based on the SCRUM process template.

Because of this overbalance of sprint/iteration related queries, it is important that the defined iteration path structure and work item queries can easily deal with the fact that the current sprint/iteration changes over time. But how to achieve this?

What’s delivered by default

Let’s first look at the iteration path structure and queries that are defined in the default SCRUM and Agile process templates.

SCRUM process template

Looking at the default iteration path structure that is delivered by the SCRUM process template, we see an iteration path structure wherein the release nodes are created directly under the root node and the sprintnodes are created directly under the release node, as shown in the figure below.

Looking at the configuration of the current sprint related work item queries, that are delivered by default, you will find “Scrum/Release 1/Sprint 1” as the default value for the Iteration Path clause in the different Work Item Query definitions.

Agile process template

The Agile process template configuration is slightly different. Looking at the default iteration path structure, note that the different iterations are created directly under the root node.

Looking at the current iteration related queries that are created by default, you will find “AgileIteration 1” as the default value for the Iteration Path clause in the different Work Item Query definitions, as shown in the figure below.

Till now, everything looks fine, but is it? Looking at the effort that is needed to maintain the default configurations, we will see that the default configurations are not as efficient as we would think upfront.

So what’s the problem?

Let’s first start with the effort that is needed to maintain the current sprint related queries of the SCRUM process template. To make these current sprint related queries work for a new sprint, you have to change their iteration path value each time the current sprint changes. Taking for example a current sprint change from Release 1/Sprint 1 to Release 1/Sprint 2, this means that you have to change the value of the iteration path clause for all current sprint related queries (at least the default 5) to Scrum/Release 1/Sprint 2. For one sprint this may be acceptable, but in case of having 26 sprints each year and multiple teams working this way, maintaining the default configuration leads to a significant waste of time.

Even worse is the effort that is needed to maintain the current iteration related queries of the Agile process template. Instead of having at least 5 work item queries, you have to change at least 10 queries each time the current iteration changes, as shown in the table below. Hmmm, not as efficient as we would think upfront.. But how to make this eassier?

How to solve?

Solution 1 – Implementing a placeholder node in the iteration path for the current sprint/iteration (prior to VS2013.5)

The first solution I have, is relevant for all versions of Visual Studio prior to VS2013 Update 5. To implement this solution you have to execute the following steps:

1. The first step you have to execute, is that you make the iteration path structure more resilient. This can be done by creating an extra level of three new nodes just above the sprint/iteration nodes level in the iteration path structure; 1-Previous, 2-Current, 3-Next. For the SCRUM process template this means that you have to create the nodes between the release and the sprint nodes, as shown in the figure below. For the Agile process template this means that you have to create the nodes just under the rootnode.

After you have done this, you have to distribute the sprint/iteration nodes under the newly created 1-Previous, 2-Current and 3-Next placeholder nodes. To achieve this, drag the previous sprints/iterations under the 1-Previous node, the current sprint/iteration under the 2-Current node and the upcoming sprints/iterations under the 3-Next node.

2. Secondly change the iteration path values of the current sprint/iteration related queries so that the value of the Iteration Path clauses relate to the just created 2-Current placeholder node.

After executing both steps, when the current sprint changes, you just have to simply drag the “old” current sprint under the 1-Previous node and the “new” current sprint under the 2-Current node. Wow, what a timesaver!

Solution 2 – Making use of the @CurrentIteration query token (since VS2013.5)

The second solution is based on a new query token which is introduced since VS 2013 Update 5; @CurrentIteration. Once upgraded to VS2013.5 or VS2015 (including your TFS server), this new query token returns the current iteration based on today’s date and can be used as value in the Iteration Path clause.

The solution is very straightforward: just update the current sprint/iteration related queries to make use of this new query token and all the queries are automatically updating their content based on the specified begin and end date of the sprints/iterations you configured. Below an example of this new query token. For more information about this new query token, see GitHub Codespaces · GitHub
.