In part one of this post on Boards, we looked at work items and backlogs in Azure DevOps. We looked at what impact the process has on your work item types and the usefulness of the Backlogs view in Azure DevOps. We finish this post on Boards by looking at the Kanban board functionality and how to configure and use sprints.

When Microsoft talk about Azure DevOps shipping Scrum ready, it is primarily these two features that make that all possible.

Kanban boards

I want to start by saying that the Kanban boards in Azure DevOps are brilliant, you can get started with no configuration and carry on going, likewise you can customise the look and feel, add style rules to format the cards, customise what is on the cards, as well as add and remove the columns.

First of all, let’s look at the navigation bar in the top right corner of the screen. If you are thinking it looks very similar to the one you see on the Backlog screen then full marks for remembering as you are correct, it is the same.

Starting from the left you have the backlog level navigation, where you can change between Epics, Features and Stories. Next is the View Options, here you can configure live updates to be on or off, I highly recommend leaving this on if you can. It means you will keep your board consistent regardless of what everyone does, without having to refresh.

Next is the filter, you can use this to scope the Kanban board to only show items assigned to you for example, filter by parent work item, team, sprint or tags. Second to last we have Settings, this is where you can customise the cards look and feel, customise the layout of the board and the behaviour of working days on your team as well as determine how you work with bugs.

Finally, the last option is to enable full screen mode, this effectively declutters the screen and gives you more screen real estate to work on your board, very useful if you have lots of cards.

When you load your board for the first time, it will automatically generate the columns from the State field on the work item you are looking at, the default is User Stories, which you can see in the screen shot above.

Simply drag your card to another column and release to move it to that column. You will notice the State field changes and if the card is unassigned it will be assigned to you as you moved it from the New state. Unlike Jira for example, where a process flow is in place and you have to follow that flow along to change the status, you do not have to do the same in Azure DevOps, you can move freely between all states which are available to you.

Using the customise options, you can add a new column in mapped to a specific field, so you can hold cards in a specific column without changing the state of the card.

Sprints

In agile methodology, a sprint is a specific time boxed allocation of work that enables you to assign work from your backlog to be worked on by the team in that allocation of time. Although this differs from team to team, typically organisations work on two week sprints, that’s 10 days of working time assuming a Monday to Friday working pattern.

In Azure DevOps, sprints are very easy to configure and assign work to and you do not have to manually start or finish the sprint, this will be done automatically when the configured start and end dates elapse.

Sprints have a task board, much like a Kanban board but instead of focusing on user stories, the task board focused on tasks, which are children of user stories. You can also view a backlog for that sprint, this is a specific backlog containing all the items you have included in that sprint. Team capacity can also be set for tasks which are calculated in hours, as opposed to story points on user stories. Finally, you can view your burndown chart for the sprint

Configuring a sprint is very easy, you basically have the following high level process to follow in order to have a sprint ready to accept work.

  1. Ensure a sprint exists, if not create a new one.
  2. Assign a start and end date to your sprint.
  3. If using hours and tasks, configure capacity to ensure you don’t over commit work.
  4. Use the main backlog view to drag work into the sprint.

That is basically all there is to it, configuring sprints is easy. Let’s do one now so you can see. The default sprint is called “Sprint 1”, you can obviously rename this to whatever you want, for the example, let’s stick with Sprint 1.

From the main Sprints section of the tool, in the top right corner you will see text saying “No iteration dates”, under here, click Set dates.

In the window that opens, you have the ability to edit the name of the iteration (this is just another name for sprint), and set the start and end date of the sprint. Go ahead and pick a two week window. Over time, you will only have to pick the start date, the system remembers the duration of your sprints and completes the end date for you. You can always change it if you need to.

When you have finished, click Save and close, the screen will refresh and in the top right corner you will now see your iteration dates configured.

Next to the dates you may see a warning triangle, this is where your mini burndown chart will appear, this just means that as the sprint dates were recently configured, the chart is not yet available. Give the screen a refresh after a few seconds and it should render.

To add items to the sprint, go back to the Backlogs page under Boards.

Adding to a sprint could not be easier, navigate to a user story for example and drag it over the sprint name, release and that work item will be assigned to the sprint. You will then see as you can see below a count of the number of work items in the sprint, and as my user story has story points assigned, it will show a count of story points under “Planned Effort”.

If you decide not to do any work on that story in this sprint, simply find the work item and drag it back to the backlog above the top sprint or another one if you have any configured.

Summary

That concludes the last post on Boards in Azure DevOps, I hope you’ve learned something about them. In the last two posts we’ve looked at work items, backlogs, sprints and the Kanban board, all fundamental elements of organising your teams work in an agile way.