Configure iterations in Azure Boards
Once you select a process template for your project and modify the template, it's time to configure the project planning.
Certainly in Agile process templates, you'll deliver code every couple of weeks. If we look back at how software was developed 10 years ago, you had a specific add-on you wanted to develop, and the add-on was only released when all features were developed. This process could take years. These days, software development is shifting to shorter development and release cycles. A typical development cycle could be as short as two weeks. After that two weeks, you can create a test release and deliver it to the customer.
Cycles can be a bit longer or a bit shorter, but we work in cycles. Not all features will be immediately available for the customer, but it will be easier to plan the release of a specific feature. Agile and Scrum is working this way, and the Basic templates support the usage of cycles or Iterations.
If we look at Scrum, there's a user that has the role of Product Owner. This person groups all requests coming from the customers, management, salespersons, internal, and so on. The product owner creates User Story, Issue, or Bug work items, and manages all those work items and prioritizes them.
In the Work Items menu, you can register all the work items in Azure Boards under the Boards section. This is just a list with all the different work items, where you can filter on type, assigned to, state, and other fields. Whenever a new request comes in, the product owner has to create a new work item in this list. This can also be automated by using the Azure DevOps API.
The work items list has no grouping or prioritizing functionality. The next step is to prioritize the different work items, because not everything can be developed within an iteration of two weeks. So, you can select the menu Backlogs in the Boards section. This will again show you the work items, but tasks will be grouped under a User Story, Bug, or Issue. In the Basic template, there's only an issue and tasks.
Here the product owner can drag the different work items to order them. Based on the available time of the team and the iteration duration, Azure DevOps will automatically suggest which work items can be developed in which iteration. An iteration is also called a Sprint.
At the right side of the page, you can see a section called Planning with a block containing the name of the project and Team Backlog. The name of my project is Basic, so the block displays Basic Team Backlog. This is the link you need to select to see all the work items prioritized. Under the Team Backlog, all the different iterations will be listed. You can always add new iterations by selecting the New Sprint button. The system won't automatically generate the sprints.
Next step is to drag and drop work items from the Backlog onto a sprint. This will plan the work items in an iteration. You can select the iteration title or select the Sprints menu to open an iteration. The iteration page has four tabs where you can see the work items displayed in a Taskboard (Kanban) view. You can see the items in the Backlog, which will show them in a list. You also have a tab Capacity and a tab Analytics.
In a Taskboard, the Issues or User Stories are displayed on the left side. You can select the green button with the plus sign to add new tasks on a User Story. In this example, two tasks are already created for the issue, but we can add a third one that requires the developer to add the Facebook field to the list page.
Once tasks are created, the developers can start working on the different work items. They can easily drag and drop them to another stage once they are working on it. If you start working on a task, drag that task to the Doing column. This is needed to get a good overview on the status of the project.
To get a realistic overview on the progress of the project, you also need to set the capacity per user. In the Capacity tab, you can add all the users that will work on that project, and how many hours they have available per day. Keep in mind that this is an average. You can't specify the number of hours per day. You can also specify this per activity. Maybe Developer A has a total availability of 5 hours per day, where 3 hours are used for development and 2 hours for documentation. You can add all those combinations in the capacity planning. You also need to specify any days off per user.
Azure DevOps will then calculate how many hours are available in total for the whole team, per developer, and per activity. You need to set this per iteration. The next step is to define the Remaining work on each task, then DevOps can calculate if there are too many tasks, or a user isn't overbooked. You can also specify the activity per task.
On the task board, you can select the View Options button and select Work details to be displayed in the Side Pane.
By doing this, you get an overview of the workload for the complete team, but also per team member, and per activity. If a bar is displayed in red, then there is a problem with the workload.
After specifying the capacity, the remaining work on tasks, and moving the tasks to their correct status on the Taskboard, the management (but also the team) can follow their progress using the Burndown chart. If you select the Analytics tab on the sprints page, a chart is displayed that will show the remaining capacity. This is calculated based on the capacity of the team including all the days off. It also displays the ideal trend line, based on the amount of work, and the Remaining work, calculated by all tasks that are not finished.
In the previous Burndown chart, you could not see much detail because our project doesn't have many tasks and users planned. But a realistic burndown could look something like this.
They didn't complete all their tasks on time as you can see on the blue graph. With the Queries menu in the Boards section, you can create queries that list information from different work items. You can create your own queries or define them for the whole team. This is useful if you need to display a list with specific filters frequently. You can also use this function to export to Microsoft Excel, and make modifications to work items from within Microsoft Excel.
Within Azure Boards, you also have the possibility to create multiple teams within the same project. This can be useful if you want to set up different boards for the different teams, but want to group them within the same project. Teams can be created by using the Project settings button at the bottom of the page on the left, and then select Teams within the General section of the project settings.
After you created a Team, you can go into the Project configuration menu in the Boards section. This allows you to manage the different iterations. Iterations are defined on project level, not on the Team level. You can modify, add, or delete iterations in this window.
We previously mentioned that iterations are defined on project level, and not on team level, but they need to be linked on the team level. So, you define them on the project level, but link them on team level. Therefore, you need to select Team configuration, where you can select Iterations on top.
On this page, you can select the Select iteration(s) button to link iterations from the project configuration to the Team.
