What Does the Agile Workflow Look like in Azure DevOps?
If you’re trying to understand work items states and reasons in Azure DevOps, you better look at the diagrams I’ve created below!
Context
At my workplace, we currently use Azure DevOps to organize our project and host its source code. Like other people on my team, I’m new to this tool. Even though I’m used to concurrent products such as GitLab, GitHub and Jira, I find Azure DevOps isn’t an intuitive tool… 🙈
To help me understand it better, I turned to the official documentation. Unfortunately, people familiar with Microsoft documents will probably understand: you’re buried with a lot of documentation that doesn’t contain what you’re looking for. ☠
One of the aspects I wanted to understand better was the Agile workflow with Azure Boards. Microsoft defines many work items for us in this process, such as stories, tasks, or bugs. And all of these have a state (eg active) and a reason for that state (eg implementation started).
While playing with those work items, I noticed that some reasons were only available when the state of the item changed… 🤨
Since I couldn’t find a visual showing the flow of each type of work item, I decided to create a free project in my time and draw lots of diagrams.
I posted them here, so if you’re also stuck like me with Azure DevOps, at least you’ll have a better understanding of it. 😅
Agile Process
I would like to thank the team at Lucid Software Inc. for the tool I used to create the following diagrams: Lucidchart. It was been a pleasure to try their free version.
Basic
In general, our work items should follow the order of the following states:
- New: work items that have been created.
- Active: work items currently in progress.
- Resolved: work items completed but not verified.
- Closed: work items that have been fixed and verified.
In some cases, you may want revert to an earlier state. For example, if you find that a bug was…
