Add Your Heading Text Here
Azure DevOps work item
A work item in Azure DevOps is a record used to track a single piece of work, such as a user story, bug, task, feature, or epic. Work items hold the details, status, and links for that work, and together they make up the backlogs and boards a team uses to plan and deliver in Azure Boards.
What it means
The hierarchy exists so a team can plan at more than one altitude. Epics capture big, multi-month goals. Features break an epic into shippable capabilities. User stories break a feature into pieces small enough to finish in a sprint. Tasks are the actual steps to build a story. Each level rolls up into the one above, so progress on stories tells you how the epic is doing.
For requirements work, this structure doubles as a traceability spine. A requirement expressed as a user story traces up to the feature and epic it supports, and down to the tasks and tests beneath it. Keeping the hierarchy clean is what makes rollups and traceability meaningful. When stories float without parents, the higher-level view stops reflecting reality.
In practice
A team planning a new checkout flow creates an epic for it, breaks that into features like 'guest checkout' and 'saved cards', and breaks each feature into user stories such as 'save a card during checkout'. A stakeholder can look at the epic and see progress without reading a single task, because the work rolls up the chain.
Häufig gestellte Fragen
What is the order of the work item hierarchy in Azure DevOps?
Why use a work item hierarchy?
Manage requirements the modern way
Modern Requirements brings documentation, traceability, and reviews together inside Azure DevOps.
