• define tasks that take a day or less to complete; this helps mitigate the risks that come from poor estimates
• don't divide tasks into subtasks
  if you do divide a task into subtasks, specify Remaining Work only for the subtasks, as the system rolls up summary values to the parent task

add a team for each feature team and management area

move the area paths associated with feature teams from a flat structure to a hierarchical structure

Flat area structure	Hierarchical area structure

• open each area path associated with a feature team and change its location to be under the management area path

• change the Location to move it under its corresponding management team area path

  

by including subarea paths for the management teams, you automatically include the backlog items of their feature teams onto the management team's backlog

Management view of team progress, e.g. "Epics portfolio backlog for the Management team"

• drilling down, you can see all the backlog items and features, even though they belong to one of three different teams: Customer Service, Phone, and Web

  

Assign work from a common backlog

• while the hierarchical team and backlog structure works well to support autonomous teams to take ownership of their backlog, it also supports assigning work to teams from a common backlog
• during a sprint or product planning meeting, product owners and development leads can review the backlog
• teams can also assign select items to various teams by assigning them to the feature team Area Path

Teams without areas using a team field in TFS

• if your organization has several teams that work from a common backlog and across many product areas, this configuration might not fit how you want to organize your work
• by adding a custom field to represent teams in your organization, you can reconfigure the agile planning tools and pages to support your teams and decouple assignments into teams and area paths
• when you customize your team project to support team fields, the Team field tab appears on the administration page for the team project, and each team

iteration Paths (aka sprints) support assignment of work items to time-box intervals

defined at the project level

each team selects the paths that they want to use

are a shared resource used by all teams that select them

You can create:

• a flat set of iteration paths
• a hierarchy of paths to support releases, sub-releases, and sprints

while maintaining a single sprint cadence simplifies project administration, you can create different cadences as needed

• for example, some teams may follow a monthly cadence while others follow a 3-week cadence
• simply define a node under the top project node for each cadence, and then define the sprints under those nodes

area paths allow you to group work items by team, product, or feature area

you can review which Area Path(s) has/have been assigned to which teams

you can add area paths under the root area path

each project typically specifies a predefined set of iteration paths to help you get started tracking your work; you only need to specify the dates