In TFS 2013, for every work item (product backlog item, bug etc.) a task has to be created. So every time a bug is created or a backlog item is added, at least one additional linked task needs to be created.
This makes it quite cumbersome to maintain the system. Is there a way to just create one work item that goes from the backlog to being developed to being tested without having to create additional tasks?
Maybe this could be done via a different process template? I’ve tried both scrum and agile build in templates from Microsoft.
There is a new article on MSDN that addresses this, at least for bugs. It shows how to make bugs act as tasks in TFS. You could theoretically expand it for any work item (although I'm not sure this is advisable).
Related
When checking in TFS under Work\Backlogs\Backlog items, any Sprint, I can see PBIs and linked tasks under them. However bugs I noticed are treated at the same level as PBIs, meaning I can never see a Bug under a PBI, but I can see a task under a Bug.
Is this because the understanding is that Bugs are an occurrence after PBIs are marked as "Done" in a future sprint (since all PBIs should have gone through testing until completely reviewed and accepted).
I'm thinking if this is the logic then Bugs in their own right are like a PBI - a new "Problem" Backlog Item lol.
We are getting confused because we at first wanted to see Bugs under PBIs or Tasks to see what the bug is associated with, but because a bug may occur from an assortment of development done in the future, it's treated as independent on the same level as a PBI. Am I understanding this correctly or is there a way to put bug under a PBI\Task in the backlog when viewing (I know you can link it as so, but I mean for viewing purposes in the backlog). Thanks.
You can configure team settings to set your team's preferences for tracking bugs.
To see Bugs under PBIs, you can select the option Bugs are managed with tasks under Working with bugs tab. See Show bugs on backlogs and boards for details.
On the board settings page, you can configure bugs display behavior.
They can be treated as Tasks, in which case they show as children of PBIs, at the same level as Tasks, and are displayed on the sprint board.
Or, they can be treated as Requirements, in which case they are shown at the same level as PBIs and can have Tasks created underneath them.
It sounds like you currently have the latter behavior enabled, but would prefer the former.
This is configurable at the Team level. You can configure one behavior or the other, but not both. This means that for a given team, bugs can either be Requirements, or they can be Tasks. They cannot be Requirements in some situations and Tasks in some others.
Also note that if you've upgraded from an earlier version of TFS, you may have to manually enable the feature, since it required some changes to the process templates that you or your TFS administrator may not have made.
We're still fine-tuning our ALM process using TFS 2015 Update 1 On-Prem. We are using the standard SCRUM template and we display bugs on the backlog, along with requirements. Bugs are reported by the business and go through the same level of analysis as PBIs in that they will contain child tasks:
Now for PBIs, when a tester is testing the PBI and discovers a bug with it (which needs to be fixed as part of this sprint), they will create a bug as a child to the PBI. This keeps them together on the task board. 1 PBI may have many bugs and these may be worked on by different people. These child bugs will have child tasks.
The process mostly works but on the Kanban board, the child bugs are shown, the parent PBIs are not. Why not? and how can I work-around this? I can link them differently but we want them to stay together on the boards.
Thanks
It feels like you're really mixing and matching the two supported scenarios here.
Personally I prefer not to create Bugs as part of the sprint (to me they're not really bugs if they haven't made it out of the iteration) and often it's used as a communication mechanism instead of dev & test working closely together.
If you want something on the board under the PBI/Bug, you could use a Task Work Item (or a custom type) and then use the funky card colouring on the board to look for a tag to signify that it's an in-sprint bug/issue.
Highlight work items based on custom criteria
We are using the scrum template for TFS 2013. Product Backlog Items and Bugs are at the same 'level', so they are both viewed on the backlog and tasks are created as children underneath. Why do PBIs have the states: New, Approved, Committed, Done, Removed, while Bugs have the states: New, In Progress, Done, Closed (which is the same as tasks)?
By treating PBIs and Bugs essentially the same, I would expect that they should have the same states. I'm not sure what 'Done' is supposed to mean as opposed to 'Closed'. I find it confusing that tasks and bugs can be marked 'Done', which is not the same as a PBI marked 'Done'.
I want to change the names of the states for the the PBIs, bugs, and/or tasks to use more consistent naming conventions, but I think I may be misunderstanding what the terms mean.
As Cece mentioned, the out of the box states in Scrum between PBI and Bug are similar. You can use witadmin to change the states of your Bug work item type to match PBIs.
Another option is to use the Kanban board, where you can create a set of columns and map each column to a state of each work item type.
I'm afraid your Scrum Process Template has been customized before. In the default Scrum process template of TFS 2013, PBI and Bug do have the same states: New, Approved, Committed, Done, Removed, while Task has the states: To Do, In Progress, Done, Removed.
The following diagrams show the typical forward progression of PBI, Bug, and Task work items used to track work and code defects for TFS default Scrum process templates:
PBI:
Bug:
Task:
I will be using TFS 2012 and I am confused as to how to setup work items for one job where there are dependencies to the steps needed to get the job completed. For example, if the job first needs to get feedback from the end user, then a developer needs to build the base classes. After the base class work is completed then another developer needs to build the UI components. After the UI is completed then the tester needs to test the work. This job requires multiple people, including more than one developer. Each step cannot be started until the prior step is done. Should all of these steps be different work items or all in one work item? If multiple work items, how do you have the work item show as ready to work on for the next person when the prior work item is completed? If only one work item, then how do you handle the steps for multiple developers? This is one example. There could be the case where we have five developers all dependent upon each other before they can start their own work.
It sounds like you're trying to fit TFS into a formal waterfall process. It probably isn't going to be a good fit in terms of creating Gantt charts for you. In TFS you can use the hierarchy of user stories and tasks to accomplish half of what you want. For the other half you can create the appropriate link type between the tasks.
However, TFS isn't going to give you a Gantt chart like view for them, it isn't designed that way. If you really want to manage projects in this fashion, I'd look at integrating TFS with MS Project and/or Project Server.
As an aside, I would strongly consider just having those people talk to each other rather than relying on a tool.
As long as your performing an agile process your on the right track. Sprints should be based on PBI deployment, not completed tasks. If you find yourself pushing a PBI across multiple sprints, you may want to break-up your PBI. It is better to do this than keep wondering if your team is getting things done, since a group of tasks are moving into a new sprint. Getting a PBI to completed at the end of a sprint should be a key goal for an agile team.
Assign all the tasks needed to complete the PBI. Tasks should be created by the team together. This will help decide how to break down the tasks. I would break down the tasks mentioned into independent tasks based on functional groupings (UI, Business Model, ect). The art of this is to not break them down too much. The team will decide this for themselves. (remember to keep agile and let the team make short-term mistakes if it will help long-term: estimation, scope, quality, ect.
Assign QA tasks with unique names for each PBI. Don't use QA for the task name, it can become difficult to prioritize on the Board view. If you have a test team, let them create there qa tasks. Agile is agile (the team is the team).
The other main key point I learned was don't move on to tasks until the PBI has been planned completely, don't move on to sprinting until the tasks have been planned completely. This will help ensure that once your are sprinting, your not making decisions for that sprint in the middle of the sprint.
I hope this gives you some pointers.
My company uses TFS 2008 with the MSF for Agile process template. We are in the process of planning an upgrade for TFS 2010. We use Scenarios as a container for functional requirements with linked development tasks, bugs, etc.
In order to save the state of a Scenario as 'Resolved' or 'Closed', I would like to enforce that any development task or bug that is linked to the scenario is also closed. With TFS 2008, these are links, in TFS 2010 we plan to use child work items.
I have been reviewing the work item type definition schema and MSDN documentation, but nothing is jumping out at me as a solution to this problem.
Can it be done? Thanks in advance for any help!
What you want cannot be done directly. The saving of a work item is what is called a Notification (rather than a Decision). That means that you can only do TFS API stuff in an event after it is done. You cannot block it.
However, there are ways to get the "effect" of what you are looking for. If you modified your template so that your parent work item (I think you called it Scenario) had the State control (not the field) as read only that would make it so that only clients that don't use the normal Visual Studio controls can change that value. (This could be worked around by your users, but it would take some effort to break the rules).
But there is one more step. You need to get the parent work item to "Resolved" somehow. For this I recommend a open source tool that I wrote called TFS Aggregator. (Or if you plan to "roll your own" you could use the code there as a starting point.)
You can find TFS Aggregatoron codeplex here: http://tfsaggregator.codeplex.com/
It is a great tool for rolling up changes and totals to parent work items. You could put in a rule that when your child items are all "done" to move the Parent to "Resolved".
EDIT: I realize now from your question that you have more than one type of Work Item as a child of the parent Item. TFS Aggregator does not support that right now (but it may in the future). It was written to aggregate tasks to Bugs or PBIs. Still, it would probably be easier to modify the code of that project than to start from scratch.
I don't think this is possible "out of the box". I would recommend you write a query to find cases where the "rule" is violated and handle it that way.
If you MUST automate this - You could use the TFS Eventing Service which can invoke a Web Service.
Set it up for when a Task or Bug is closed - query the database for the Scenario and if all the Task/Bugs are closed - use the TFS API to advance the Status to Resolved or Closed. You could limit the allowed user to make advancement to the account the Service runs under.