Is it possible to create new backlog item as a Task standalone without parent (not under user story or bugs). Sometime only single task is small to be a user story.
Not exactly on the backlog. It's not designed to support orphaned tasks. However, you can easily create a task without a parent in the Queries interface. Just go to Work -> Queries, click New -> Task (upper left), and there you have a task. You can then view it in the sprint iteration beneath "Unparented". You can also view them in Queries, of course. You won't be able to see them in the product backlog, though, since it only shows parented items.
Related
Our developers work from Sprint Boards, and they drag tasks into Closed stage. However, this leaves stories as New / Active when all tasks are done, and there is no easy way to know if story has all tasks completed
Is there a way to auto-close story when all tasks are done (without any additional plugins)?
Is there a way to identify what stories have all tasks closed/resolved?
Work items have independent states. Most of our experiences will not include automatic updates based on hierarchy. Either based on parent to update child or based on child to update parent.
You could refer Taylor's comment in this thread--User Story status closed but child Task still active?
Even though there is not any build-in solution, you could use some 3-rd party tool to auto change parent states: TFS Aggregator .
Another sample using Webhook to handle this. Detail solution here: https://twitter.com/danhellem/status/1173614918333030400?s=20
which leads to: https://github.com/microsoft/azure-boards-automate-state-transitions
There are many presentations that talk about being able to synchronize work between the management and the implementation level in Visual Studio Team Services. That is, a manager can create a set of Epics of Features and the children of those (User Stories or Work Items) will reflect the goals of the project.
However, I could not find a way to re-order parent work items (Features) so that this re-ordering of their Backlog Priority gets updated in the backlog/board that contains children work items (User Stories).
So, my question is: Is it possible to re-order Epics/Features in VSTS and get their children (User Stories) get automatically re-ordered as well?
The only progress that I have done is turning on "Show parents" in the User Story backlog and being able to re-order parent Features in the User Stories backlog. This does not affect the order of the User Stories in their backlog or on the Kanban board.
No, it's not supported.
The priority or stack rank reorder only affects on the the Backlog/board of the specific work item type itself. That means you need to separately set the order of Epics/ Features/Stories.
So, if you want to do actions against the child work items based on their Parent order, then as a workaround just as you mentioned, you could "Show parents" in the Parent backlog and Expand the level (click the Plug + icon) to show them. See below screenshot for example.
However the requirement sounds make sense, actually there is a similar User Voice submitted here to suggest the feature, you can go and vote it up to achieve that in future, VSTS team is listening your voice.
How is it possible to change the area that a product backlog item resides in including it's children? I know that I can open a backlog item and simply change the area, and it will be moved. But any in progress or to do tasks that are linked as children of that backlog item will be lost.
What I want is to be able to change the area as you can change the iteration path by moving it entirely to another area, including its linked childeren items. Otherwise, after a move, I need to alter every single task that is left behind.
Is there an easy way to do this?
It is not the most pretiest way to solve it, but it seems to work. What I now do is expand all items in the general backlog. Then I select all the items and edit them all at once.
This way, I can change the area of the backlog items, and all included tasks that are linked as children. This also means that items that are "done" will be moved to another area.
I don't really understand why this is not made easier, and that other people do not encounter this problem. When working with teams, you can't prevent that backlog items (and linked children) need to be moved between them.
This is no default feature or setting in TFS Sever which could achieve what you need.
You need to do this with help of some 3-party tool such as TFS Aggregator (Web Service)
Some uses cases:
Update the state of a Bug, PBI (or any parent) to "Done" when all
children get moved to "Done" or "Removed"
....
It's also suitable for updating area filed for all children. You need customize rules through the extension.
More related tutorial for TFS Aggregator, please refer this link.
I am trying to understand how to operate Team Foundation Service with scrum methodology. A problem of mine is:
I have a Product Backlog Item and five Work Items. Three Work Items are assigned to the backlog item and are displayed on the "board", so I can move them in between to do, in progress and done. Two other ones are not being displayed on board. Why? How can I assign them to the backlog to be able to see them on board?
This is not supported by the board, unfortunately. For the tasks to show up on the board, they must be a child of either a PBI or a Bug (or any work item that is in the Requirements category).
I was able to accomplish this by creating a new task, then link the backlog item to the task using the ID# as a Parent item (it also works by adding as a Child item as stated by #JamesTupper). After saving, the item showed up on my board. Hope this helps!
I have accomplished this by creating a "Project Tasks" spike to get these types of tasks to show up on the board in their own lane. You can also estimate this SPIKE, if you want to make sure this work is counted in your velocity, but I tend to treat these as "overhead" tasks that don't deliver value, so I don't report on them in our velocity.
If the tasks are related directly to the value you are delivering (for example, you are performing an investigation spike to determine how to estimate a user story) you should definitely estimate that PBI, give it points, and then add those tasks to that PBI.
Either way, adding the tasks as children of a PBI is the way to get them on the board.
If I understand your question correctly, search for the work items that you want to assign to a backlog item. Right click on the task task and then choose 'Link to an Existing Work Item'. Choose parent for the link type and make sure that you know the work item ID of the back log item and enter that in the work item ID. Press ok and then save the task item in the lower part of the web page.
That worked for me.
I am working on a project that is using the Agile template with TFS 2010 and I'm trying to decide when I should assign an Iteration to a task. At the moment I have a bunch of User Stories and these User Stories have been assigned an Iteration. I've then created Tasks for each User Story and linked them.
So, my question is should I assign an Iteration to the tasks even through the User Stories have already been assigned an Iteration? And what should I do about "general" tasks that are not really associated with a User Story? For example, I could create a task that involves updating references for controls or performing a code review. Should these be assigned an Iteration and is it worthwhile managing two types of tasks, i.e. those assigned to User Stories and those that aren't?
Iteration is to be set when your team is committed to work on these tasks. If after reviewing the tasks you decide to defer some, then set the iteration to a later sprint.
An excerpt from MSF for Agile Software Development v5.0 on MSDN:
You can assign the area and iteration fields to most work items based
on a process template for Microsoft Solutions Framework (MSF). You
specify values for the area and iterations fields when you create a
work item or during a review of the product or iteration backlog. If
you defer a work item to a later time, you should change its iteration
accordingly.
And from the work item definition guide:
In the Area and Iteration lists, click the appropriate area and
iteration, or leave these fields blank to be assigned later during a
planning meeting.
Regarding the general tasks, there are special work item for this such as Issue (Agile) and Impendiment (Scrum).
You should definitely check out this resource, it's a presentation by A.Bjork that presents with a way to deal with what you 're after.We tend to assign UserStories to future Iterations, and before an iteration starts, at the time 'planning poker' takes place - we generate & assign the Tasks to the team.Doing so is vital, for TFS to keep a proper tracking of your efforts: the only Work Item where 'hours' are inserted is the type 'Task' - so this is what feeds the Burndown charts that show how effective you work. If you add another Task to a team-member during the sprint, that would be perceived as 'unplanned work' by TFS (simulating an interruption!) and will mess up the calculations for your Team's velocity.Try breaking your long-running Tasks into smaller ones, that shall fit into each sprint. At worst, for example if you have a huge refactoring Task, you can make several child-Tasks assigned to each sprint and then have the umbrella-Task assigned to the last iteration - where your refactoring is completed.Apart from time-tracking (which is solely based on Tasks) you need to also add into your iteration backlog all other work items that are important for the sprint, so you 'll be able to track in the future when each Issue, User Story etc was considered.