Powershell script to make use of @CurrentIteration query token in TFS queries

Since the introduction of Visual Studio 2013 update 5, a new query token (@CurrentIteration) is available to automatically identify the current iteration of your iteration path, based on today’s date. By using this query token in queries that are related to the current iteration/sprint, you will save a lot of time in managing those queries (as mentioned in my previous blogpost). However, once upgraded to Visual Studio 2013 update 5 or higher, you have to manually update your queries to make use of this new @CurrentIteration query token. This may cost you a lot of time. For that reason, I’ve made a powershell script to automatically implement the @CurrentIteration query token for the shared queries of your team project (see the code below or the attached zip file). After downloading/unzipping, just specify your own values for the different variables and run the powershell script. EnableCurrentIterationQueryToken  

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

Changing the Default CheckIn Action in TFS

For some weeks ago, I had a team ask me if it was possible to change the default CheckIn action for relating a work item to a check-in in TFS. After finding different solutions, I thought it would be helpful to share with you the different options I found. So what’s the problem? As you will know, when you want to relate a work item with your check-in in TFS, you have to choose between two CheckIn actions: Associate or Resolve. The first one, Associate, is used to just link the work item with the future changeset. The second one, Resolve, also automatically closes the work item on check-in. By default, your Visual Studio client will select the Resolve action on check-in. For some situations this is very helpful. However, when you want to use the Associate action most of the time, it is very annoying and inefficient to change the CheckIn action each time