Work Item State Description
This guide describes the different states of Azure DevOps (ADO) work items. Consistent work item state transitions are essential to enable consistent follow up on status.
This work item description is in line with the following:
Intended for
Product owners and development team members.
Interpreting a state
In general, a state is indicating the following:
- New: Something to be done.
- Active: Work started.
- Resolved: Development done (including unit tests on story level and component test on feature level).
- Closed: Definition of done (DoD) fulfilled.
Work items and their states
The work items have the following states and definitions.
| Type | New | Active | Resolved | Closed |
|---|---|---|---|---|
| System epic | When created | When DoR fulfilled and first child is active | When development is done → When all arch/dev epics are closed | When DoD fulfilled |
| Epic | When created | When DoR fulfilled and first child is active | When development is done → When all arch/dev features are closed | When DoD fulfilled |
| Feature | When created | When DoR fulfilled and first child is active | When development is done → When all children are closed | When DoD fulfilled |
| User story | When created | When DoR fulfilled and first child is active | When development is done → When all children are closed | When DoD fulfilled |
The DoR/DoD guide provides details about definition of ready (DoR) and DoD.
Work items and types of children
- System epic
- Architecture epic.
- Development epics.
- System integration test (SIT) epic.
- Epic (*)
- Architecture feature.
- Development features.
- Documentation feature (product capability, architecture, user documentation).
- Product integration test (PIT) features.
- Feature
- Development user stories.
- Documentation user story (up to the team to decide).
- Component/function tests (up to the team to decide).
- User Story
- Tasks.
() If an epic is implemented in just one component, all testing/documentation is done at the component level.
() If the features of an epic are vertical slices (implementing end-to-end functionality) and independent, typically, most testing is done by the development team
Work item example
Below is an example with the different work items and their children
- Blue arrows show development relations.
- Red arrows show test relations.
- Green arrows show gate relations.
Questions & Answers
Q: Can some state transitions be automated (for example, when a child item is "Active", the parent is automatically set to "Active")?
No - not yet...
Q: Who is responsible for updating the states for each work item type?
Generally, the appointed work item assignee, but see the table in the appendix for details.
Q: Should development be started if the parent work item is in state "New"?
DoR on the parent must be fulfilled before development is allowed to start.
Q: Development work items, documentation work items, test work items, and architecture work items are mentioned. Are all of them optional to have created under a parent?
The generic approach for business/development work items is described in the section Work items and types of children, but it can be tailored according to the release project setup if necessary.
For example, an enabler epic or architecture epic will not have the same children.
Q: Must all work items, except system epic, be linked to the parent? Or are orphans allowed?
The generic idea is that all work items (except bugs) shall be linked to a system epic. The system product owner is responsible for setting up system epics that also cover enabler epics.
Q: Can a user story be linked to an epic?
No, all levels shall always be used. So, a feature shall be created, or the epic should be a feature in the first place.
Q: Can an epic have a child epic?
No. Instead, "Related to" or "Successor/Predecessor" shall be used for dependencies between work items on the same level.
References
Appendix
The general (*) role responsible for changing state:
| Type | New | Role | Active | Role | Resolved | Role | Closed |
|---|---|---|---|---|---|---|---|
| System epic | When created | System product owner | When DoR fulfilled and first child is active | System product owner | When development is done → When all arch/dev epics are closed | System product owner | When DoD fulfilled |
| Epic | When created | Product owner | When DoR fulfilled and first child is active | Product owner | When development is done → When all arch/dev features are closed | Product owner | When DoD fulfilled |
| Feature | When created | Dev team | When DoR fulfilled and first child is active | Dev team | When development is done → When all children are closed | Product owner | When DoD fulfilled |
| User Story | When created | Dev team | When DoR fulfilled and first child is active | Dev team | When development is done → When all children are closed | Dev team | When DoD fulfilled |
(*) The different streams might have done some tailoring, e.g., for some teams, the product owner is handling the transitions of features