TFS vNext: Configuring your project to have a master backlog and sub-teams


 

One backlog to rule them all…

One common practice we’ve seen our customers use is to have a master backlog, which “feeds” several teams. The master backlog is prioritized and maintained, and when it comes time to plan for the next sprint, all the teams gather together and “sign up” for backlog items to work on in the upcoming sprint.

That way, they can ensure that all teams are working on the most important items for each sprint.

This blog post will tell you how to configure and use a master backlog.

Let’s start with a newly created team project: “Demo Project”. When a project is created, a default team is created for that project. This team is the “master” team.

1

Configure the “Master” team’s work areas

 

Click on the “Configure work areas…” link

clip_image002[7]

 

The root area path is selected for the this team. Click on the context menu, and select “Exclude sub-areas”

clip_image004[5]

 

 

This will configure it so that the backlog for the “master” team only includes backlog items that are located at the root area path, but not below the root area path.

 

clip_image006[5]

 

 

Press Close and that is done.

2

Create sub-teams, which will each have their own backlog

 

Navigate to the Administration Console by click the “gear” icon in the upper right

clip_image008[5]

 

 

You will see that one team already exists. Is the “default project team” created when you create a team project, which is acting as the “master” team.

 

Select “New team” to create another team

clip_image010[5]

 

 

Select a team name, and if you want, a description:

clip_image012[5]

 

 

Just for fun, click on “settings”

clip_image014[5]

 

 

This will display the advance settings. You will note that by default, the “Create an area path with the name of the team” is checked.

 

When this is checked, creating a team will also create an area path of the same name (in this case: “Blue Team”, and then associate that area path with the newly created team.

clip_image016[5]

 

Press “Create Team” and you’ve just created your first team

clip_image018[5]

 

 

Repeat the process again, to create a second team.

clip_image020[8]

 

 

What you have now is three teams. The “master team” which is the default team that resides at the Team Project level, and two sub-teams (Red and Blue).

 

Click on one of your teams, and you’ll see the settings for that team.

NOTE: That you can add members to each sub-team, as well as administrators and a cool pic if you want.

clip_image022[5]

 

 

Click on the “areas” tab

clip_image024[5]

 

 

You’ll see that new area paths were created for both teams, and that this team (the Blue Team) is configured to use the “Blue Team” area path.

clip_image026[5]

 

 

Feel free to poke around. But eventually, we need to use this stuff. So close the Admin Console tab on your browser to return to the main screen.

clip_image028[5]

 

3

Populate the master backlog

 

Here is the home page for the “master team”, that is the default team configured for the team project.

Click on the “View backlog” link to view the master backlog.

clip_image030[5]

 

 

Here’s the backlog, with a few things added:

clip_image032[5]

4

Assign a backlog item to a sub-team

 

Open up a backlog item by double clicking it. Set the Area to the appropriate sub-team

clip_image034[5]

 

 

Save and Close the work item, to view the backlog again.

You will notice that “backlog item 1” is still on the backlog, even though it was assigned to a sub-team.

clip_image036[5]

 

 

You will need to refresh your browser to see that item removed. Here it is after a refresh:

clip_image038[6]

 

 

You can do this with any number of backlog items, assigning to the teams to work on.

 

5

View the sub-team’s backlog

 

Select the “team navigator” in the upper right. This shows the projects and teams you’ve recently viewed. Since we haved looked at our newly created teams, we’ll probably have to select “Browse All Teams”

clip_image040[5]

 

 

Select the desired sub-team from the list, and press “Navigate”

clip_image042[5]

 

 

You’ll now see the sub-team’s backlog, complete with the item that has been assigned to it:

clip_image044[5]

 

5

Configure the sub-team’s iterations

 

You’ll notice that there are no iterations available for planning. You need to tell TFS that you want this team to work on specific iterations. The easiest way is to navigation to the Home page:

clip_image046[5]

 

 

And then click on the “Configure schedule and iterations…” link

clip_image048[5]

 

 

Here you can select the sprint’s you want this team to particpate in.

Just check the boxes

Below we are selecting Sprints 1 through 6 of the first Release

clip_image050[5]

 

 

Press Close to return to the home page. Then click on “View backlog” to go back to the backlog page.

You’ll now see the sprints available for planning

clip_image052[5]

 

 

Conclusion

 

Go ahead and configure all the sub-team’s to have the correct iterations. Now you can have a single master backlog “to rule them all”, and decide with each sprint, which sub-team is going to take on each backlog item.

 

The sub-teams can then use their own backlog to prioritize and pull into a sprint for planning.

 

Enjoy!

 

 

 

 

 

 

 

 


Comments (14)

  1. JimSz says:

    Nice walk through of how to use teams in vNext. Thanks Gregg!

  2. Allen Feinberg says:

    Can we script the creation of Teams and script the setup of team settings?

  3. Michael Wells says:

    What if each team has a different Release/Sprint cycle and they all use the set dates?

       Red Team is on Release 1 (no dates set) – Sprint x all have dates set.

       Blue Team is on Release 4 (no dates set) – Sprint x all have dates set.

    How would one go about that?

  4. Ryan Adler says:

    How does this integrate with the Sharepoint portal for that project, since I don't believe Sharepoint has this concept of subteams within a project?  For instance, which data will be shown on the main Dashboard?

  5. Gregg Boer says:

    @Ryan, the SharePoint portal will only show the information for the team project, and is not "team-aware".

  6. Lambros says:

    Thanks for the nice walkthrough Gregg!

    However, I think Michael's question (see Michael Wells, above) about different Release/Sprint cycles worth an answer, since it's an essential aspect to succesfully adopt your approach.

  7. David Withers says:

    Silly question probably, but how did you make the field a drop down?  also the system pukes when I used the square brackets []

    BTW this article is brilliant, i've been saying this is how it should be done…. No  need to duplicate everything for each business unit

  8. @David Withers, which field drop down are you referring to? I also am not understanding what you mean about brackets. Glad you liked the article.

    @Lambros/@Michael Wells, sorry for the (way too long) delay in answering. If two teams are on different release cycles, you can do that, but I would not recommend it. It seems like if two teams are sharing the same backlog, they should be sharing the same sprint schedule. If what you are referring to is you the two teams are really on the SAME release schedule, but contributing to two different releases, then my recommendation is that you create an additional custom field called "RELEASE", and use that (not iteration path) to track which release the story is destined for. In the future, we are going to make this an out-of-box concept.

  9. Dianna says:

    The issue we have with this is that we would like to have meaningful product areas (e.g. Framework, Apps, Admin) for Support, QA, Reporting but using this method eliminates the ability to define proper Areas or they would have to be replicated under each team name.  We have cross-functional teams that can work in all areas so we want some other way to isolate their backlogs by Team assignment without using up Area.  By using Team names as Areas this eliminates the possibility of having real functional areas.

  10. Jonathan says:

    @Gregg You mentioned in a previous comment "…my recommendation is that you create an additional custom field called "RELEASE", and use that (not iteration path) to track which release the story is destined for. In the future, we are going to make this an out-of-box concept."

    Is this really going to be an "out-of-box concept"?

    I think this is our answer. We have a single backlog for all of our teams, but any item in that backlog could be for any release version we are supporting with bug fixes.

  11. @Jonathan, we are planning on add a first-class notion of RELEASE to TFS in the future. It is not there yet, so the workaround is to create your own field.

  12. BossHogg20 says:

    Is this available now, or is vNext part of the TFS 2015 RTM?

  13. @BossHogg20, TFS 2015 RTM doesn't have a first-class notion of a Release. However, you can create your own field for this. Adding a first-class notion of Release is planned for a future update. Sorry, I can't be more specific than that.

  14. BossHogg20 says:

    @Greg, Sorry, I mean this whole setup you are information us about in general "Configuring your project to have a master backlog and sub-teams".