Create and Modify Areas and Iterations

To group work items by product, functional, or feature area, you define area paths. To group work into sprints, milestones, or time periods in which they’ll be worked on, you define iteration paths. To restrict access to a group of work items, you can use either area or iteration paths. The procedures to create and modify area and iteration paths in a team project are the same when working in Visual Studio Online and Team Foundation Server (TFS). If you need to create a team project, go here.

Area and iteration paths are useful for generating queries and also support key functions of the Agile planning tools. A team’s default area path is used to filter the backlog items for each team’s backlog pages. Work items created using Agile planning tools auto-assign the area and iteration paths based on team defaults. Many artifacts provided by the default process templates use the iterations to organize work and display team progress.

In addition, the default method for creating teams associates each team with a default area path. If your organization has several teams that work from a common backlog and across many product areas, might may want to use a custom field to represent teams. To support this configuration, see Customize a team project to support team fields.

Requirements

You must be a member of the team for which you want to modify areas and iterations. All team members can choose iterations for the team, specify areas for the team, and specify dates for the iterations for the team.

To create areas or iterations, you must either be a member of the Project Administrators group or your Create and order child nodes, Delete this node, and Edit this node permissions must be set to Allow for the area or iteration node that you want to modify. For more information, see Change permission levels.

You use the context menu for areas to add, edit, or delete child nodes, to set permissions on who can modify work items under a node, to set a default area for a team, and to exclude subareas.

Context menu for Areas

Adding and modifying area and iteration nodes

To add an area or subarea

  1. From your team project page in Team Web Access (TWA), open the administration page.

    Choose the gear icon to open administration

    To learn more about connecting to TWA, go here.

  2. Open Areas. Most teams are associated with a default area path.

    Areas and Iterations

    The default area path is used to filter the backlog items for the team project backlog pages.

  3. To add a new area or subarea, do one of the following:

    • To create a subarea, choose New Area.

    • To create an area that is a child of an existing area, highlight that area, choose the Context Menu Icon context icon for the area, and then choose New Child.

    • To create an area that is a peer of an existing area, highlight that area, choose the down arrow next to that area, and then choose New.

    The Create Area window opens.

  4. In the Create Area window, specify the Area Name, and then choose Save and Close.

To specify an area as the default area for a team or team project

  • Continuing from the previous procedure with the Areas page displayed, choose the set default link for the area that you want to be the default.

    All new work items will automatically be set to the default area path.

To view and specify iterations for a team

  1. Open the home page for the team, and then choose Configure schedule and iterations.

    The Iterations window opens.

    Example Iterations for a Team
  2. In the Iterations list, view the iterations selected for your team. Iterations selected for your team will have a check box selected by the iteration name.

    TipTip

    By default, all iterations for a team project will be displayed. To view only the iterations selected for your team, next to Show, choose all to toggle the selection to selected only.

  3. To specify an iteration or sub-iteration for a team, select the check box next to that iteration or sub-iteration. If you choose an iteration, all sub-iterations will not be selectable. If you want to use the sub-iterations, clear the check box for the iteration, and then select the check boxes for the sub-iterations you want to use for your team.

To add an iteration or sub-iteration

  1. Continuing from the previous procedure with the Iterations window displayed, do one of the following:

    • To create an iteration, choose New Iteration. A new iteration will be created that is a peer to the other iterations in the list.

      The Create Iteration window opens.

    • To create an iteration that is a child of an existing iteration, highlight that iteration, choose the Context Menu Icon context menu next to that area, and then choose New Child.

    • To create an iteration that is a peer of an existing area, highlight that iteration, choose the Context Menu Icon context menu next to that iteration, and then choose New.

      The Create Iteration window opens.

  2. In the Create Iteration window for Iteration Name, specify a name for the iteration. Optionally specify start and end dates for the iteration either by typing them in the text boxes for Start Date and End Date, or by choosing the calendar icon and then specifying the dates within the calendar window. If you are creating an iteration in a different location from the default, specify a different location for the iteration in Location, and then choose Save and Close.

To specify dates for an iteration

  1. Continuing from the previous procedure with the Iterations window displayed, highlight the iteration for which you want to specify dates, and then choose set dates.

    The Edit Iteration window opens.

  2. Specify start and end dates for the iteration either by entering them in the text boxes for Start Date and End Date, or by choosing the calendar icon and then selecting the dates within the calendar window. Then choose Save and Close.

By assigning permissions, you can scope the set of actions that users or groups can perform on work items or test plans that are assigned to an area. You can also restrict or allow users or groups to manage the project structure for an area or iteration.

To control access to an area

  1. Open the Context Menu Icon

  2. The Permissions window appears for the node you selected, as the following illustration shows:

    Security dialog window for Areas
  3. Choose the name of a group or user whose permissions you want to set.

    You can add users or groups and then set the permission to allow or deny for each user or group. Specifically, you can grant or deny permission to manage the structure of a node, and for area paths, to view or modify work items or manage test plans that are assigned under the node.

  4. To change a permission, choose not set, deny or inherited to change it to allow, or choose allow to change it to deny.

    NoteNote

    Your ability to change a permission will depend on your current permission settings. If you are unable to change a permission, contact your administrator for either the team project or Team Foundation Server.

  5. When you have finished modifying the permissions, choose Save and Close.

For additional ways to restrict modifications to work items, see Manage Permission to Create or Modify Work Items.

For an overview of how you can define iterations and plan a sprint, see Collaborate. When you specify the areas and iterations for your team or team project, consider the following guidelines:

  • For Areas

    • Define areas that support your traceability and security requirements.

    • Each team can create a hierarchy of areas under which the team can organize their user stories, requirements, tasks, and bugs.

    • Use areas to represent logical or physical components, and then create sub-areas to represent specific features. Your team can use this structure to keep work items organized and improve traceability by component or feature.

    • Set permissions on areas to restrict access to work items that are assigned to particular categories. You can set security options that dictate not only who can change each area node but also who can edit or even view work items in a particular area. For more information, see Restrict access to work items assigned to an area or iteration earlier in this topic.

    • Avoid creating an area structure that is too complex. You can create areas to partition permissions on work items, but complex trees require significant overhead for permission management. You may find that it is too much work to duplicate the structure and permissions in other team projects.

  • For Iterations

    • Use iterations to represent sprints, milestones, or cycle time for your project.

    • Determine the cycle duration that meets your team processes, and define your iterations to support that cycle.

    • Create a separate iteration for unassigned backlog items, user stories, requirements, tasks, or other work items.

    • For an overview of how you can plan a sprint by using iterations, see Work in sprints.

  • For Both Areas and Iterations

Back to top

You build the structure of product areas by creating nodes that represent components and features. As an example, you might create three areas for a team project that is named MyApplication. These areas would represent the three main development components of a tiered web application: the website, the web services, and the database. As the following illustration shows, you can create a node under the team project node for each of these components, which are labeled My Websites, My Web Services, and My Database.

Area and Iteration Hierarchy iconMyApplication


After you create these areas, you can assign work items, such as user stories, tasks, or bugs, to a specific area and run a query to find all items that are assigned to that area.

You can also organize the major components into more granular groupings. As the following example shows, each top node now contains two or more child nodes.

Area and Iteration Hierarchy iconMyApplication

   Area and Iteration Hierarchy iconMy Web Sites

        Layout & Design

        Navigation

        Area and Iteration Hierarchy iconPages

          Home

          Products

          Resources

          Services

          Support

   Area and Iteration Hierarchy iconMy Web Services

       Logon

       Logoff

       Performance

       Security

   Area and Iteration Hierarchy iconMy Database

         Event Triggers

         Performance

         Schema

         Security

You build the structure of the project lifecycle by creating nodes that represent a hierarchy of events, such as sprints, pre-beta and beta deliverables, and other release milestones. In the following example, Backlog, Beta 1, Beta 2, Release 1.0, and Release 2.0 are defined for the MyApplication team project. You can assign all work items to the Backlog iteration if they are not yet scheduled for work or for a release.

Area and Iteration Hierarchy iconMyApplication

   Backlog

   Beta 1

   Beta 2

   Release 1.0

   Release 2.0

As you create the backlog of product features and tasks, you can start to assign them to the milestones by which you expect the team to finish the features and tasks. As your needs change, you can add events under each major milestone that reflect how your team schedules and manages its work. As the following example shows, the Beta 1 iteration now contains five child nodes, one for each sprint in the Beta 1 time period.

Area and Iteration Hierarchy iconMyApplication

    Backlog

   Area and Iteration Hierarchy iconBeta 1

         Sprint 1

         Sprint 2

         Sprint 3

         Sprint 4

         Sprint 5

   Collapse icon for Area and Iteration hierachiesBeta 2

   Collapse icon for Area and Iteration hierachiesRelease 1.0

   Collapse icon for Area and Iteration hierachiesRelease 2.0

Iterations do not enforce any rules. For example, you can assign a task to an iteration but not close or complete it during that iteration. At the end of an iteration, you should find all work items that remain active or have not been closed for that iteration and take appropriate action. You can, for example, move them to a different iteration or return them to the backlog.

The Area and Iteration fields are paths that consist of multiple node items that are separated by backslash (\) characters. The following table describes the restrictions that govern the definition of nodes and paths.

Restriction type

Restriction

Node length

  • Must not contain more than 255 characters

Special characters for nodes

  • Must not contain Unicode control characters

  • Must not contain any of the following characters: \ / $ ? * : " & > < # % | ,

  • Must not contain characters that the local file system prohibits. For more information about character restrictions in Windows, see the following topic on the Microsoft website: Naming a File.

Reserved names

  • Must contain more than a period (.) or two periods (..)

  • Must not be a system-reserved name such as PRN, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, COM10, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, NUL, CON, or AUX

  • For more information about reserved names, see the following topic on the Microsoft website: Naming a File.

Path length

  • Must contain fewer than 4,000 Unicode characters

    Important noteImportant

    If you define a path name that contains more than 256 characters, you will not be able to specify it in Office Project. To avoid this problem, define path names of fewer than 10 characters, and do not nest nodes more than 14 levels deep.

Path hierarchy depth

  • Must be fewer than 14 levels deep

A: When you rename an area or an iteration, or move the node within the tree hierarchy, you must manually update the work items that reference the existing path or paths. You can perform a bulk update using TWA or Excel.

When you delete an area or an iteration node, the system automatically updates the existing work items with the node that you enter at the deletion prompt.

A: The Agile planning tools—Create and organize the product backlog and Work in sprints—are built from system queries that reference the team area path. You can view these queries by choosing the Create query link that appears on these tools’ pages. However, you can’t change the underlying query.

Also, for a sprint or iteration backlog page to appear for a team, it must first be defined and selected.

You can quickly generate queries or filter reports to view the progress for those areas and iterations.

A: Although there is no concept of sub-teams, you can create teams whose area paths are under another team, which effectively creates a hierarchy of teams. To learn more, see Add another team.

A: Yes. If your organization has several teams that work from a common backlog and across many product areas, you might want to change how teams are configured. 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 assignment to teams and area paths.

A: No. You can’t export the structure of tree paths for one team project to use with another team project.

A: By default, team projects that are based on Visual Studio ALM process templates have several predefined iteration nodes and the team project as the top area node. For information about how to customize these settings, see Define the Initial Areas and Iterations in the Classification Plug-in.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft