Explicit Backlog node, or root node as backlog node?

Question

Is there any reason to prefer an explicit Backlog area or iteration node in TFS, instead of just using the root node? Does this improve the function of any of the reports or anything? Do either of them them offer easier managability?

I've seen this done both ways, and I'd like to see suggestions about tradeoffs.

Answer 1

Using a different node for area path:

The concept of a team was introduced in TFS 2012. Each team can have their own home web access page as well as their own backlog. Each team may be tied to a specific area path, and you can set their backlog to a specific area node to filter down the backlog queries. You can even connect to a specific team in Visual Studio 2012, so the work items are filtered down in the IDE environment as well.

Using a different node for iteration path:

Teams can break down their iterations into releases. I.e. sprints 1-10 could be for release one and sprints 11-20 could be for release two. This will give you release burndowns as well as sprint burndown. It really depends on how you develop your software and process your team uses.

These are only a couple of examples as the possibilities are endless. You can also tie teams to a different field other than area path and have a centralized backlog which is then delegated out to the teams. Here is a blog post by Martin Hinshelwood on this specific topic: http://blogs.msdn.com/b/greggboer/archive/2012/01/27/tfs-vnext-configuring-your-project-to-have-a-master-backlog-and-sub-teams.aspx