In the latest post of this series on Azure DevOps we will start to look at the functionality provided in Boards, this is the functionality of the tool which allows you to log work for your team to do and is importantly Scrum ready. Firstly the features provided here mean I’ll split this part into two, first we will look at the concept of work items and backlogs in this post.
Of all the teams I work with at Virgin Atlantic, the majority of the training and work I do with them is around boards. Broadly speaking this is the place where you plan, track and discuss work across your team. Remembering back to the post on projects, this can be one project team or different teams within your project.
In the next part of this post on boards we will look at Kanban boards and sprints within Azure DevOps, but first, let’s take a look at the building blocks of the boards functionality which is work items, followed by backlogs.
First of all, the work item types which are available in your project are dependant on which process your project is using. The process defines the blocks which track your work items, you can customise this through a web based editor, however every project which is using the process will inherit the changes.
Out of the box you have the ability to choose one of the following templates:
For more detailed information on all of the work items in each of the processes, the Microsoft documentation is very comprehensive. For the purposes of this post, we will be looking at using the Agile process.
Within the workflow for the Agile process, you have the ability to link together work items and work with a hierarchy, the following diagram illustrates the relationships between work items.
At the top level you have the Epic work item, you can create children of Epics, which are called Features. Then children of a Feature can be a User Story followed by a Task. Notice that an Issue is not assigned any backlog level. You can configure in the backlog settings for your project how Bugs and Tasks are handled.
Each work item type has different fields which are completed, depending on the work item you are dealing with. Common elements do exist between them though such as the Title, Assigned To and Status field, as well as the ability to add attachments and relationships to other work items.
I personally feel that the most productive place in the interface for working with your work items is the backlog functionality. For me it’s the ability to change the top level view between Epics, Features and User Stories so you can add children directly from the parent without having to remember to add the relationship in. It’s also the ability to drag around the screen to change the order of your work items, edit any work item in place without navigating away from the page and the clean interface which just make it a pleasure to work with.
Let’s start by taking a look at the Backlogs screen, by default in a new project it will look as shown in the screenshot above. Basic elements of this screen include:
- Team navigation
- Product backlog
- Drag and drop sprint planning
- Backlog level navigating
As you can have multiple teams within a project, you can use the menu at option one to navigate between the backlogs for a team. When you create a team each team has their own backlog. Once you have populated your backlog you will see them appear where the number two is shown in the screenshot above. From your backlog you can drag them to the planning section shown at number three to put work in a specific sprint or back to the main backlog.
You can navigate between your Epics, Features and Story backlogs using the navigation at number our and finally number five is where you can configure the options associated with the backlog. It’s important to note that by default Epics are not shown in the backlog level navigation drop down, you have to open Settings and then click Epic from the navigation levels and click Save and close.
So let’s create a basic Epic and start from the top, first of all change the navigation level to Epics.
When you click New Work Item from the top of the menu, you will see a pop up appear as shown above. This is where you add the name of your Epic, clicking the arrow at the right of the button at the end gives you the option of where to add your Epic, obviously for the first one it will be the same for every option. After you have a list of work items, you can then decide to add them where you have selected in the list, at the top or bottom.
For our example, let’s say we are opening a new retail store for our company. In this situation, the Epic may be the new store ID plus some extra details, something which makes it recognisable to others. Click enter and your new epic will be created. One of the reasons I love this view is the ability to work on all my work items in one place, so let’s go in and add a feature, in the default view, on the left of the Order column, you’ll see a plus sign when you hover over it. It will tell you what you can add under that level, as illustrated in the diagram at the top of the post. Under an Epic, this will be a feature.
Now how you break up your Epics and Features etc is really a team discussion, you’ll find plenty of guidance online about it and aligning that to the agile principles but in this example let’s think about the things you would need to do to open a new retail store almost by category. You’ll need lots of detailed things for sure but what about a level higher than that? You’ll need building work, shop fitting, electrical work, network connectivity and a whole lot more. Let’s create a feature using the method described above.
Initially for this post, I want to highlight two things, firstly, by default, the only required field is the title (number one), this is the only field you have to complete before saving the form. Secondly, note because of how we created the feature, the Related Work section has a parent link in to our Epic we created earlier. As before, let’s now add a user story, this is now getting close to our specific deliverable of work, we’ll add this under the Feature we have just created.
In the above screenshot you can now see our hierarchy of our three basic work items, you could of course add tasks and bugs under your user story but you get the idea hopefully of how that works now.
So how, you hopefully have a good idea of what work items are and how backlogs work. The next post on Boards looks at the configuration and usage of sprints in projects as well as Kanban boards.