AZ-400: Designing and Implementing Microsoft DevOps Solutions
Configure Activity Traceability and Flow of Work
Flow of Work SCRUM
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.
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 Item | Purpose | Example |
|---|---|---|
| Epic | High-level initiative spanning releases | Launch international payments support |
| Feature | Group of related PBIs delivering value | Payment authorization workflow |
| Product Backlog Item (PBI) | User story, bug, or task driving a feature | “As a user, I want 3D Secure...” |
| Task | Specific work unit derived from a PBI | Implement UI validation, write tests |
| Bug | Defect tracked and prioritized like a PBI | Fix transaction timeout error |
| Impediment | Blocker preventing sprint progress | Waiting on external API keys |
Note
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:
- New
- A PBI (feature, bug, or task) is created to capture stakeholder requirements.
- Approved
- The Product Owner validates alignment with goals and approves it for sprint planning.
- Committed
- The team pulls the approved item into the sprint backlog and commits to delivering it.
- Done
- The work meets the Definition of Done, passes all acceptance criteria, and is closed.
- 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.
Links and References
Watch Video
Watch video content