https://stackoverflow.com/questions/13638896
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianI hope you found use of my post, and I would also recommend that you take a look at One Team Project to rule them all and TFS vNext: Configuring your project to have a master backlog and sub-teams.
Here is my best effort to answer your questions:
Question 1) We figured that because our teams aren't that big and to make administration more manageable, that we didn't want to define teams per product since we physically have teams per client and they oversee all the products for that client. Is this a mistake, or is this OK?
This is just fine and will allow you to grow as your teams do. If your team members work across multiple Clients you may run into prioritisation and context switching issues that you can minimise by pushing your team up a level, or having a single unified backlog and separate sub teams but still focusing on client work and not product work. I would indeed recommend this approach for the layout that you have.
Question 2) Assuming that the above team configuration is OK, are we then correct to "map" each of the areas above to each team i.e. For team "Client A Team" specify area "Client A" (and all sub-areas) as the areas to be owned by that team. What about the default area, is it ok to set the root of the "Client A" area as the default for the team?
That is indeed correct and should result in all of your work items being created when that team is selected with those defaults. Many organisations also create a parent or master backlog where misc items are created, ordered and then divided up into the appropriate team backlog as Greg Boer, Product Owner for the TFS Agile Planning Tools blogged about in his post TFS vNext: Configuring your project to have a master backlog and sub-teams.
You layout for iterations is indeed looking good as long as your Teams don’t cross the boundary between clients or you will start getting into difficultly mapping Areas and Iterations to Teams. If you think that you may need to have a single Team or group of teams map to more than one client then you may need something more like:
-> Team Project (Iteration root)
|—> Team Boundary (This could be one or more teams)
|--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A)
|---> Product A
| |---> Release 1
| |---> Release 2
| |---> Release 3
|
|---> Product B
| |---> Release 1
| |---> Release 2
|
| (ETC)
|--> Client B (This is also out team boundary - ie. we have another TFS Team for Client B)
|---> Product C
| |---> Release 1
| |---> Release 2
|
| (ETC)
While still not dynamic this would enable that scenario. I would however still retain my $\TeamProject\Client A\ProductA source control structure and not filter this down. It is simply a compartmentalisation of the planning process and should not nessesarily spill over into the other parts of your ALM Solution.
Question 3) This seems to be trickier to get the iterations right, especially when it comes to TFS showing the backlog. Specifically, for the TFS Scrum 2 Iteration setup, it seems that I should be selecting (check box) only those leaf level iterations that are for planning and subsequent development. So extending the above example, we might have that the "Client A Team" will be available to start work on a new Product B for the next 4 weeks (assume 2 week sprints). Would we then only select (check box) "Sprint 1" and "Sprint 2" from Release 1? Am I understanding/using it correctly?
You are, but you are really looking at 3 Sprints out to have an actionable backlog as part of the Scrum process. I would recommend sequentially numbering your sprints consecutively so that in the UI you will not get confused on Sprint 2 when you also tick Sprint 4 if it is called Sprint 1. It is also nice to keep a tally of the experience level of the current team.
-> Team Project (Iteration root)
|—> Team Boundary (This could be one or more teams)
|--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A)
|---> Product A
| |---> Release 1
| | |---> Sprint 1
| | |---> Sprint 2
| | |---> Sprint 3
| |---> Release 2
| | |---> Sprint 4
| | |---> Sprint 5
| | |---> Sprint 6
| |---> Release 3
| | |---> Sprint 7
| | |---> Sprint 8
| | |---> Sprint 9
|
| (ETC)
But you are fundamentally correct on the technical process involved and the result it will achieve.
Question 4) Team Backlog Iteration selection - This might be problematic due to our concept of having teams per client and not teams per product, but maybe I just understand it wrong. In TFS Areas setup, you specify which iterations the "Backlog iteration for the team". My problem is that our PBI (Product Backlog Items) will be product specific and do not wish to mix them with PBIs from another product. So what I'm unable to understand yet is what the impact will be if we select area "Client A" as the "Backlog iteration for the team" instead of perhaps "Product B". I think I'm confusing myself here - what would be a sensible choice?
You are not confusing yourself and the person entering something into the backlog of the team will need to change the default to be the iteration/area of the product that they want the change in. At least by default you are getting the correct Team and this should be an easy thing for either the person entering the item, the Product Owner or a Team Member to categories this correctly.
Anything under the area that you specify as the Team Default is by default included in the items that you see. You can “right click” on your default Area for a team and de-select “Include sub-areas” so that you only see the top level and this is the technic that is used for Greg's Master Backlog. I would however suggest that you want to maintain a setting of “Include sub-areas” for visibility and transparency within your team.
I don't know whether have one team project and multiple areas for products (as is generally recommended) is complicating the issue.
It can. Some organisations prefer to add a drop-down list for “Team” to their work items (like the Conchango/EMC template) and use that as their team designation which can be configured in the Agile Planning Tools configuration as a default. That way you don’t need a Team designation in Area or Iteration if you are hitting up against that. I have no recommendation either way without more information of how your organisation is configured.
Question 5) TFS Web Access website - For any given team under "WORK | work items | Shared Queries" there is predefined queries under a folder called "Current Sprint" (Blocked Tasks; Sprint Backlog; etc), but it seems that these queries are hardcoded against "Root Project\Release 1\Sprint 1" - should these not automatically discover which is the current sprint given the dates defined against iterations? If not, then what is the best practice for maintaining these queries?
Option 1: Each Sprint spend the 2 minutes it takes to change the queries
Option 2: Create a tool to do that for you
Option 3: Have an additional “Current” iteration node within your Release and move the currently active iteration to below that node. Then set the queries to point to “Under” that “Client A\Product A \Release 1\Current”. Then it is quicker to change the nested iteration once and all the queries work. You then only need to change the Current but once per Release.
Do you know of some quality TFS 2012 and Scrum 2 specific training / tutorials that might help address these questions, or give some guidance for a successful Scrum 2 TFS setup?
I would recommend the Professional Scrum Developer training from Scrum.org or / and engaging with an ALM Consultant.
