Azure DevOps Work Items
Overview
Azure DevOps supports different work item types (WITs) to help teams manage software development projects efficiently. The specific work items available depend on the process template used (Agile, Scrum, Basic, or CMMI). Below are the primary work item types in Azure DevOps.
1. Work Items Common Across All Process Templates
1.1. Epic
- A high-level objective representing a large body of work that can be broken down into Features and User Stories/Backlog Items.
- Example: "Implement Authentication and Authorization System."
1.2. Feature
- Represents a major system capability or area of functionality.
- Features are linked to Epics and broken down into User Stories or Backlog Items.
- Example: "User Login Functionality."
1.3. User Story (Agile) / Product Backlog Item (Scrum)
- Represents a functional requirement from an end-user perspective.
- Typically written in the format: "As a [user], I want [goal] so that [reason]."
- Example: "As a user, I want to reset my password so that I can regain access to my account."
1.4. Task
- Represents a specific unit of work that contributes to completing a Story, Backlog Item, or Bug.
- Example: "Design login page UI."
1.5. Bug
- Used to track defects or issues in the application.
- Can be linked to Features, Stories, or Backlog Items.
- Example: "Login button not responding after page refresh."
2. Additional Work Items Based on the Process Template
2.1. Process Template: Agile
Work Item Type |
Description |
Issue |
Represents a risk, blocker, or impediment. |
Test Case |
Used for defining test conditions and validation steps. |
2.2. Process Template: Scrum
Work Item Type |
Description |
Impediment |
Represents anything blocking the team’s progress (similar to Issue in Agile). |
Test Case |
Defines test steps and expected results. |
2.3. Process Template: CMMI (Capability Maturity Model Integration)
Work Item Type |
Description |
Requirement |
Equivalent to a User Story or Backlog Item in other templates. |
Change Request |
Used to track requested changes to existing functionality. |
Risk |
Identifies project risks. |
Review |
Captures peer reviews and formal assessments. |
2.4. Process Template: Basic
Work Item Type |
Description |
Issue |
Used to track problems or tasks that need resolution. |
Task |
A unit of work needed to complete an Issue. |
3. Special Work Items
3.1. Test Plan, Test Suite, and Test Case
- Found in Azure Test Plans, used for managing manual and automated tests.
- Example: "Verify login with correct credentials."
3.2. Release Work Item
- Tracks releases and deployments.
3.3. Deployment Work Item
- Captures details of a specific deployment.
Hierarchy of Work Items
graph TD
A[Epic] --> B(Feature)
B --> C(User Story/Backlog Item/Requirement)
C --> D(Task/Bug)
Choosing the Right Work Item
Work Item |
When to Use |
Epic |
To define high-level project goals spanning multiple teams. |
Feature |
To break down Epics into major functionalities. |
User Story/Backlog Item |
To capture detailed functionality requirements. |
Task |
To track specific work needed to complete a Story. |
Bug |
To report and fix defects. |
Issue/Impediment |
To log problems or blockers affecting progress. |
Conclusion
Azure DevOps provides a structured approach to work tracking, with different work item types suited for various software development methodologies. Whether you follow Agile, Scrum, Basic, or CMMI, choosing the right work item ensures clear documentation, better collaboration, and streamlined project management.