Introducing Team Foundation Server 2012 and Scrum V2.x
The combination of Microsoft’s latest Scrum process template and Team Foundation Server 2012 brings a host of new features and much improved user experience. Most of the interaction and administration of Team Projects moves into the web interface with only rare visits to Team Explorer required.
A “Backlog” view enables the team to refine the backlog, quickly adding new User Stories and reprioritising any story by simply dragging it up or down the order. A forecast function provides the ability to visualise sprint by sprint how the team might progress through the backlog at a specified team Velocity. Sprint Planning is well supported; the team simply drag candidate stories into the new Sprint and then as they add tasks to the stories there is automatic feedback of team commitment versus their capacity.
A “Board” view provides an interactive virtual team board with state swim lanes so that the teams can see exactly what each other are working on and how the sprint is progressing. The Board view can be narrowed down by team member to aid Scrum meetings and personal work management. The user experience of the board is excellent, with low impedance changes to task states, hours and assignments with an automatic background save.
What About Multi-team Support?
All this new functionality and user experience works nicely when you have a single team working within a single Team Project. It is common though, for multiple teams to work against a common Product Backlog which requires a single Team Project. Consider for example where multiple teams are collaborating to build a product or ecommerce system. Configuring a Team Project based on Scrum V2.x template to support multiple teams is certainly possible but the behaviour of the board and backlog views makes some assumptions and requires some working around.
In VS2012 the multi-team scenario is supported in part by an area path mapping per team that is intended to act as a filter for the backlog and board views such that the teams see their own subset of data. There are a number of challenges with this approach though:
- The area path is no longer available for Product Backlog theming or categorisation which is a major setback for those of us trying to make sense of large backlogs.
- The filtering by area path is too binary, providing one of these two options:
- A team has visibility of the entire Product Backlog but their Sprint Backlog view is unusable as they can’t filter out other team’s backlog items
- A team can’t see the entire Product Backlog (only those scoped to their area path) but their Sprint Backlog view makes sense. I suspect this is the intended option!
- Lack of complete Product Backlog visibility degrades architectural decisions and ability to work with the other teams sharing the backlog.
- The “Forecast” feature of the backlog view isn’t effective unless it applies to the entire backlog rather than just team subsets filtered by area path.
- Teams can’t pull requirements into their Sprints until backlog items have been moved to the team’s area path by someone else.
- The issues above drive early assignment of backlog items to teams, causing sub optimal scheduling and flow of stories.
- One of the teams has to be the “Default” team which inherits its area path setup from the Team Project configuration and doesn’t appear as a named team in navigation lists.
- New Product Backlog items inherit their area path from the default team path setting, so the “non-default” teams can’t see them
- All teams share Sprint start and end dates – generally good practice but teams working from different countries often have different holidays requiring adjustment of sprint dates.
- It is possible to use a custom field as a “Team” field but this approach shares similar challenges as above except that it does free up the area path for backlog categorisation.
- The custom field approach requires the addition of a team field in all appropriate work items (e.g. Product Backlog Item, Bug, Task & Impediment.
Given the challenges outlined above I have spent some time exploring a number of alternative approaches to supporting multiple teams. Here are three different patterns that work reasonably well if you are prepared to live with a few compromises. There may well be other good patterns so please let me know if you discover them!
Multi-team configuration – Area Path Pattern
If your teams won’t miss the area path as a means of Product Backlog theming or categorisation and all the teams use consistent dates for their sprints then try this pattern. This approach uses the area path to split the team’s views of the backlog but uses an additional “virtual team” to provide the teams a way of interacting with the whole backlog.
In this example, I’m going to have two teams, Team A and Team B, working together against the same Product Backlog within a single Team Project, Scrum03.
I’ve created three teams, the two Scrum teams and then a third team, the Über Team, who will be the “Team of teams” and are set as the default team – notice the bold formatting of the team name in the screenshot below:
The Über Team is the key to working around many of the challenges listed earlier, providing our teams the visibility of the whole backlog for Product Backlog refinement activities and joint planning. All members of both teams are also assigned to the Über Team so that they can use the Über Team’s backlog view. I’ve used Windows groups as security containers for my 3 groups, hence why the view above only shows “1 member” for each team.
The area path configuration for the Über Team should be set to the root, with sub areas included to ensure that the entire backlog is visible, regardless of whether items have been assigned to a specific team:
The two Scrum teams provide filtered views via their area path setting so that Sprint Backlog and Board views show only those backlog items and tasks committed to by each team. The area path setting for each team should be configured to the specific team path.
How to work with it
See the screenshot below that shows the backlog view from the perspective of the Über Team, with the entire Product Backlog visible. Notice that we have switched the Forecast to ‘on’ so that we see how the combined teams are likely to progress through the backlog Sprint by Sprint.
The teams can jointly assess which stories should be considered for the upcoming Sprint and how they should be split between the teams and pulled (just in time) into each team’s Sprint Planning meeting. They will need to set each story they are going to consider for the next Sprint to their specific area path so that it will appear in their backlog and board views. Until they do this, they will have empty views! See PB06 above, it has been moved into both the new Sprint iteration path and the team’s area path.
To pull a backlog item into Sprint 1 is easy enough; simply drag the desired item to the sprint. The backlog item has to be edited though to select the team who are going to take it into Sprint Planning:
Having used the Über view to select backlog items for planning, teams can then switch to their own view so that they just get their own backlog items to which they can add tasks. Switching between the different team views is shown in the partial screenshot opposite. I’ve added some red marking to indicate the teams we’re currently interested in. Observe that the Über Team doesn’t actually have a name as it is the default team so it just goes by the Team Project name of Scrum03. In this example we are moving from the Über Team’s view to Team A’s view.
In the team backlog view, we select the new sprint and our selected backlog items should appear. If they don’t then either the area path or sprint selection may have been incorrect. In the screenshot below, look for the ‘+’ button to the left of each of the Product backlog items that enable tasks to be added in Sprint Planning.
We’re looking at the “Contents” tab in this example but you’ll notice that there is also a “Capacity” tab that enables the availability of each team member to be set for the sprint. This is what drives the numbers and bar charts that appear in the “Work” section of the contents tab – see the area to the right marked in red. With this feature we can see whether our team still has capacity to pull more work into the sprint.
Having planned a backlog item and confirmed that we have enough capacity to commit to the item, we move the state of the backlog item to “Committed” – see the red marker in the centre of the screenshot above.
Once the team get stuck into the sprint they have their own interactive “board” that allows them to track their progress and synchronise their work:
Multi-team configuration – Team Field Pattern
This approach is very similar to the previous pattern except that we use a custom field rather than the area path to indicate which team has ownership of a given work item. From a usability point of view it is a very similar experience but with the major advantage that we can now use the area path for backlog categorisation.
The major disadvantage to the previous pattern is the amount of work you need put in to the initial setup of a Team Project to get this to work.
I’m going to try and save this blog from being the longest ever by simply highlighting the differences between the Team Field and Area Path patterns – most of this being in the Setup.
In this example, we have two teams, A Team and Dilberts, working together against the same Product Backlog within a single Team Project, ScrumDemo04. This approach also requires the “Team of Teams” model and here we have the “Online” team setup as default team to enable an overall view of the Product Backlog.
In summary, what we need to do is:
- Create a Global List look up for the team field
- Configure the Team Project to use a custom field rather than the area path to support team selection
- Setup a custom field type and associated UI configuration for each work item type that we will need to set the team ownership – at least the PBI and Bug
- Map the teams that your Team Project will use
1. Create a Global List look up for the team field
The simplest way to create the team Global List is with the Process Editor tool, part of the TFS Power Tools. If you can’t use the Process Editor then there is always the command line and witadmin, using exportgloballist and importgloballist options along with some xml editing.
2. Configure the Team Project to use a custom field rather than the Area Path to support team selection
Use the command line and witadmin with the exportcommonprocessconfig option to export the CommonProcessConfig.xml file and then edit the Team mapping from:
<TypeField refname=”System.AreaPath” type=”Team” />
to something like:
<TypeField refname=”RippleRock.TeamName” type=”Team” />
“RippleRock.TeamName” is the custom field that will be added to each of the work item type descriptions to enable team selection from the teams in the Global List.
See the screenshot below:
After amending the team mapping and saving the file, re-import the updated CommonProcessConfig.xml using witadmin with the importcommonprocessconfig option.
3. Setup a custom field type and associated UI configuration
Use the Process Editor to add the team custom field type to each of the work item definitions that you care about and then expose the new field on the work item form so that it is visible in both Web Access and Visual Studio. Alternatively you can use witadmin from the command line and edit the xml directly if that makes you happy.
3.1 Adding the team field to the Product Backlog Item using Process Editor:
3.2 Set the Rules for the field so that it can only be populated from the Global List you setup in step 1:
3.3 Configure the layout or UI of the PBI work item to expose the Team field:
And here’s what the field looks like on the working PBI:
How to work with it
The screenshot below shows the backlog view from the perspective of the Online Team (the default team), with the entire Product Backlog visible and the Forecast option on. The only difference with the Area Path model is that we now have the team set by our custom field, while the area path is free to be used to categorise the backlog.
The teams will still need to switch views between the Online team and their own as they move to Sprint Planning and update the Team field of those PBIs they pull into their Sprint. Just like the Area Path model except that we now use the Team field instead of the area path.
Multi-team configuration – Iteration Path Pattern
If your teams can’t function without using the area path as a means of Product Backlog theming or categorisation or some teams need to have different dates for their sprints then try this pattern. This approach uses an extra level on the iteration path that allows both a holistic view of the product backlog but also allows the teams to view just their own items at the Sprint level. There is an Über team again but its only role is to support a combined forecast view of the overall backlog.
There is an issue with this approach however, the standard Release Burndown chart that ships with the template doesn’t seem to handle the extra level in the iteration path. It is fairly straightforward to use Excel Reporting to show a Release Burndown and there is an example shown towards the end of this paper. RippleRock are working on an alternative chart that will cater for this approach and works on a daily basis rather than sprint by sprint. We’re hoping to have this report available for on-premise TFS setups soon …
As in the previous example, we have two teams, The A Team and Dilberts, working together against the same Product Backlog within a single Team Project (ScrumDemo 01). In addition to the two Scrum teams, we also have the Online Team (like the Über team in the first example), who will be the “Team of teams”.
The major differences in this approach are in the area and iteration path configurations as we will see below.
This is the configuration for the whole online team. The team area path configuration can either match this or you can configure subsets for teams specialised to a part of the system. Obviously in Scrum, we encourage good cross-functional teams but in technologically diverse systems this is occasionally necessary.
Notice that with the area path selection, it can be configured such that sub-areas are included with the parent so that all the children are also accessible to the team. This functionality is not available for the iteration path.
This enables individual sprint start and end dates and also provides the team filtered data we need to drive the backlog and board views.
By default, new Product Backlog items are created at the node set to be the “Backlog iteration” for the default team, or Über team in our models.
To scope backlog items for a release, simply move them to the Release iteration path node – Online MVP in this example.
We are looking at the A Team’s iteration path configuration and we can see that they are set to only be able to see their “Team Sprints”.
Here we see that the team of teams view is configured to only see the parent sprints and not the individual team sprints. This is important as it will enable a nice combined team forecast on the overall backlog from the team of team’s backlog view
How to work with it
See the screenshot below that shows the backlog view from the perspective of the combined team of teams, with the entire Product Backlog visible. The Forecast feature is showing how the combined teams are likely to progress through the backlog sprint by sprint, based on the parent sprint nodes rather than the individual team sprints.
From the team specific backlog view we see only the sprints for that team but we also see the entire backlog. In the screenshot below, the team are dragging a backlog item into their sprint for planning.
The other team will also see the entire backlog, including those items that the A Team are planning – as you can see from the iteration path which is indicating which team has each item. Teams can pretty much stick with their own view for planning and working through the backlog and really don’t need to keep switching to the team of teams view as we did using the area path pattern.
As we can see from the A Team view of their planning, all the new backlog and board features work as Microsoft intended them:
The only wrinkle is that the Release Burndown report doesn’t cope with the team sprints. We will be making a day by day Release Burndown report available but it is really easy and quick to use the Excel Reporting capability of TFS to build one like this:
All three of these patterns are quite workable for supporting multiple teams within a single Team Project with a MS Scrum V2.x process template. My thoughts on each approach are:
- The Area Path model is my least favourite as it sacrifices a key categorisation facility and also offers a clunky user experience.
- The Team Model is a better model but it requires quite a bit of setup work and shares the same issue of user experience as the Area Path model.
- My personal favourite is the final pattern as it frees up the area path, has great flexibility of sprint configuration and a better user experience around Sprint Planning.
I’d be very interested to hear your opinions and experience too.