Creating Queries - Token for Current Iteration
When creating a work item query, you are given the option to select the iteration path for which the query is to return results for. It will be fantastic if a token was provided such as [Active Iteration] and you can specify the active iteration manually, or TFS calculating it via the Start/End dates
Simplifying the user experience
Add @CurrentIteration variable to TFS so your team queries know which teh current sprint is like @Project or @Me
Since we can detect what the current iteration is for a team - it would be nice to be able to build work item queries that continually changed as the iteration changed - an @CurrentIteration filter would be fantastic!
TFS Current Sprint Macro for query builder:
If i have an Iteration tree like
ProjectName -> Sprint Number -> Sprint 80 -> Reports
I would a macro that allows all queries to change sprint automatically.
ProjectName -> Sprint Number -> "CurrentSprint" -> Reports
Is the change done yet ? It was more than a year ago now...
Alex Scott commented
If you change your iteration path from Sprint 1 to Current, all items in Sprint 1 will automatically move to Current. When you rename Current back to Sprint 1, all items are moved back into Sprint 1 and you are now ready to rename Sprint 2 to Current. Works great when you manage sprints in the iteration path. All your current sprint queries never have to change from /Current. We moved away from managing our sprints in the iteration path and now we realize we traded one set of problems for another.
On January 11, 2012 11:49 p.m Visual Studio team (Product Team, Microsoft) wrote: "We have heard this feedback more often, and is something we would really love to do."
415 days ago.
Lambros Vasiliou shared this idea · Oct 4, 2011
514 days ago.
How can the Visual Studio Team release a feature with such a flawed design?
I think we need a uservoice "idea" to improve uservoice satisfaction. If we create it today we might get satisfaction in 600 days.
Stu Miller commented
Here's one suggestion for this issue:
Stephen Hewison commented
Definitely needed. It makes current iteration reporting useless without it.
Adding a new Field such as "Query Name" (or "Query") can alternatively resolve the need for defining new tokens.
For example: I would manually edit a Query named 'Active Iteration' periodically, while having in multiple Queries a Clause with Field set to "Query", Operator set to "Satisfied" and Value set (from a drop-down list) to "Team Queries\Current Sprint\Active Iteration".
I think such feature would increase the Query flexibility significantly, and maybe simpler for implementation (than user-defined tokens)?
I like current token, would save me from editing the query every week.
Having iteration start and end dates available for query and as a column option would be massively beneficial.
Terry Short commented
I also would prefer an explicit Current Interration/Sprint that the Scrum team/master sets and all the current sprint queries can then use that.
Phil Spokas commented
I recommend *not* having TFS calculate this automatically, but rather the Scrum team/Scrum Master make an explicit declaration about which sprint is *current* and exactly when. There's too much variability in real life over when the current sprint is actually current at sprint transition and planning time.
It seems that it shouldn't be terribly hard to do since the Team Project Dashboard shows the Current Iteration. Use that code wherever the system variables like @Project are created. Of course, I'm probably drastically oversimplifying this since I know nothing about how VS is developed.
A useful important thing also would be a query variable like @CurrentIteration for workitem queries. In my opinion for Scrum a minimal requirement.
This feature would be very beneficial, especially when you look at the opportunities for leveraging the dashboard type views on a project portal.
Andy Bray commented
Agree - this would save having to update all of the 'current sprint' queries every couple of weeks which is a bit clunky.
Thanks for your suggestion.
We have heard this feedback more often, and is something we would really love to do. We had to make the tough decision to put it below the cut line when we compare it to the other work we need to get done for Dev11.
But it is definitely something we consider for the future.
Ewald Hofman (TFS Program Manager)