Recently, working on a customer, due to the teams and project structure they have, and the reporting needs for this structure (a correct structure BTW), we came to a situation in which dividing the Teams by areas was not so useful, and didn’t helped us in our work item and reports strategy, as you probably already have observed, it is not so easy to create the reports per team with complex structures, as areas are tree views.
So I came up to this article, which helped in creating a Work Item field to define the teams, I found it very useful for this and other situations, being honest, I find this even more comfortable than using areas for this.
For what is coming in this blog post I assume you already have knowledge about how to divide the work between teams in the same Team Project and feel comfortable with TFS Work Items personalization’s. Also this article is entirely based on Team Foundation Server On Premises.
Basically the procedure (go to the article for the details) is:
- Define a Global List for your list of teams.
- Add a new field for Features, Epics (the article doesn’t mention this first two but we also added to them=, Product Backlog Items, Bugs, Tasks and Test Plans. At the end of the day, any Work Item type which can be used to work in backlogs. It is important to define the field with the same name in all Work Item Types, and also be sure to make this reportable as dimension if you plan to use it in Reporting.
- Specify this field to have values from the Teams Global List as allowed values.
- Use witadmin command line tool to export the process, and modify the process to specify the new field as the field defining the team the work item belongs to. (<TypeField refname=»MyCompany.Team» type=»Team» />).
When you go to admin your Team Project (all of this is done at Project Level) you will see the possibility to define the value for the new field for each Team, so the backlogs and panels are filtered correctly.Make sure to specify this value for all of your teams, if you don’t do it, you will receive alerts about your team is not correctly configured. Also remember a particular team in TFS can own different values for this field, which is particularly useful for Product Owners views or management views.
Also, there is another point in the article, which allows you to be able to specify the team you want the Work Item to belong during its creation from the Product Backlog view, something like the next image. But this configuration brought me a small problem, when someone from within a team, selects to create the Work Item for a different team, the backlog view produces an error as is it weren’t able to save the Work Item, so I disabled this configuration.
And as for final conclusion of this, well I haven’t been still a lot of time with this solution in production let’s say, but at this moment I find it very useful, as it allows me to improves some reports and Queries so I can clearly see the team a work Item belongs to, without any trick to truncate the area path or something to make the information easy to filter and more readable, specially in reports.
If you are going to need this or you will follow this article, please, test it thoroughly before going live, customizations in Work Items are always tricky, and specially in this level in which we are modifying the default behavior of TFS.
Also I tested it in a TFS “15” preview environment, and it also worked successfully as expected, so going forward to next version of TFS is expected to work.