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 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.
Here's a diagram which helps explain some of the various elements:
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 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:
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:
No comments:
Post a Comment