Export (0) Print
Expand All

What's New in Tracking Work Items

Visual Studio 2010

Updated: May 2011

In the current release, you can more easily integrate how you track work items in Visual Studio ALM with how you track status and progress in Office Excel and Office Project. You can also perform the following tasks:

  • Create a hierarchical task structure by using Office Excel. You can create a list of nested tasks, subtasks, and sub-subtasks in Office Excel and then publish it to Team Foundation Server. If you take this approach, the parent-child relationships among the tasks are retained with the relevant types of links. For more information, see Performing Top-Down Planning Using a Tree List of Work Items (In Excel).

  • Maintain predecessor and successor relationships of tasks that you create in Office Project. If you create tasks in Office Project and publish them to Team Foundation, they are automatically defined with predecessor and successor links that you defined in Office Project.

  • Maintain parent-child relationships of summary and subordinate tasks that you create in Office Project. If you create tasks in Office Project and publish them to Team Foundation, all summary tasks are automatically created as parent tasks with links to their child tasks.

You can perform the tasks in the previous list by using new types of links and the following new features integrated into Office Excel:

  • View list: Within Office Excel, you can display work items in one of two forms:

    • Flat lists: Use to view and modify work items in a simple list form.

    • Tree lists: Use to show hierarchical relationships between work items with parent-child links and to modify both the work items and the links among them.

  • Refresh list: Within Office Excel, you can specify how you import work items and how they are refreshed after you change them:

    • Input lists: Use when you only want to refresh the information about the work items that are already in the worksheet.

    • Query lists: Use when you want to refresh which work items appear in the worksheet based on a work item query, in addition to refreshing the information about the items.

For more information, see Flat Lists and Tree Lists, Query Lists and Input Lists.

You can better manage risks and dependencies if you use several new features of the current release. To perform the tasks in the following bulleted list most effectively, you must store bugs, tasks, features, requirements, and value propositions as work items. You must define dependent links not only between value propositions and features but also between features and all associated requirements, tasks, and bugs. You must break down tasks into a tree hierarchy of subtasks.

  • Determine the impact of cutting a feature. You can create a direct links query to list all active work items on which each feature depends and all requirements that the feature supports.

  • Determine which tasks your team must complete to implement a feature. A team lead creates a direct links query to list all incomplete tasks for each feature.

  • View all tasks that are assigned to a development team and group the tasks by the features that are implemented. You can create a direct links query that lists all features that are linked to active tasks that your team members must complete.

You can perform the tasks in the previous list by using the new query editor and query results view features. For more information, see Finding Bugs, Tasks, and Other Work Items.

In the current release, you can track status and progress on a broader scale by linking to work items across team projects. By taking this approach, you can define dependencies for a task or feature that another team or group owns, track and annotate those dependencies, and build relationships with another project group. Also, you can track how dependencies change over time.

In the following scenarios, you track features, requirements, and tasks as work items in Team Foundation.

  • Create a dependent relationship to a feature that another team is developing. If you determine that some of your features depend upon another team’s project, you can document that dependency by linking from your project to one or more work items in the other project. You might then contact the project manager (the provider) on the other team to discuss an informal service level agreement. The agreement might include the points of contact, rules of engagement, areas of responsibility, deliverables, and schedule for the cross-group collaboration. After you and the other project manager finish negotiating the terms of the agreement, you both know how to track progress on the dependencies and when they should be complete. You can then create additional links to document the dependencies in more detail.

  • Create a dependent relationship to a feature or set of tasks that are under development by another team. When your development lead creates tasks for their feature work, they must account for external dependencies that are part of the overall cross-group collaboration that you have already established. For each task that has a dependency, they create a dependent link specifically to the associated feature or task in the other team’s project.

  • Request a dependency to another team. A project manager on another team might deliver only a portion of a feature on which your project depends. If a developer on your team discovers an issue with the implementation of that feature, they can report the bug in your project and create a dependency from that bug to the other team's project.

  • Manage commitments to other teams. You can use dependency links to determine how much work other teams are requesting from your team and decide which requests to fulfill or deny. As development progresses, you can periodically reassess those work items and, if necessary, cut one or more of them from the current milestone. When you resolve those work items and change their status to postponed, your changes are reflected in the other team's project.

  • Get notified of changes to dependent work items. If you are working on a task that depends on a work item in another team's project, you can receive an e-mail message whenever that work item changes. For example, you might want to know when another team resolves a bug that blocks your progress.

  • Manage cross-group dependencies. Your team might not be able to close one or more of its work items until another team fulfills a set of obligations that relate to those work items. Because these obligations represent risks to your project, you should regularly review the other team's progress. You can run a query or open a report that displays all active work items that have external dependencies, including information about the status of the work items upon which you depend, resolutions, project names, assignment fields, and work item IDs. You can get more information about important changes by opening work items to which your project links.

  • Generate flexible reports and support increased integration across team projects. By grouping types of work items into categories. You can query on categories and find work items that are similar but have different names across team projects.

You can perform the tasks in the previous list by adding types of links, creating queries that are based on directed links, and creating links to other team projects as described earlier in this topic.

In the previous version of Visual Studio ALM, you and other members of your team maintained relationships between two or more work items by adding a link from one work item to another. In the current version, you can create more functional relationships by using different and customizable types of links. By tracking bugs, tasks, features, requirements, value propositions, and other project elements as work items, you can create useful associations among them. You can enforce constraints, and create queries to review and track the status of their dependencies and linked work items. You can also link one work item to many work items with a single action. For example, you can perform the following tasks over the course of a development cycle:

  • Create richer associations among user stories and features. If you start with a list of user stories and a list of features, you can quickly create a work item for each item on both lists and link each user story with its set of child features. For more information, see Performing Top-Down Planning Using a Tree List of Work Items (In Excel).

  • Identify gaps in associations between requirements and features. After you create initial associations between requirements and features, you can run a query to easily verify whether every requirement is associated with at least one feature.

  • Track code defects and identify gaps in test coverage. With increased integration of work item tracking with Visual Studio Test Professional, Test Manager, and Test Runner, you can identify features that are at risk and whether all features are adequately covered by test cases. This integration includes the implementation of new types of work items such as test case and shared steps and associated link types that are defined for the Microsoft Solutions Framework (MSF) process templates. 

  • Determine bugs that are associated with requirements. When testers create work items for bugs, they can associate each of those work items with one or more features. You can then run a simple query to show all requirements that are linked to features against which active bugs have been filed.

  • Create predecessor and successor relationships between tasks. As team members create a work item for each major task, you will want to track which tasks must be completed before other tasks can start. You can create predecessor links to track this kind of dependency between work items.

You can perform the tasks in the previous list by using the following new features:

  • Use and customize types of links. Each type of link defines a set of rules and a relationship between two or more work items. These relationships can include a feature, a task, or a bug that depends on one or more other work items; a successor task; or a hierarchical relationship between tasks or work items. For more information, see Choosing Link Types to Effectively Track Your Project.

    NoteNote

    When you upgrade from the earlier version, all links are assigned the Related link type.

    You can also customize types of links. For more information about how to customize links, see Customize, Extend, and Administrate Work Item Tracking Objects.

  • Create a work item that is automatically linked. From a list of results from a query, you can create a work item that is automatically linked to a work item that you specify.

  • Add, remove, and save multiple links at a time. You can run a query to find a set of work items and then link from the current work item to multiple items in the set. You can perform this task within the form for tracking work items in Team Explorer and Team Web Access. You can also create multiple links within Office Excel and Office Project..

In this release, you can find a two-tiered set of work items based on a two-tiered set of query clauses and filters for linked associations. You can create work items for bugs, tasks, features, requirements, and value propositions for your project and then create relationships among them that meet your project's business goals. When you define these relationships, you can perform the following tasks:

  • Track and check features against value propositions. You can create a work item for each of your business goals or value propositions. If you add children as features of those value propositions, you can then review the status of all features to understand which value propositions are complete or nearing completion.

  • Review active tasks grouped by feature area. If you create parent-child associations between all of your team's features and tasks, you can then review all tasks, grouped by feature area, that are assigned to your resources. Additionally, you can subdivide each task into subtasks and create child links to the parent task.

  • Assess changes that were made to dependent work items. If you store features and tasks as work items, you can create links to track dependencies between those features. You can then quickly review the status of dependent tasks based on features to answer questions such as "Does anyone still depend on my feature?"

  • Assess changes that were made to dependent work items at a point in time. If you create links to track dependencies between features, you can create a project schedule based on those dependencies. Later, you may want to change the project schedule based on new and changed dependencies and negotiate a new contract. You can better justify new terms in the contract by running a query to identify how the dependencies have changed over time.

You can perform the tasks in the previous list by using the following new features:

  • Type of query: You can perform complex queries and view link associations between work items with the addition of these two new types of queries:

    • Work Items and Directed Links: Displays a two-tiered set of work items and their dependent links based on work-item and link-filter criteria that you specify. You can expand and collapse leaf nodes and, within Team Explorer, drag work items to change link associations.

    • Tree of Work Items: Displays multi-tiered hierarchical relationships between work items that are associated with parent-child links. You can expand and collapse leaf nodes and, within Team Explorer, drag work items to change link associations.

  • Save changes to work items: You can quickly save any changes that you make to multiple work items within the list of results from the query.

For more information about these new features, see Finding Bugs, Tasks, and Other Work Items.

In this release, you can manage how you organize and share team queries. For example, you can perform the following tasks:

  • Create a nested hierarchy of subfolders under Team Queries.

  • Organize team queries into subfolders and assign permissions to individual feature teams to manage and organize their queries in their team's folder.

  • Specify which team members can change a query or the folder hierarchy.

  • Grant access to team members to manage only their feature's query folder.

  • Restrict access to sensitive team queries to specific individuals or distribution groups.

You can perform the tasks in the previous list by using the following new features:

  • Create, delete, rename, move, copy, and paste team queries and query folders.

  • Set or restrict access to individual team queries or team query folders and subfolders. Enable or disable inherit security permissions to a team query folder.

  • Set or restrict access to query components by individual users or Team Foundation Server or Windows user groups.

  • Change the owner of a team query, folder, or subfolder.

  • Specify queries, query folders, and access permissions in the process template that was used to create a team project.

  • For more information, see Sharing Work Items and Queries with Team Members.

In this release, you can rename types of work items, create and customize types of links, create rules that govern several types of work items based on their category assignments, and permanently remove work items and types of work items. For example, you can perform the following tasks:

  • Customize work item forms by using new controls. You can use the following new controls in work item forms to support the following scenarios:

    • Link filter: Control the set of link types that can be used to link types of work items. Also, you can specify the default column fields displayed for links in a work item form.

    • Hyperlink label: Attach a hyperlink to informational text or to a field label.

    • Standalone label: Provide informational text that is not associated with any field. Optionally, you can attach a hyperlink to some or all of the text.

    • Web content: Display content from a URI or HTML-based content within a work item form.

    For more information about the new controls, see Designing and Customizing a Work Item Form.

  • Create and customize types of links. You can create and customize a variety of link types to meet the specific needs of your development environment. For example, you can create a type of link to track feature dependencies, and then you can configure the form for tracking features so that your team can add that type of link only to that specific type of work item.

    For more information, see Customizing How Work Items are Related through Link Types.

  • Open a pre-populated bug from a failed test case. If your team stores both bugs and test cases as work items, you can define a custom bug type as the default bug type. When a test case fails and the tester determines that the failure represents a defect in the product, they can open the default bug from the test tool. The bug is automatically populated with information such as the area path, the iteration path, and the build version. The tester can specify any additional information before saving the bug.

  • Rename a type of work item. You might take over management of a team that uses one or more custom types of work items whose names are misleading or ambiguous. After you rename those types of work items, the new names appear throughout the suite of tools for Team Foundation.

  • Remove work item types. If you determine that one or more types of work items are no longer useful for your project, you should remove them to prevent team members from accidentally creating work items of that type. After you remove them, neither the types nor any work items upon which they are based appear in the database or relational reports, as if the types never existed.

  • Remove pilot work items. You can remove any work items that you create as you evaluate Team Foundation Server but that you do not want in your production system. 

  • Remove unused global lists. You can remove global lists from the server.

You can perform the tasks in the previous list by using the following new features:

  • The witadmin command-line utility. By using this tool, you can perform a variety of administrative tasks that apply for a project collection or a specific team project. These tasks include creating, deleting, importing, and exporting categories, global lists, types of links, types of work items, and work item fields. For more information, see witAdmin: Administering Objects for Tracking Work Items.

  • Work item category. By using categories, you can manage multiple types of work items as a group. You manage categories through XML files much like you manage global lists and types of work items. For more information, see Grouping Work Item Types into Categories.

  • Updated object model for defining and tracking work items. Each type of work item has a reference name that never changes and a friendly display name that you can change.

  • Updated editor for process templates. You can retrieve and set the reference name for each type of work item by using the Process Editor.

    NoteNote

    The Process Editor is a power tool that is installed as an add-in to Visual Studio. You can download the power tool from the following page on the Microsoft Web site: Team Foundation Server Power Tools 2010. This tool is not supported.

In the current release, you can update the name of a team member in Active Directory, and the change is automatically updated in the corresponding work item fields at the next synchronization. This new functionality supports the following circumstances:

  • Automatic propagation of name changes throughout work items and queries. A team member marries and changes her last name. If you update her name in Active Directory, the following updates are made in Team Foundation Server:

    • Work item forms show the new name in all the person name fields and throughout the history of the work item. The team member can continue to query for and update her work items as before.

    • Both individual and team queries that are stored in Team Foundation Server are updated to work with the new name.

    • All notifications that referenced the old name are updated.

  • Ease of selecting team members who share the same name. If two team members have the same name, their e-mail aliases appear next to their names in drop-down lists for the appropriate fields. For example, you may want to assign a work item to a developer who is named John Smith, instead of to a test lead who has the same name but who works in another group. You can use the e-mail names to distinguish to which team member you want to assign the item.

  • Ability to modify work items assigned to someone who has left the team. You can modify and reassign these work items and maintain the history of the team member who left the team.

The syncnamechanges attribute was introduced so that data for fields that contain person names can be stored and updated automatically.

Important noteImportant

When you upgrade from the previous release to the current release, all built-in fields that contain person names are automatically enabled for synchronization. However, you must manually enable synchronization for any custom fields that contain person names. For more information, see Enable Synchronization of Person-Name Custom Fields.

Date

History

Reason

May 2011

Added note about where you can obtain the Process Editor.

Information enhancement.

Community Additions

ADD
Show:
© 2014 Microsoft