Agile process template work item types and workflow
Teams use the work item types (WITs) provided with the MSF for Agile Software Development 2013 (Agile) process template to plan and track progress of software projects. Teams define user stories to manage the backlog of work and then, using the Kanban board, track progress by updating the status of those stories.
.png "Agile 7.0 work item types")
To gain insight into a portfolio of features, scenarios, or user experiences, product owners and program managers can map user stories to features. When teams work in sprints, they define tasks which automatically link to user stories.
Using Microsoft Test Manager and Team Web Access (TWA), testers create and run test cases. Bugs and issues are used to track code defects and blocking issues.
Define user stories and estimate effort using story points
User stories define the applications, requirements, and elements that teams need to create. Product owners typically define and stack rank user stories. The team then estimates the effort and work to deliver the highest priority items.
Create user stories from the quick add panel on the product backlog page.
.png "Quick add panel, Stories backlog page")
Later, you can open each user story to provide more details and estimate the story points.
.png "Work Item Form for a User Story")
By defining the Story Points, teams can use the forecast feature and velocity charts to estimate future sprints or work efforts. By prioritizing the user stories on the backlog page (which is captured in the Stack Rank field), product owners can indicate which items should be given higher priority.
Use the following guidance when filling out the form. Required fields are so indicated.
Field/tab |
Usage |
|---|---|
Estimate the amount of work required to complete a user story using any unit of measurement your team prefers, such as t-shirt size, story points, or time. Agile velocity charts and forecast tools reference the values in this field. This is a required field to generate the velocityreport. For additional guidance, see the white paper Estimating. |
|
A subjective rating of the relative uncertainty around the successful completion of a user story. Allowed values are:
To change the menu selection, see Customize a pick list. |
|
Details (user stories) |
For user stories, provide enough detail for estimating how much work will be required to implement the story. Focus on who the feature is for, what users want to accomplish, and why. Don’t describe how the feature should be developed. Do provide sufficient details so that your team can write tasks and test cases to implement the item. Steps to Reproduce (bugs) For bugs, capture enough information so that other team members can understand the full impact of the problem as well as whether they have fixed the bug. This includes actions taken to find or reproduce the bug and expected behavior. Consider including what “Done” means by describing the criteria that the team should use to verify whether the user story or bug fix has been fully implemented. Before work begins on a user story or bug, describe the criteria for customer acceptance as clearly as possible. Conversations between the team and customers to determine the acceptance criteria help ensure a common understanding within the team to meet customers’ expectations. The acceptance criteria can be used as the basis for acceptance tests so that the team can more effectively evaluate whether an item has been satisfactorily completed. |
Track progress
Teams can use the Kanban board to track progress of user stories, and the sprint task board to track progress of tasks. Dragging items to a new state column updates the workflow State and Reason fields.
.png "Kanban board with story update")
You can customize the Kanban board to support additional swim lanes or columns. Or, you can customize the workflow for the user story and task WITs which will change the default column headings.
A typical workflow progression for a user story follows:
The product owner creates a user story in the New state with the default reason, New user story.
The team updates the status to Active when they decide to complete the work during the sprint.
A user story is moved to Resolved when the team has completed all its associated tasks and unit tests for the story pass.
A user story is moved to the Closed state when the product owner agrees that the story has been implemented according to the Acceptance Criteria and acceptance tests pass.
By updating the workflow, teams know which items are new, in progress, or completed. Most WITs support transition both forward and backward from each workflow state.
Map user stories to features
When you manage a suite of products or user experiences, you might want to view the scope and progress of work across the product portfolio. You can do this by defining features and mapping user stories to features.
From the Feature backlog page, you can quickly add features, in the same way that you added user stories.
.png "Quick add panel, features portfolio backlog page")
The feature work item contains similar fields provided for user stories, and includes additional fields, as the following table describes.
.png "Feature work item form for Agile")
The Implementation tab captures the links to mapped user stories.
Field |
Usage |
|---|---|
A subjective rating of the feature as it relates to the business. Allowed values are:
To change the menu selection, see Customize a pick list (drop down menu) [redirected]. |
|
Specify a number that captures the relative value of a feature compared to other features. The higher the number, the greater the business value. |
|
Specify the date by which the feature should be implemented. |
From the backlog page with Mapping turned on, you can drag user stories to the feature that they implement.
.png "Map a user story to a feature")
This mapping creates parent-child links from feature to user stories, which is captured in the Implementation tab.
Using portfolio backlogs, you can drill down from one backlog to another to view the level of detail you want. Also, you can use portfolio backlogs to view a rollup of work in progress across several teams when you setup a hierarchy of teams.
Define the tasks required to implement user stories and track team capacity and burndown
When your team manages their work in sprints, they can use the sprint backlog page to break down the work to be accomplished into distinct tasks.
.png "Add task link on a sprint backlog page")
Name the task and estimate the work it will take.
.png "Work Item Form for Task")
Using Agile processes, teams forecast work and define tasks at the start of each sprint, and each team member performs a subset of those tasks. Tasks can include development, testing, and other kinds of work. For example, a developer can define tasks to implement user stories, and a tester can define tasks to write and run test cases.
When teams estimate work using hours or days, they define tasks and the Remaining Work and Activity (optional) fields.
Field/tab |
Usage |
|---|---|
Original Estimate (see note 1) |
The amount of estimated work required to complete a task. Typically, this field doesn’t change after it is assigned. |
The amount of work remaining to complete a task. As work progresses, update this field. It’s used to calculate capacity charts, the sprint burndown chart, and the following reports: Burndown and Burn Rate, Remaining Work, and Status on All Iterations. If you divide a task into subtasks, specify hours for the subtasks only. You can specify work in any unit of measurement your team chooses. |
|
The amount of work that has been spent implementing a task. |
|
Select the type of activity this task represents when your team estimates sprint capacity by activity. To change the menu selection, see Customize a pick list.. |
|
Implementation |
This tab captures the parent-child links created between user stories and tasks. When you add tasks to a user story using the sprint task board, you automatically create links to the story. Using tasks, you can track the progress of work that has occurred to complete the story. This activity also supports several reports, such as the Stories Overview Report (Agile) and Requirements Progress Report (CMMI). |
Notes:
You can specify work in hours or in days. There are no inherent time units associated with this field.
If you use Microsoft Project to assign resources and track a schedule, you can update these fields using Project.
Track test progress on user stories and capture code defects
Test user stories
From Test Manager or TWA, you can create test cases that automatically link to a user story or bug.
.png "Select the test suite and add a test case")
The test case contains a number of fields, many of which are automated and integrated with Test Manager and the build process. For a description of each field, see Build and test integration field reference.
.png "Test case work item form")
The Tested User Stories tab lists all the user stories and bugs in a test case. By linking user stories and bugs to test cases, the team can track the progress made in testing each item. By defining these links, you support information that appears in the Stories Overview Report (Agile) report.
Track code defects
You can create bugs from TWA, Visual Studio, or when testing with Test Manager.
.png "Bug work item form (Agile process template)")
Field/tab |
Usage |
|---|---|
Capture enough information so that other team members can understand the full impact of the problem as well as whether they have fixed the bug. This includes actions taken to find or reproduce the bug and expected behavior. Describe the criteria that the team should use to verify whether the code defect is fixed. |
|
A subjective rating of the impact of a bug on the project. Allowed values are:
To change the menu selection, see Define a pick list. |
|
When Test Manager creates bugs, it automatically populates System Info and Found in Build with information about the software environment and build where the bug occurred. To learn more about defining the software environments, see Setting Up Test Machines to Run Tests or Collect Data.When you resolve the bug, use Integrated in Build to indicate the name of the build that incorporates the code that fixes the bug. To access a drop-down menu of all builds that have been run, you can update the FIELD definitions for Found in Build and Integrated in Build to reference a global list. The global list is automatically updated with each build that is run. To learn more, see Fields that support integration with test, build, and version control. For information about how to define build names, see Use build numbers to give meaningful names to completed builds. |
Define common work item fields and tabs
The following fields and tabs appear in most work item forms. Each tab is used to track specific information, such as History, Links, or Attachments. These three tabs provide a history of changes, view of linked work items, and ability to view and attach files, respectively.
The only required field for all WITs is Title. When the work item is saved, the system assigns it a unique ID. Other required fields are highlighted in yellow.
Field/tab |
Usage |
|---|---|
Title [Required] |
Enter a description of 255 characters or less. You can always modify the title later. |
Assign the work item to the team member responsible for performing the work. Depending on the context you are working in, the drop-down menu will list only team members or contributors to the team project. |
|
When the work item is created, the State defaults to the first state in the workflow. As work progresses, update it to reflect the current state. To change the drop-down list of states, see Change the workflow for a work item type. |
|
Use the default first. Update it when you change state. Each State is associated with a default reason. To change the drop-down list of reasons, see Change the workflow for a work item type. |
|
Choose the area path associated with the product or team, or leave blank until assigned during a planning meeting. To change the dropdown list of areas, see Add and modify area and iteration paths. |
|
Choose the sprint or iteration in which the work is to be completed, or leave it blank and assign it later, during a planning meeting. To change the drop-down list of iterations, see Add and modify area and iteration paths. |
|
Add all types of links, such as hyperlinks, changesets, source files, and so on. This tab also lists all links defined for the work item, even those defined in other links control tabs. |
|
Share more detailed information by adding files to the work item, such as email threads, documents, images, log files, or other file types. |
|
Review the audit trail that the system captures and capture additional information. Every time that the work item is updated, information is appended to the history. History includes the date of the change, who made the change, and which fields were changed. You can also add formatted text to the history field. |
To look up information about other fields, see Index of Work Item Fields.
Start tracking work
Before you start tracking work, you must have a team project. Go here to create one.
If you have a team project, start tracking work:
To get familiar with common work item tasks, see Get started using work items.
To create a backlog, use TWA. See Create your backlog.
To learn more, see Choose the Team Foundation client to support your tasks.
Q & A
Q: How can I track business value?
A: You can use the Priority field to differentiate the value of various stories. Or, you can add a custom field to the User Story WIT that tracks the relative value of stories. To learn how, see Modify or add a custom field.
Q: What workflow states does Agile support?
A: These diagrams show the main progression and regression states of Feature, User Story, Bug, and Task. To customize the workflow, go here.
Feature .png "Feature workflow states, Agile process template") |
User Story .png "User Story workflow states, Agile process template") |
Bug .png "Bug workflow states, Agile process template") |
Task .png "Task workflow states, Agile process template") |
Q: How do I resolve a bug as a duplicate?
A: Set the State to Removed and specify the Reason as Duplicate.