Using Azure DevOps to run agile development sprints

In the last post we talked about some fundamentals around using Azure DevOps for teamwork - in particular, the idea that it doesn't need to be development work that's the focus. As I mentioned last time, here at Content and Code we have all sorts of teams using the Boards capability within Azure DevOps - in addition to our development teams, architect and platform/infrastructure teams also manage their project work and week-to-week tasks in the service.

It's certainly true that DevOps is primarily targeted at developers though, and there are some great features for teams performing agile development using sprints or iterations. We'll dig into tools such as the sprint board, burndown chart and cumulative flow diagram in this article - all hugely valuable tools to help a team measure their work and continuously improve from sprint to sprint, at least once team members are in the swing of using them. 

First though, let's think about motivations.

Why do this? We've survived this long without something like Azure DevOps! 

Many organizations have development teams who are getting by with approaches they've used for a long time. There are a series of inefficiencies and guesswork that are somewhat invisible, and just accepted as "this is as good as it gets". Symptoms of this include:

• Project managers constantly asking for an update 
• Regular interruptions from colleagues, even other developers on the team
• Difficulties interpreting why changes were made
• Lack of clarity of progress against estimates
• No understanding of whether team productivity is improving or declining

Azure DevOps isn't the only way to solve these problems, but it does provide a platform to address these challenges and it certainly does a lot of the heavy lifting for you. Once the team are working in a certain way, things flow around the work items in the system - the need for conversations and interruptions to keep people's work in sync is much reduced, because many of the answers are right there in the system. This even extends to trying to avoid pinging a colleague in Teams (or Slack or other chat tool) and instead having more of the conversation in comments of an Azure DevOps work item with @mentions - this dialogue is probably useful later, either to the participants or others. Stand-ups become much more efficient, and the remaining conversation is high value rather than transactional "when will you be done with X?" type questions. 

Step 1 - create a project and choose your process (e.g. agile or scrum)

The first thing you'll need of course, is an Azure DevOps project created using the methodology you prefer. DevOps gives you four main types, but you can customize these to add your own (notice the last two items):

If you're new to these types, I would suggest:

• Basic is great for non-development or very simple work with minimal categorization of tasks (still in preview at time of writing)
• Agile and Scrum are the most common 
• CMMI is appropriate for "high-formality" development only 

The main differences are the workflow states (e.g. New, Active, Resolved, Closed, Removed for Agile, but use of Approved and Committed for Scrum, where the dev team has to "commit" to doing those tasks in this sprint) and whether user stories are used in planning. The Choose a process page in the DevOps documentation is your guide here.

The next step is to enter your work items into the system. Usually you'll break these down into user stories or features, with tasks underneath. I'm going to skip over this bit because it's relatively simple once you've created the first one, but the Add and update a work item page provides guidance. One of the key tenets of agile is to create an overall backlog of work (which is continually evolving), and then allocate this into iterations/sprints as you go along. You use a product backlog for the overall programme or project, and a sprint backlog for each iteration. 

The whole world of backlogs and boards in Azure DevOps is quite deep - see Three classes of backlogs, two types of boards as a good primer, but remember that you don't have to use every feature. 

Step 2 - set team capacity and set-up the sprint

Once you have an overall product backlog, we're ready to start thinking about chunking the work into individual sprints. I show some of the most important next steps in the video below. The first minute of the video in particular shows:

•  Defining team capacity - telling the system how many hours each team member has available per day
• This is critical for DevOps' ability to calculate how much work the team is likely to get done in a certain period. If you haven't told it how many hours are available, how could forecasting ever be possible? You can also set amounts per activity type e.g. design, development, deployment, documentation, testing etc.
• Use forecasting tools to allocate work to the next sprint - the backlog view helps you carve up the work into iterations/sprints by forecasting how much work will fit into the time available. Items are dragged into the sprint to confirm.
• Imagine a scenario where you have 2 x 20 hour tasks, compared to one where you have 10 x 4 hour tasks. Clearly there's a big difference here in the number of tasks which would get completed - the forecasting tools help you see this, by drawing a line in the task list at the point where the sprint would end - thus helping the team make decisions about what to bring in to a sprint  
• In the video I show how adjusting the "velocity" parameter (how fast the team are working) changes how much gets done - you see the line changing position in the list of tasks. The velocity number is is something you tweak over time using data from Azure DevOps

From there I show various other features around running a sprint in DevOps - use of the board, updating tasks and so on:

The video actually covers many different elements of working in sprints, not just the initial setup. Here's a summary of what we just saw in the video:

So, hopefully the video and commentary conveys some key principles of using Azure DevOps for development sprints. What about some of the tools we can use?

The burndown chart

More formally known as the "Burndown Trend report" in Azure DevOps, the burndown chart is the classic tool to help manage your sprint. It provides the team with a view of progress against the current sprint plan, indicating whether things are ahead of or behind schedule. Here's an example of a real burndown from one of our projects/sprints with a note on some of the indicators:

The blue area represents work still to be completed, and the grey line indicates linear progress from start to end of the sprint. Comparing the two helps show where you are against plan. You can use either remaining hours or number of work items to represent the work remaining, with the former usually making more sense. 

The sprint above doesn't have non-working days configured, so that would be a nice improvement to show a more accurate picture. 

For more information on the burndown chart, see Configure and monitor sprint burndown.

The Cumulative Flow Diagram

The CFD is a fantastic tool once your team has been working for a period. It helps you understand how work flows the process, in particular:

• Cycle time - how long an item is active for on average (i.e. from the time someone starts work on the item, to time of completion)
• Lead time - average end-to-end time for an item (i.e. from time of item creation to time of completion)

I use the slide below as an example of a CFD from one of our projects:

Here's a diagram which helps explain some of the various elements:

 

For more information on the Cumulative Flow Diagram, see Cumulative flow, lead time, and cycle time guidance.

Summary

Azure DevOps can really propel a development team to achieve more. Notably, some of the benefits come from centralizing updates, discussion and questions around the work items in the system - as opposed to having discussions separately and somewhat out of context (e.g. pinging a colleague in Teams). This doesn't mean that all communication happens this way, but a subtle move in this direction can help enormously. 

Aside from this, it's the following prerequisites which unlock the benefits:

• Ensuring project tasks (work items) are entered into the system, with effort estimated for each one
• Defining a series of iterations (sprints) to break the project up into time periods
• Regularly updating the "effort remaining" on tasks
• Use of the forecasting and analysis tools to continuously improve

Hopefully this has been useful. If you didn't catch the first article on DevOps Boards fundamentals, it can be found at:

Using Azure DevOps to manage teamwork

Using Azure DevOps to manage teamwork

It's been interesting observing the rise of Azure DevOps in the last couple of years at Content and Code, and in particular, seeing the usage expand beyond the development team. We now have several teams which are not dev-focused using the platform to manage their work - including architecture and platform/infrastructure teams whose work is oriented towards envisioning, design, configuration, security or testing. In many cases, team leaders have been looking for a task management tool somewhere within the Microsoft stack with deeper capabilities than Planner or To Do, and without the heavy project management emphasis of Project Online. In some cases their work involves files (e.g. PowerShell scripts or JSON snippets) but often does not. The common thing is that a team's work needs to be managed - and once introduced to Azure DevOps Boards, everyone seems to love the feature set offered by Boards and the clarity it brings to the work. Being able to understand priorities, who is working on what and how various tasks relate to each other are perhaps fundamental to teamwork but are done very well in DevOps Boards. Being able to stay up-to-date on specific items without chasing the owner starts to change the team dynamic in significant ways - it's amazing how many interruptions can be avoided and how efficient a team can become. 

Over the next couple of articles, I want to talk about how Azure DevOps can help in many scenarios - not just for advanced development teams. 

I use the slide below to summarise some of the benefits - this was in a presentation aimed at developers, but it's interesting how only a couple of the points are specific to dev work:

By the way, the slide shows a screenshot of the "Work Details" pane in Azure DevOps. This alone is hugely powerful, providing a view of the volume of work assigned to each team members and how this relates to pre-defined limits. The limits come into play by defining the capacity that each person has available in a particular period, meaning that vacations, work on other projects and anything else that takes away from time available to this work can be accounted for - thus keeping forecasts and time management accurate:

In addition to the examples in my company of architecture and platform/infrastructure teams, I think there's even a case for small support teams outside of a full ITSM process to use Azure DevOps over other tools - more on that later. Overall, I see a scale of different levels of Azure DevOps usage where only development teams running agile sprints are likely to move to level 2 or 3, but level 1 can work for so many different teams:

To unpack that a little, here's an overview of what I mean by those different usage levels:

Some of that might not mean too much at the moment, but we'll explore the different areas further in these articles.

A closer look at Azure DevOps Boards

If you're not familiar with the Boards capability, part of the premise is that the team can see a visual board of a task backlog where an item can simply be dragged to another column to update the status, similar to Post It notes on a physical board (Kanban). This is similar to Trello, Planner or some other task management tools of course. Personally, I love the following features:

• Being able to define your own columns - often these will map to an individual item status such as e.g. New, Approved, In Progress etc. but you can also map multiple states to a column such as "Build and Test"
• Being able to define swimlanes to go across the board horizontally - to help categorise items regardless of their state
• Styling rules - some examples I like to implement include:
  • Changing the card color to red for blocked or overdue items
  • Highlighting the tag displayed on the card for certain tags - the image above shows any item tagged with "Data" in a yellow highlight so the team can identify those tasks quickly for example
• Live updates - meaning that another team members changes are immediately reflected without a page refresh

Here's an example of a board showing some of those features:

Setting up an Azure DevOps project

In the video below, I demonstrate starting from nothing - creating a new DevOps project, and then adding some issues and tasks to assign to team members. I think it gives a good feel for the user experience of working with items and using some of the collaborative features:

Quite a lot of the basic features are shown in this video - defining tasks, tagging, using drag and drop to update an item's status on the board, using collaborative features such as @mentions and "following" to receive update when an item is changed, and more. The elements shown can be summarized into this list, broken down into three areas:

Summary

Getting started with Azure DevOps is quick and easy. Licensing is generally considered a good deal for what you get, with the first 5 users free and then $6 per user per month after that. In this post we explored some of the capabilities to support modern teamwork - and my experience is that they really can work amazingly well for a variety of teams. Whilst Azure DevOps has many benefits for developers, we've certainly seen it work well in other contexts too at Content and Code. 

Coming back to the different levels of usage, this article and video focuses on the first level ("Simple"):   

In the next article, I'll cover some of the agile features which help a team run sprints, including use of tools such as the burndown chart Cumulative Flow Diagram - tools which help a team understand their progress through a series of tasks and overall velocity over time: 

Using Azure DevOps to manage agile sprints