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 | Azure DevOps Server 2020
Workflows play a central role in managing work items: they consist of states, transitions, and reasons and are defined per work item type. Transitions let you move work items forward and backward between states. When you add a custom state, the system automatically creates transitions between that state and all inherited states (except Removed).
Azure Boards uses state categories so Agile planning tools and dashboards treat workflow states consistently across backlogs and boards.
Workflow states
Workflow states define how a work item progresses from creation to closure. For the User Story (Agile process), the primary states are New, Active, Resolved, and Closed. Use the Removed state to remove a work item from the backlog; for details, see Move, change, or delete work items.
The natural progressions and regressions for common work item types—user story (Agile), issue (Basic), product backlog item (Scrum), and requirement (CMMI)—appear here:
Workflow states: User Story, Agile process
Category states
State categories determine how Agile planning tools and dashboard widgets treat each workflow state. Teams map workflow states to the following category states used by backlogs, boards, and widgets: Proposed, In Progress, Resolved, and Complete.
The following table shows how the default inherited states map to category states for the four system processes, including Test Plan work item types. Test Case, Test Design, and Test Suite workflows remain consistent across the four system processes.
Categories
Work tracking
Test tracking
Proposed: Assign this category to newly added work item states so they appear on the backlog. The first column on boards and Taskboards maps to Proposed.
New
Design (Test Case)
In Progress: Assign this category to states that represent active work. Work items in In Progress appear in the backlog (unless hidden) and occupy the middle columns on boards.
Active (Bug, Epic, Feature, User Story)
Active (Test Plan); In Planning (Test Suite); In Progress (Test Suite); Ready (Test Case)
Resolved: Assign this category to states that indicate a solution implemented but not yet verified (commonly used for bugs). Resolved states appear on the backlog by default and can be included in burndown charts. Azure Boards treats Resolved the same as In Progress for many tools.
Resolved (Bug)
n/a
Completed: Assign this category to states that represent finished work. Work items in Completed don't appear on the backlog and appear in the final column on the board. You can't modify or add states to this category.
Closed (Bug, Epic, Feature, User Story)
Closed (Test Case); Completed (Test Suite); Inactive (Test Plan)
Removed: Assign this category to the Removed state to hide items from backlog and board experiences.
Removed (Epic, Feature, User Story)
n/a
Work item types and their boards
Know where each work item type appears so you can manage work effectively.
| Work item type category | Work items appear here |
|---|---|
| Requirement | Only on the product board. |
| Feature | Only on the Feature portfolio board. |
| Epic | Only on the Epic portfolio board. |
| Custom | Only on a custom portfolio board. |
Tip
Map each workflow state to a board column. If a state isn't mapped, it doesn't appear on the board.
Note
Completed or closed work items don't display on the backlogs and boards after their Changed Date value is greater than 183 days (about a half a year). You can still list these items by using a query. If you want them to show up on a backlog or board, you can make a minor change to them, which resets the clock.
Note
Completed or closed work items don't display on the backlogs and boards after their Changed Date value is greater than a year old. You can still list these items by using a query. If you want them to show up on a backlog or board, you can make a minor change to them, which resets the clock.
Activated By/Date and Resolved By/Date fields
The system updates these fields—Activated By, Activated Date, Resolved By, and Resolved Date—when a change occurs based on corresponding workflow category states. When the workflow state changes to an In Progress state category, Activated By and Activated Date are updated. When the workflow state changes to a Resolved state category, Resolved By and Resolved Date are updated.
To learn more how workflow states map to state categories, see How workflow states and state categories are used in Backlogs and Boards.
Note
The logic governing the fields described here applies to Azure DevOps Services, Azure DevOps Server 2020.1 update, and later versions.
Because these fields reference the workflow state categories, custom workflow states that you add are referenced when updating the fields. To learn more about customization, see Customize the workflow for a process.
Additional notes:
- The fields get updated anytime a work item moves from any category state other than that being set. For example, if you update a work item from New to Fixed, the Resolved By/Resolved Date fields are updated. However, if you update from Fixed and Ready for Testing—which are in the same category state—the Resolved By/Resolved Date fields aren't updated.
- When you transition backwards, such as going from a Resolved to an Active state, the system clears the values for Resolved By/Resolved Date fields. If you got from Active to New, the system clears the values for Activated By/Activated Date fields.
- Don't manually change the values for these fields. They are system fields that are governed by system rules. Any value you attempt to set gets over written.
When to add a State versus a column
Use States and columns together to track work status. States apply at the project level; columns apply at the team level. Only project collection admins can add custom states; team admins can add columns.
Add custom states when you want to align teams to a shared organizational workflow. Custom states propagate to projects and work item types that reference the process.
Prefer shared custom states when multiple teams use the same workflow to avoid confusion from different teams basing queries on columns. Maintain single ownership of work items by team area path or standardize columns by adding custom states shared across teams.
Auto completion of work items with pull requests
When you link a work item to a pull request (PR), you can automatically complete those work items when you complete the PR. For details, see Auto complete work items with pull requests.
Automate work item state transitions
You can update a parent work item's state automatically based on the state of its child tasks. For details, see Automate work item state transitions.
Related content
Inheritance process model
On-premises XML process model
Dashboard widgets
- Explore Lead Time and Cycle Time control charts (widgets) ::: moniker-end