Team and organizations that are new to TFS almost always struggle with how to structure their hierarchy for the Area Path field. The documentation might seem straight forward: “Area paths allow you to group work items by team, product, or feature area”. However, most teams quickly discover that this is easier said than done.
First of all, do not use area path to track teams unless you have to (currently no other way to do it in VSO). I’ve explained why in a previous post.
Second, start small with broad areas and add more detail (child nodes) as needed. I’ve seen too many teams getting stuck on implementing a “complete” area path hierarchy thinking the field wont be useful unless they have it all in place. Most of the time that is a real waste of time, usually resulting in a way too detailed hierarchy where many nodes are never used. Use an agile approach instead and add detail where needed, when needed.
Third, keep a user centric view. A very common scenario is that the area path hierarchy is defined by the development team usually resulting in something relating to the software architecture. Unfortunately this is rarely useful to non-developers, e.g. Product owner, stakeholders, end users. Product features or workflows are usually more useful as it makes more sense to the non-developers (typically the ones creating new requirements and bugs) and for reporting purposes. One of the most interesting solutions I’ve seen, and personally feel makes a lot of sense, is to map the area path hierarchy to the user manual’s table of content.
This is the second post in a series where I will try to give you some solid guidance on TFS/VSO or point you towards existing solutions and recommendations.
jesfer 