VSO: Single project with a tiered area structure?

Question

Historically we have always had separate VSO Projects for each logical project undergoing development. This is particularly important as we need to have separate backlogs for each project. Each project has its own Product Owner.

We have a team of around 10 developers who work between these projects over 2 week sprints.

This setup has led to some serious issues when using VSO's Scrum tools:

• Multiple burndown, cumulative flow and velocity charts
• Split team member capacity during sprints

This has made it very difficult to monitor work progress during sprints and to plan effectively for the next. This led me to create this StackOverflow question.

Based on MrHinsh's answer, I can now have 1 VSO project and then split all the projects into areas:

This means we have the following teams in Project (all "mapped" to their relevant areas):

• Project 1 Team
• Project 2 Team
• Project 3 Team
• Project 4 Team

Would it be a good idea to add an extra tier to the area structure?

For example, projects belong to some product. A logical grouping could be useful for reporting sake (velocity/burn date/etc). It would fit our organisational model quite well:

From my understanding, we would then need to create two more teams:

• Product A Team
• Product B Team

Additional questions:

This would essentially mean that the Product A Team backlog would be an accumulation of the Project 1 and 2 backlogs. BUT, members could still add items to Product A's backlog, which is somewhat wrong because backlog items should only be created in Project 1 and 2. Is there no way of disabling this?

I have been playing around with this in VSO and have found that no matter which Area a member belongs to, he/she always seems to have access to all areas in the Project. This means that access control isn't quite possible. Also, it means that I cannot "hide" the Product layer.

Additionally, when navigating to a team area, there is no clear indication of the hierarchical structure (see screenshot below). This may be misleading for members. This would be another reason to hide such Product layers. I haven't found a way to do this.

Scotch

If a different Product Owner owned each Project within a Product the. I would question the validity of them being Product Owners... Are they not just Project Managers? – Quarto

Answer 1

There is no way to hide the Product layers, however you can do something about permissions and defaults.

Permissions

You can set permissions directly on Area Paths. This allows you to restrict visibility or write access into the contents of an area path. If you open the Area Path manager and right-click you can see the "Permissions" option. Remember that "not set" is way better than "Deny" as "deny" always wins.

If you select the root Area->Security->Contributors you can "not set" the permissions that you don't want to inherit. Then give Teams access to the areas that you want.

Backlog management

If you open up the backlog Tree and instead of selecting the "ProductA" node as the backlog iteration for the "ProductA" team you can select "Project1" as the default area instead. Any new items added to the "ProductA" backlog then automatically appear on "ProductA\Project1" instead of the root.

All you do is hover over the "Project1" entry and select "set default" to make that the default.

Quarto