We want to set the iteration path to a default our tree structure is as follows
Root
v10.1
v10.2
v10.3
So we want it to prefill with the latest (v10.3) on creating each new work item.. and in future when we add v10.4 it would then pre-fill that instead.
Are either the default or dynamic update to new iteration paths possible?
It is not possible to have a rule in your work item to default the iteration path.
That said, in TFS11 iterations are first class citizens: they have dates.
The product now knows what is the current sprint/iteration for a team. If you create a new work item in the context of that team it will default the iteration path with that iteration.
See more on teams in TFS11 at http://msdn.microsoft.com/en-us/library/hh528603(v=vs.110).aspx
Related
I am trying to query items(Features, User-Stories, Tasks) that were moved from current iteration to a different iteration (like next iteration), for our team to see which items we didn't accomplished in the current iteration.
Is there a way to do this in TFS?
My TFS Version is 2017 Update 3 RTM
You can track the progress of requirements, bugs, and other work to be completed in the current sprint using the #CurrentIteration macro.
Any item assigned to a sprint which corresponds to the current iteration path for the team will be found. For example, if a team is on Sprint 5, then the query will return items assigned to Sprint 5. Later, when the team is working in Sprint 6, the same query will return items assigned to Sprint 6.
Note
For the #CurrentIteration macro to work, the team must have selected
an Iteration Path whose date range encompasses the current date. For
details, see Define iteration paths (aka sprints) and configure team
iterations. Also, queries that contain this macro are only valid
when run from the web portal.
See also Client restrictions on the use of the #CurrentIteration
macros later in this article.
After exclude those current iteration items, you should be easy to determine those items you need and then you can check the history of these work items which the previous iteration path they are.
One tip is to have a habit of tagging work items with sprint name eg. "P27" from which they were moved to an other sprint. Then it is easy to query. Even though this requires some manual routine tagging ...
I am getting started with TFS 2015 and I need to know how to make a query that returns all of the work items for the current iteration for the current team. I have Iteration Path Under #CurrentIteration and Work Item Type = User Story, but I can find a macro similar to #CurrentIteration that would get the current team or team area. How do I filter out the stories for all other teams?
It's not able to do this through a query. You could check the Query macros or variables, use the macros described in the following table to filter your queries based on specific fields. There is not any team area related macro.
Besides, actually as far as I know work items can only be assigned to specific people not groups. However, for a workaround. By assigning a work item to a specific area path you basically assign it to a team. If you use the area path for something else today, you can also use another string field in the work item that specifies the team.
(https://www.visualstudio.com/docs/work/scale/portfolio-management)
So you could use Area Path to do the filter.
This won't directly solve your problem but you can use 'Assigned to' 'In Group' and then use a user group e.g. '[Home]\Team NI'. This will return tickets assigned to the group or group members but assumes the tickets are assigned appropriately (rather than being unassigned). YMMV but I've found it useful at times to get around this limitation. TFS Azure 2019 now also includes #TeamAreas - which is helpful unless you have multiple teams using the same areas.
I am working with the VSO REST API and have a question on how Iteration and Area ID's are assigned. Specifically, why is it when I assign a work item to the root Iteration or Area the ID that is returned for the WIT is not returned when I query the classification nodes?
For example, imagine I have this hierarchy when I query /DefaultCollection/my project/_apis/wit/classificationnodes?$depth=2
My Project: id=1234
Area 1: id=5678
Area 2: id= 9012
And I then query for a work item using /DefaultCollection/_apis/wit/workItems/1?$expand=all
If the work item is in Area 1 or Area 2, the System.AreaId field is as expected (5678 and 9012, respectively). However, if I assign the work item to My Project, the System.AreaID is some value that is not included when I query for all classification nodes. There appears to be some kind of relationship between the ID's as they are serial (e.g. the ID returned by the classification node query is 1232 for the area and 1233 for the iteration), but I can't seem to find a way to query to get the actual ID returned by the work item query.
In fact, not only is the ID returned for a work item not present when I query for all classification nodes, if I assign the work item to both the root iteration and area, the ID returned for both fields is the same value that is not included in the classification node query.
What I need is a way to look at a work item and figure out the area and iteration it belongs to. I could probably do something with the path field strings that are returned, but that seems error prone since users can change them.
****Edit****
The above appears to be a bug in the REST API, but for anyone who comes across this post there is a way to get a usable iteration ID by the path string. Structure your REST call like so:
/DefaultCollection/[Project Name]/_apis/wit/classificationnodes/iterations/Release 1/Sprint 1 (etc.)
I have never done this with ID. I only use the path. In the classification service you can get the node by path easily enough.
For example, using the REST API - you can access this url to get the data about a specific iteration:
/DefaultCollection/[Project Name]/_apis/wit/classificationnodes/iterations/[Release X]/[Sprint Y]
Note that trying to access the default iteration path (the project name instead of a specific iteration) will return an error:
/DefaultCollection/[Project Name]/_apis/wit/classificationnodes/iterations/[Project Name]
will give :
{"$id":"1","innerException":null,"message":"VS402485: The node name is not recognized: [Project Name]","typeName":"Microsoft.TeamFoundation.WorkItemTracking.Server.Metadata.WorkItemTrackingTreeNodeNotFoundException, Microsoft.TeamFoundation.WorkItemTracking.Server","typeKey":"WorkItemTrackingTreeNodeNotFoundException","errorCode":0,"eventId":3200}
So if you do batch work, you have to filter those before querying the api.
There are three ways of identifying an Area (everything I post equally applies to Iterations also). The Path (string), the ID (int) and a Guid. each of them are used in different ways, and have different ramifications.
For example renaming an Area, does NOT change it's identity, therefore does not update a work item (the path returned for in a workitem is dynamic).
It is also possible to delete and recreate and identical path, but it will have a different ID.
The GUID is used primarily for the Excel Reports (such as are parent of the SharePoint portal)
Depending on how you want things to react determines the appropriate element to use.
I have not seen any issues with the ID that you mention, and if you could create a simple repro, I would be glad to look at it.
david(dot)corbin(at)dynconcepts(dot)com
Is there any option to configure TFS backlog tree items I'v marked bellow?
EDIT:
I would like to create target structure that looks like:
Current
Future
Experimental
Other
It sounds like you essentially want to add extra metadata to sprints. Unfortunately this is not currently possible (the only metadata supported today is Name, Start Date, End Date).
What some people have done in the past (prior to the Agile Planning tooling), is introduce a Work Item Type called Sprint, then they can define custom fields against it and surface the data in WI Queries.
I suppose you could define a new WI Type and try to associate it with Iterations, but I wouldn't recommend it.
There is no way you can configure the tree on the left panel but since you are using TFS 2013 (also available in 2012) you can use Tags to mark the backlog items that are Experimental or Other.
Add tags to work items to categorize and filter lists: http://msdn.microsoft.com/en-us/library/dn132606(v=vs.120).aspx
Other option is to add a custom field to work items which is not recommended as its painful when you want to upgrade later on.
Modify or add a custom work item type: http://msdn.microsoft.com/en-us/library/hh409273.aspx
Is there a way in TFS in VS2010 to specify that a particular iteration is the current one, and then return that for use in queries similar to the way #Project works? If not is there a way to do sub-queries in TFS work item queries?
Looks like Microsoft listened. #CurrentIteration is being added as a token.
That’s great, of course. When looking to write a query against the current sprint, however, you are in danger of losing sight of unclosed work items in previous sprints. When you reach for #CurrentIteration, you probably just mean “all unfinished work that has been committed to a sprint.” If you filter to a single sprint, you’ll miss any stragglers you failed to close or move forward from previous sprints.
Consider using the following pattern, where “ScrumOfScrums\Release 1.0.0.0″ is your backlog path, and all of your sprint paths are children to that:
Filter for work items under your backlog iteration node, but not equal to the backlog iteration node. That will give you all items committed to a sprint.
This will also catch any items that weren’t closed in your previous sprints. Since the goal is to close every item in a sprint before moving to the next one, this query pattern will generally be better than using #CurrentIteration, unless you're looking to find the closed items in the current iteration.
P.S. While this is an old question, it was my top hit when I searched for info on querying the current iteration in TFS.
I'm afraid that there is not such a macro. I personally just have a few "X in current iteration" team queries and then edit those queries to point to the new iteration path at the start of each iteration.
I am going to try using a standard name for the current iteration such as 'Current'. The queries for this iteration would all reference this name. Once the iteration is completed, I will rename it using a naming convention that includes the date for example and the next iteration would then be created with the name 'Current' (or renamed to this if it already exists). The queries would then return results from the new iteration.
- 2010-49
- Current
- 2010-51
I am not sure whether renaming iterations this way will cause any conflicts or confuse the data warehouse for example but this would save on having to create or modify a heap of queries at the start of each iteration.
I would be very interested to hear feedback on this approach!
Query for Sprint in a date interval as shown here:
Team Project = #Project
And Work Item Type = Sprint
And Start Date <= #Today
And Finish Date >= #Today
I have found that Telerik's free Work Item Manager provides an elegant solution to this problem.
Just define your queries as you usually would but leave out any filters relating to iterations (note that this also applies to areas). There is a treeview pane named 'Area/Iteration Filters' that will add extra, recursive filtering based on the iteration (or area) that you select there.
Note that if the pane is not visible then you can enable it via the View menu.