Recently I was at a customer who used the MSF for Agile Software Development template in Team Foundation Server 2012. As he was doing Scrum with this template he had the need to show Bugs in the Product Backlog view as well. Just like User Stories he wanted to plan bugs in a specific sprint.
Seems logical but Bugs did not show in the Product Backlog view.
When I checked a little bit further, it seems that the MSF for CMMI template only shows [Requirement] work items and the Scrum template showed [Product Backlog Item] and [Bug] Work items.
The most obvious option was to press the [Create Backlog Query] button on the Product Backlog, but that only gave the possibility to save the underlying query in the Team Project.
Because I could only find some forum answers I decided to create a blog post on how to modify the Product Backlog view in the TFS 2012 Web Access Client. It is somewhat more complicated than one would expect.
Work Item Types and Categories
Before I start my explanation on how to modify the Product Backlog, I want to explain a little bit about the underlying concepts.
Since TFS 2010 there is the notion of Work Item Categories. A Work Item category is a functional grouping mechanism to group Work Item Types. In TFS 2012 this concept is expanded and we know the following categories
- Bug category
- This contains work item types that are considered a Bug. When you use Test Manager it creates the Work Item Type that is the default of this category.
- Code Review Request / Response Category
- This contains work item types that are considered as the ones to use when performing Code Reviews. When you submit a Code Review Request in VS 2012, the default work item type for this category is created.
- Feedback Request / Response Category
- This contains work item types that are considered as the ones to use when using the Feedback tools in VS 2012. When you submit a Feedback Request in VS 2012, the default work item type for this category is created.
- Hidden Category
- This contains all work item types that are used in the backend but will not be displayed in the Web Access Client and cannot be created when choosing [New]. For example [Code Review Request], [Shared Step] or [Feedback Response]
- Requirement Category
- This contains all work item types that are considered as a requirement. In Scrum this is the [Product Backlog Item] and in CMMI this is the [Requirement].
- Shared Step Category
- This contains the work item type that is considered to be a Shared Step
- Task Category
- This contains the work item types that are considered to be a task. When you click the [+] sign in the Web Access Client on a Requirement or PBI, the default Work Item Type in this category in created
- Test Case Category
- This contains the work item types that are considered to be a Test Case. When using Test Manager and adding new Tests, the default work item type in this category will be used.
To edit categories you must use the witadmin tool to export and import the category definitions (http://msdn.microsoft.com/en-us/library/vstudio/dd273721.aspx)
The categories XML looks a bit like this
As you can see, a category can contain multiple work item types, and always 1 default type.
A category requires some fields to be present on a work item type. For example, the [System Information] field and the [Steps to Reproduce] field are required for any work item in the [Bug Category]
More about categories you can find on MSDN: http://msdn.microsoft.com/en-us/library/vstudio/dd695775.aspx
Changing the backlog
Now we know a bit more about categories, we can dive into the Product backlog. As I mentioned at the start of this post, the button [Create Backlog Query] only gives you the possibility to save the backlog query but not modify the query that is used for the backlog. Still, this is very useful information, because it provides us with valuable information about the data that is used in the Product Backlog.
As we can see in the query for the Agile Template, the product backlog shows us all Work Items from the Requirements category in the states New, Active and Resolved.
We need to perform several steps
- Change the categories for this Project so that the Requirement category also contains Bugs
- Change the Bug Work Item so that it contains all the required fields of the Requirement category
- Change the Agile Process Configuration to change the output columns and the “Add Panel”
- Look at the different states that are used in the query
I will work out an example where we are going to change the Product Backlog of an MSF Agile project so that it shows User Stories and Bugs and show the Area Path in the output columns.
Change the categories
Export the categories of the Agile Project by using the following command
Change the Requirement Category element so that it includes [Bug]
Import the categories of the Agile Project by using the following command
Change the Bug Work Item so that it contains all the required fields of the Requirement category
When you now open the Web Access Client it shows you an error
TF400917: The current configuration is not valid for this feature. This feature cannot be used until you correct the configuration.
This means that there is something wrong with the configuration. The categories configuration however is fine. The error is located within the [Bug] Work Item. This item does not contain the fields that are necessary for the Requirements field. Add the Story Points field (exactly the same as the one on User Story) to the [Bug] Work Item.
Change the Agile Process Configuration to change the output columns and the “Add Panel”
To change the output columns in the product Backlog, open a command window and run the following command
Open the XML and change the following element
Run the following command to import the changes back into TFS
This results in an adjusted “Add Panel” and adjusted output columns
Look at the different states that are used in the query
The states that are used in the query, are extracted from the meta states that are defined for the project.
Run the following command
This file contains information about the meta states that are used.
When you follow these steps, you can modify how your Product Backlog looks and works !
Hope this helps !