Skip to main content
Scrum is an agile framework that structures development into fixed-length iterations called sprints, enabling rapid feedback, continuous improvement, and high adaptability. In Azure DevOps, the Scrum process template extends the Basic process by introducing three additional states—Approved, Committed, and Removed—to give teams finer control over work-item progress and feedback loops.
The image is a slide titled "When to use a SCRUM template?" with three points: "Team anatomy emphasized," "Frequent stakeholder feedback," and "Agile product development," each accompanied by an icon.
When to choose a Scrum template in Azure DevOps?
  • You want to emphasize clear team roles and self-organization.
  • You require frequent stakeholder feedback to guide development.
  • You plan for rapid, iterative delivery aligned with agile product development.

​
Scrum Work-Item Hierarchy

Azure DevOps organizes Scrum work items into a clear hierarchy. This structure helps you map strategic goals to deliverable tasks and defects.
Work ItemPurposeExample
EpicHigh-level initiative spanning releasesLaunch international payments support
FeatureGroup of related PBIs delivering valuePayment authorization workflow
Product Backlog Item (PBI)User story, bug, or task driving a feature“As a user, I want 3D Secure…”
TaskSpecific work unit derived from a PBIImplement UI validation, write tests
BugDefect tracked and prioritized like a PBIFix transaction timeout error
ImpedimentBlocker preventing sprint progressWaiting on external API keys
Track PBIs and bugs on the Kanban board for visibility, then split them into Sprint tasks on the taskboard to manage day-to-day work and remaining effort.

​
Backlog-Item Lifecycle in Scrum

The lifecycle of a backlog item in Scrum—from creation through completion or removal—follows a set of well-defined states:
The image is a workflow diagram showing the progression of a backlog item through stages: New, Approved, Committed, and Done. Each stage includes a condition, such as approval by the product owner or commitment by the team.
  1. New
    • A PBI (feature, bug, or task) is created to capture stakeholder requirements.
  2. Approved
    • The Product Owner validates alignment with goals and approves it for sprint planning.
  3. Committed
    • The team pulls the approved item into the sprint backlog and commits to delivering it.
  4. Done
    • The work meets the Definition of Done, passes all acceptance criteria, and is closed.
  5. Removed
    • At any point, items can be removed if priorities shift or the work is no longer needed.
Throughout each sprint, newly discovered work is added to the backlog, reprioritized, and planned in upcoming iterations. This iterative loop ensures that the team continuously delivers value and adapts to stakeholder feedback.

Watch Video