If you are new to Azure DevOps, or you know the basics but haven’t explored more deeply, then this is the perfect blog series for you!
One quick caveat: I often play the role of Business Analyst or Scrum Master on project teams and may assist with QA testing for my clients. This is the context I will be focusing on in this blog series (I know next to nothing about the development side of this tool, so don’t even ask).
Before I get started, I should probably point out that, in true Agile fashion, Azure DevOps itself is constantly being updated and improved. Depending on when you read this, some of the features may or may not exist. So, with that said, let’s get started!
Pick Your Template
Azure DevOps comes with four basic “Process” or “System” Templates to choose from. This is one of the first steps in setting up your system. Which option you choose will depend on how you work and how you want to manage that work. It’s important to pick the best option for your organization from the get-go because it can be painful if you decide you prefer another template later (so make sure you understand the differences between each).
Basic
The “Basic” template is the simplest one available in Azure DevOps. It only tracks work at three levels: Epic (portfolio backlog), Issue (product backlog), and Task. If you’re all about simplicity, then this is the choice for you, but it’s also limiting and doesn’t provide as much flexibility as some of the other templates.
Agile
The “Agile” template in Azure DevOps is meant to be used with any type of agile framework. The template includes epics, features, user stories, tasks, bugs, and issues. The way bugs are handled is configurable. The main differences between this template and Scrum are terminology and time handling. In the Agile template, users are required to include an original estimate, remaining work, and completed work. This provides additional metrics that can be measured and monitored.
Scrum
The “Scrum” process template is specifically for use by teams using Scrum as their agile framework. While the “Agile” template could suffice, I prefer this template because it uses the generic term “product backlog item” rather than “user story” (because we all know that not everything in a product backlog item will be in the form of a user story).
Another reason I prefer this template is because it only requires the development team to track work remaining. To me, this is in the spirit of trusting the team and not putting an undue burden on them to use this system to track time. That is not the purpose of this tracking; it’s merely a tool to tell whether the team is on track toward completing their sprint goal.
CMMI
The final available process template in Azure DevOps is “CMMI”. I wasn’t as familiar with this one (I had to look up what CMMI means, and I was totally wrong in my guess). It stands for “Capability Maturity Model Integration” – whew, that’s a long-winded name. The key point with this template is that it’s for more traditional development methods. It includes change requests and reviews, along with issues and risks. Otherwise, it’s structured much like the Agile and Scrum templates. The main difference is that, instead of user stories or product backlog items, this template calls that level of work a “requirement”.
Which Template is Right for You? It Depends…
By now, I think you should have some idea of which template might work best for your organization. However, if you need more detailed explanations (with pretty pictures), visit Microsoft’s documentation on Choosing a Process.
So, now that you know the basics, the next top tip for your Azure DevOps set up is whether to use Area Paths.
