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.

Figure 1 - Default current sprint related queries - SCRUM process template
Figure 1 – Default current sprint related queries – 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.

Figure 2 - Default iteration path structure SCRUM process template
Figure 2 – Default iteration path structure SCRUM process template

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.

Figure 3 - Default Iteration Path clause - current sprint SCRUM queries
Figure 3 – Default Iteration Path clause – current sprint SCRUM queries

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.

Figure 4 - Default iteration path structure Agile process template
Figure 4 – Default iteration path structure Agile process template

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

Figure 5 - Default Iteration Path clause - current iteration Agile queries
Figure 5 – Default Iteration Path clause – current iteration Agile queries

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?

SCRUM template Agile template
  • BlockedTasks
  • OpenImpediments
  • TestCases
  • UnfinishedWork
  • WorkInProgress
  • ActiveBugs
  • ActiveTasks
  • BugTriage
  • CompletedTasks
  • OpenIssues
  • OpenTestCases
  • OpenUserStories
  • ResolvedBugs
  • UserStoriesDelivered
  • UserStoriesWithoutTestCases

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.

Figure 6 - Extra level of placeholder nodes

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.

 

  1. 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.
Figure 7 - Example of query which relates to the Current placeholder node
Figure 7 – Example of query which relates to the 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 https://www.visualstudio.com/en-us/news/2015-mar-10-vso.

Figure 8 - Example of use of @CurrentIteration query token
Figure 8 – Example of use of @CurrentIteration query token

2 gedachten over “How to deal with the current sprint/iteration in TFS queries?

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *