A while ago I wrote a free Ebook about Getting started with Azure DevOps which you can download here or if you want a hard copy you can get it on Amazon here now it is time to take a deeper look at working with Azure Boards.
Azure Boards is a tool that provides software development teams with interactive and customizable tools to manage their software projects. It has a rich set of capabilities including native support for Agile, Scrum, and Kanban processes, calendar views, configurable dashboards, and integrated reporting. These tools can be used for any small project and easily scale to use with larger projects.
You can track various types of work using default work item types such as user stories, bugs, features, and epics. You can also customize these types or create your own. Azure Boards allows you to track all your ideas at every development stage and keep your team aligned with all code changes linked directly to work items.
Process
Each Dev Ops project is created with a process, and out of the box we get Agile, Basic, CMMI, or Scrum, these processes are used to control what kind of work items are available in your project, I would recommend even if you think one of these fit your project type, that you create your own, so you have the ability to customize things so that they fit your project best. To create your own process go to Organization Settings and go to Process, choose one, and Create inherited process.
Give your process a name and a description.
Once it is created you can create a New team project using your process.
If you go to Boards -> Work items -> New Work Item you can see a list of the Work Items that can be used for this project.
If you wish to add a new Work Item type this can be done by going to Project Settings -> Process -> New work item type
Next, you can add the fields that you want to be available to your new work item type.
You can also customize what states your Work item can be in.
And you can also add rules, now hit back to your project and you should see your new Work Item Type appear in the list of Work Items.
If you choose your Helpdesk Item you can see that you can fill out Title, Description, and System.
Once you save it, you have the ability to set your work item in our new state Pending.
So that is how you can create your own Work Item Types, next let us look at the ones that are “standard” and how they should be used.
Work Items
Epic: This is a top-level work item, which is not used very often since it is very high-level, an epic can be seen as a project placeholder, an Epic should only have features as children.
Feature: The feature is a work item that is used as a container for all the tasks that need to be completed to handle any given feature, the reason why you would use features is, if a work item requires more teams to be involved or if it is too large to fit into one sprint, a feature should only have User Stories and Bugs as children.
Bug: This is used to keep track of bugs in your system, these should only have Tasks as children.
User Story: This is where a given task would be written in the customer’s own words, these should only have Tasks and Test Cases as children.
Test Case: This is used to write the test cases that a tester should perform. These should only have tasks as children.
Task: This is the lowest level in the hierarchy, and this is where a user story should be broken into as small parts as possible so it can be spilt among the correct people, this is also where you will keep track of the time spent.
Issue: This is used to make any issues that might stop you from completing a task, it can be anything from not having access to a given server, or a team member needs to attend a course to be able to solve the task.
Let us try to create a new feature with some user stories and tasks.
Save this feature, and add some related work.
Choose New Item, and make sure that the link is Child, choose User Story as work Item type:
Press Save and add some related work.
Give it a description, an Activity, which is used for planning, and an Estimate.
Next, go back to your User Story and create a Task for calling the Azure Function to send the item to Magento.
Next, go back to your User Story and create a Test Case.
Next, Go back to your User Story and create a Task, this time set the activity type to Testing:
The main difference between the Test Case and this Test Task is that the Test Case is more targeted toward flow testers, while the test task is for functional testing. If you go back to your Work Items your list should look something like this:
Now that we have some work items to work with let us look at Boards.
Boards
Boards are Azure DevOps way of running Kanban, the idea behind Kanban is that you keep pushing updates to your system, which is also the main idea behind Lean development, my board looks like this:
Now you might notice that I can only see my User Story but if you click on the task icon you can also see my tasks, however, you cannot track progress on Task level on the Kanban board, and that is because as I mentioned earlier Kanban is meant to be very simple, but that also means that it is very difficult to get a complete view on how your project is running. You might also notice that in the Active and Resolved columns, there is written 0/5 and that is because in Kanban you should never have more than 5 user stories in active at any given time, and the same goes for Resolved and that is because it is built on the Lean mindset that we should push new features constantly, now I am not going to use much time on the Kanban board because it is very simple and it should only be used for simple “projects” but like anything else in Azure DevOps you can customizing your Kanban to have more columns if you wish so, this is done by clicking the gear icon and going to columns.
Let us move on to Sprints.
Sprints
Now Sprints is where I feel that DevOps really shines, now it does take some setup to get it working, but once it is set up it is a very powerful tool, when you click on Sprints you might be met by this screen:
And that is because our work items are not assigned to an iteration, which means that they are on our backlog, to assign our work item to an iteration (sprint) press the Schedule Work, or the Backlogs link in the menu.
This will take you to a view where you can see the complete list of all your work items, you might wonder why you can not see your Feature but only your user story, and that is because by default there is a filter on Stories, you can change this in the top corner, however, I do not recommend that you do this, because a feature should not be assigned to a sprint, because remember that a Feature is used a placeholder for a task that is either too large to fit in one sprint or it is split among different teams. To assign your user story to your iteration, all you have to do is drag and drop it to the iteration that you want it to be in. If you cannot see the Planning side pane you can turn it on by going to:
As you can see in our box you will have three Iterations called Iteration 1,2,3 and you can always see which one is your current iteration by looking and the blue Current box. Once you have dragged it to your Iteration, two things will happen, your Iteration Path will be updated and you can see it in your Planning side pane.
Now go back to your sprints and you should see something like this:
So as you can see, unlike the Kanban board, now you can see your Tasks, and you can also see how much time is remaining on each task, and the sum can be seen on the User Story, which is great, but we can do even better, so head over to the Capacity tab, here you can set up the capacity of all the team members. So I will add a couple of people.
Next, give them a capacity per day, and what kind of activity they will be performing, you can also register if they have any days off in the iteration this will then be subtracted from their overall capacity.
Remember to press Save and then go back to the Taskboard, at first glance you might not see any difference but that is because we need to setup som dates for our iterations so in the top right corner click the Set dates:
Here you can also change the name of your iteration if you wish:
If you assign your tasks to some of your team members, and then turn on the work details pane you will get an overview of if your project is on track:
If we try to set one of the tasks to 100 hours you can see that the overview will turn red.
So even though our team as a whole does have the time to take on the tasks, then since we only have one tester and her task has more hours than her capacity, we can see that we have a problem, which can either be solved by adding a tester more to our iteration or asking one of our other team members to help our testers, so using this setup will help you in planning your work and making sure that you have the resources that you need to complete your sprint.
The flow will now be that once you start working on a task you will drag that task to the Active column, and this will update the number of hours in the active state.
Once you get started it is important that at the end of the day, you update the Remaining work on the task because this will make sure that everything is still on track, this is done either by changing the number or by opening the task and updating the field or doing it directly from the Taskboard, so if I set mine to 5 hours because it took longer than I had anticipated.
if I enter my task I will see that the original estimate is still 2 while the remaining is 5, which we can then use in our retrospective meeting about what might have gone wrong.
So to sum up, once you get your Azure DevOps boards setup it can be used to control your workflows and it can be used to get an in-depth look at how your projects are running, and if you really want to get the most out of all the data then I would suggest that you take a look at Dashboards and queries but that was it for this post since it is already way too long, until next time stay safe.