Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
In Azure Boards, the Agile process uses work item types (WITs) to help your team plan, prioritize, and track progress. The Agile process includes epics, features, user stories, tasks, issues, and bugs. After you define your WITs, you can track progress by updating work item states.
To gain visibility into a portfolio of features, scenarios, and user experiences, product owners and program managers map user stories to features. Teams working in sprints then define tasks that link to those user stories. If you're new to the Agile process, see Plan and track work with Agile.
This article shows you how to:
- Define and prioritize user stories.
- Track workflow state as work moves from new to done.
- Break stories into sprint tasks and estimate remaining work.
- Link test cases and bugs to track quality and defects.
In Azure DevOps Services, testers create and run test cases in the web portal. In Azure DevOps Server, testers can also use Microsoft Test Manager to track code defects and blocking problems.
Define user stories
Product owners typically define and stack-rank user stories that describe application requirements and work elements. The team then estimates the effort required to deliver the highest-priority items.
Create user stories from the quick add panel on the Product Backlog page. You can also drag and drop items on the page, reorder them, and map items to features.
Open each user story to add details and estimate story points. Define Story Points so your team can use the forecast feature and velocity charts to estimate future sprints and work effort. By prioritizing user stories on the backlog page (captured in the Stack Rank field), product owners indicate which items have higher priority.
Use the guidance in the following table and the common fields used across work item types when you complete the form.
Field
Usage
For user stories, provide enough detail for estimating how much work is 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. Provide sufficient details so your team can write tasks and test cases to implement the item.
Provide the criteria to be met before the bug or user story can be closed. Before work begins, describe the customer acceptance criteria as clearly as possible. Conversations between the team and customers to define the acceptance criteria help ensure your team understands your customers' expectations. You can use the acceptance criteria as the basis for acceptance tests to more effectively evaluate whether an item is satisfactorily completed.
The area of customer value addressed by the epic, feature, requirement, or backlog item. Values include:
- Architectural: Technical services to implement business features that deliver solutions.
- Business: (Default) Services that fulfill customer or stakeholder needs and directly deliver customer value to support the business.
Estimate the amount of work required to complete a user story by using any numeric unit of measurement your team prefers. Agile velocity charts and forecast tools reference the values in this field. For more information, see the Estimating white paper.
A subjective rating of the user story, feature, or requirement as it relates to the business. Allowed values are:
- 1: Product can't ship without the feature.
- 2: Product can't ship without the feature, but it doesn't have to be addressed immediately.
- 3: Implementation of the feature is optional, based on resources, time, and risk.
A subjective rating of the relative uncertainty of the successful completion of a user story. Allowed values are:
- 1 - High
- 2 - Medium
- 3 - Low
Capture comments in the Discussion section
Use the Discussion section to collaborate on work items by adding and reviewing comments.
When you place your cursor in a text box that supports formatting, the rich-text editor toolbar appears.
Note
A Discussion work item field doesn't exist. To query work items with comments from the Discussion area, filter on the History field. The full content of the text entered in the Discussion text box is added to the History field.
Mention someone, a group, work item, or pull request
Use one of the following icons to open recent entries for people, work items, or pull requests:
You can open the same menu with keyboard shortcuts: at-mention @, hashtag #, and exclamation point !.
Enter a name or number to filter the list, and then select the item you want to add. To mention a group, enter @ followed by the group name, such as a team or security group.
Edit or delete a comment
To update or remove one of your comments, select Edit 
or select More actions (
) and then select Delete:
After you change a comment, select Update. To remove a comment, confirm deletion. The History tab maintains an audit trail of all edited and deleted comments.
Important
For on-premises Azure DevOps Server, configure an SMTP server so team members can receive notifications.
Add a reaction to a comment
Add one or more reactions to a comment by selecting an emoji on the comment. To remove your reaction, select the same reaction again. The following image shows an example of adding and viewing reactions on a comment.
Save a comment without saving the work item
Note
This feature is available starting in Azure DevOps Server 2022.1.
If you only have permissions to add to the Discussion of a work item, then you can do so by saving comments. This permission is controlled by Area Path nodes and the Edit work item comments in this node permission. For more information, see Set work tracking permissions - Create child nodes, modify work items under an area or iteration path.
When you save comments, you don't need to save the work item.
Note
When you save changes made to the Discussion control, only the comment is saved. No work item rules defined for the work item type are executed.
Track progress
As work progresses, update the State field to reflect status. You can optionally specify a reason. The State and Reason fields appear in the header area of the work item form:
Agile workflow states
As teams update workflow states, they can identify which items are new, in progress, or completed. Most WITs support forward and backward transitions between states. The following diagrams show the main progression and regression states for user story, bug, and task WITs.
Here's the typical workflow progression for a user story:
- The product owner creates a user story in the New state with the default reason, New user story.
- The team updates the story status to Active when they decide to complete the work during the sprint.
- The story moves to the Resolved state when the team completes all associated tasks and the unit tests pass.
- The story moves to the Closed state when the product owner agrees the story is implemented according to the Acceptance Criteria and acceptance tests pass.
Update status with the board or taskboard
Teams can use the board to update the status of requirements, and the taskboard to update the status of tasks. Dragging items to a new state column updates both the State and Reason fields.
You can customize the board to support more swimlanes or columns. For more information, see Customize your work tracking experience.
Map user stories to features
When you manage a suite of products or user experiences, you might need to review work scope and progress across the portfolio. Use features and mapping from user stories to features to track that rollup.
Using portfolio backlogs, you can drill down from one backlog to another to view the level of detail you want. Also, use portfolio backlogs to view a rollup of work in progress across several teams when you set up a hierarchy of teams.
Define tasks
When your team manages work in sprints, use the sprint backlog page to break down planned work into distinct tasks.
Enter the task name and estimate the effort in the Effort field:
When you use the Agile process, teams forecast work and define tasks at the start of each sprint. Each team member then completes a subset of those tasks. Tasks can include development, testing, and other work. For example, a developer might define tasks to implement user stories, and a tester might define tasks to write and run test cases.
When teams estimate work according to the number of hours or days, they define tasks and the Remaining Work and Activity (optional) fields.
Field
Usage
The amount of estimated work required to complete a task. Typically, the field value doesn't change after you enter the initial value. You can specify work in number of hours or days. There are no inherent time units associated with this field.
The amount of work remaining to complete a task. As work progresses, update this field. 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. This field is used to calculate the following charts and SQL Server reports:
The amount of work spent implementing a task.
Select the type of activity this task represents when your team estimates sprint capacity by activity.
The product build number that incorporates the code or fixes a bug.
Track test progress
Track testing progress by using user stories and bugs for code defects. For guidance on tracking other issue types, see Track other issues.
Test user stories
In Azure DevOps Services, you can create test cases that automatically link to a user story or bug in the web portal. In Azure DevOps Server, you can also use Microsoft Test Manager. You can also link a user story to a test case from the 
Links tab.
The test case contains multiple fields, many of which are automated and integrated with test management and the build process. For a description of each field, see Query based on build and test integration fields.
The
Links tab captures links to user stories and bugs in a test case. By linking user stories and bugs to test cases, the team can track testing progress for each item. These links also support information shown in the SQL Server Stories Overview report.
Track code defects
To track testing for code defects, create bugs from the web portal, Visual Studio, or Microsoft Test Manager.
Definitions for common work tracking fields
The following fields and tabs appear in most work items. Common tabs include 
History,
Links, and 
Attachments.
For all work item types, Title is the only universally required field. When you save a work item, Azure DevOps assigns a unique ID. Required fields are highlighted in yellow. For more fields, see Work item field index.
Note
Other fields might be required based on process and project customizations.
| Field or tab | Usage |
|---|---|
| Title | Enter a short description (up to 255 characters). You can edit the Title later. |
| Assigned To | Assign the work item to the person responsible for completing it, or leave it unassigned until ownership is clear. |
| State | On creation, State defaults to the first workflow state (such as New or Unassigned). Update it as work progresses. |
| Reason | Reason explains why the item is in the current State. Default values vary by work item type and process. |
| Area | Select the area path for the product or team. For details, see Define area paths and assign to a team. |
| Iteration | Select the sprint/iteration for planned completion. For details, see Define iteration paths (sprints) and configure team iterations. |
|
History tab |
View the full change log for the work item, including author, date, and updated fields. You can also add formatted text in History. |
|
Links tab |
Add relationships to other artifacts (for example, parent/child work items, changesets, source files, or test results). |
|
Attachments tab |
Add supporting files such as documents, images, logs, or email threads. |
Track other issues
Use issues to track events that might block progress or prevent shipping a user story. Use bugs to track code defects. Add an issue by using the New work item widget on a team dashboard, or from the New menu on the Queries page.
Work items you add from the widget are automatically scoped to your team's default area and iteration paths. To change team context, see Switch team context.
Track business value
Use the Priority field to differentiate the value of stories. You can also add a custom field to the User Story WIT to track relative story value. For more information, see Customize a field for a process.
Backlog list order
The Stack Rank field tracks the relative ranking of user stories. By default, the work item form doesn't show this field. The sequence of items on the backlog page is determined by where you add or move the items on the page. As you drag items, a background process updates the Stack Rank field.
Customize work item types
For most work item types, you can add fields, update the workflow, define custom rules, add custom pages, and create custom work item types. For more information, see Customize an inheritance process.
For most work item types, you can add fields, update the workflow, define custom rules, add custom pages, and create custom work item types. For more information, see Customize an inheritance process or Customize the On-premises XML process model, depending on your process model.