When I move a user story from one iteration to another in TFS 2010, I then have to update the iteration in each child task manually. Otherwise it retains the previous iteration value and the various reports and filters don't produce the intended result.
Can anyone recommend a method, or extension, that will either keep the task iterations synchronised to their user story iterations automatically, or failing that, do it for all user stories/tasks in a product on demand?
Try TFS Aggregator
Example Uses
Update the state of a Bug, PBI (or any parent) to "In Progress" when a child gets moved to "In Progress"
Update the state of a Bug, PBI (or any parent) to "Done" when all children get moved to "Done" or "Removed"
Update the "Work Remaining" on a Bug, PBI, etc with the sum of all the Task's "Work Remaining".
Update the "Work Remaining" on a Sprint with the sum of all the "Work Remaining" of its grandchildren (i.e. tasks of the PBIs and Bugs in the Sprint).
Sum up totals on a single work item (ie Dev Estimate + Test Estimate = Total Estimate)
You can export all the work items in Excel and mass edit them into the new value.In order to do so, you need to maintain a work item query and have all WIs within one Team Project. Typically this is an activity that goes down during planning poker when a new iteration is about to start.I found this presentation by A.Bjork very useful on how to do (among other things) tasks like that.
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 ...
In my Company we are using Team Foundation Server 2012 and Agile as Project Template. We are still learning how the Board and the Backlog show Tasks within User Stories and I realized that "Orphan" Tasks are not shown in these cases...
I made an query to solve the problem about the "Orphan" tasks but I realized that the same issue is happening when a User Story and a Task have, for some reason (maybe someone assign it to a User Story after creating it), a different iteration path... the tasks are not shown in the Backlog or Board.
Is there an automatic way to make tasks having the same iteration path as their parents? How can I make a query to show tasks whose User Stories have a different iteration path as them?
Thanks a lot in advance!
Well. After more researching I have realized about two thing:
- It is not needed to do this in order to show the Tasks in the Board/Backlog because, if the User Story contains tasks that are defined in different iterations, the User Story will be shown in the different iterations, repeated, but only with the tasks belonging to the iteration.
- If someone still wants to create the query, maybe to reunite User Stories, the solution is creating a new Query of the type Work Items and Direct Links and change the following parameters:
* In Filters for top level work item Add a new clause And Iteration Path = IterationA
* In Filters for linked work items Add a new clause And Iteration Path <> IterationA
* In Filter options Types of links select Return selected link types and check Child and Parent.
Unfortunately there is no way, so far I know, to do it automatically for all iterations so you have to do a Query of this type for all iterations.
I have some problem with tfs. I created iteration somename and than I created some tasks. They are active and in classification -> iteration field i used somename. But I looked at Backlogs and tasks in my newly created iterations (which is current iteration) didn't show up. Could you tell me how can i view this tasks on backlog and board?
P.S. I have assigned all the tasks to the teammates, I filled the capacities and filled original estimates to every task. And I would like to see work details and burndown.
Does the tasks have as parrent a Product Backlog Item and does this PBI belong to the same iteration as the tasks do? Maybe this is the problem.
After stopping our current sprint we need to move a lot of items to the next sprint. This raised some questions where we, as new scrum users, did not find an answer to.
We understand that we need to create new PBI's and move the tasks which are marked as To Do to that newly created PBI. (And what happens with In Progress tasks, how should they be moved? Just move them, or close them and create a new one for the new sprint?)
One of the discussions raised was how we should name our PBI's because the management wants it to be clear enough for our customer who has read access to our Product Backlog and the Sprint Backlog.
From a developer point of view, PBI's such as "Research feature A", "Implement feature A", "Polish feature A", while our management believes the PBI's should be named "feature A (part 1)", "Feature A (part 2)", "Feature A (part 3 - END)" because neither they nor our customer understands our PBI's and they want to know when they can start testing feature A. Our management basically just wants to print out the Sprint Backlog query and pass that on to our client as a way of showing what has been done.
A second, less important, question is: how should we properly use the area path? If we have a feature A, it makes sense to us to create a feature A area path and use that as a common identifier for all PBI's and tasks which are related to it. But what should we do with work items that are related to multiple features (and thus area paths)? We are afraid we would end up with lots of area paths and the list would get cluttered. We can't remove area paths because bugs might be filed for it, or we need to pick it up at a later stage. Also, what if a feature has the be implemented in multiple versions of the application?
We understand that we need to create new PBI's and move the tasks
which are marked as To Do to that newly created PBI. (And what happens
with In Progress tasks, how should they be moved? Just move them, or
close them and create a new one for the new sprint?)
You don't need to create new PBIs for each sprint! A PBI stays in progress until all its child tasks are done. Its iteration may move forward to the next sprint (e.g. "Release 1\Sprint 1 > Release 1\Sprint 2" or just stay on an upper level ("Release 1"). Tasks don't get moved to another PBI, but do get progressed to the next sprint.
This will resolve the naming issue, as PBI's wouldn't get the "part X" suffix. A possible name for PBI is "Feature A - infrastructure" or "Feature A - UI". So its child tasks may be named "Feature A - infrastructure - design", "Feature A - infrastructure - implementation" and "Feature A - UI - design" and so on.
A second, less important, question is: how should we properly use the
area path?
If Iteration is a chronological point in time, so Area is used to represent a logical module of the product. E.g.:
|-Server
| |--Database
| |--Web Services
|
|-Client
| |--UI
| |--Navigation
|
|-Configuration
|
|-Documentation
|
|-Installation
| |---Client
| |---Plugins
|
Don't overuse area definitions. The list should be clean and easy to understand.
what if a feature has the be implemented in multiple versions of the application?
Create another PBI and assign it with the same Area path but different Iteration path.
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.