Azure DevOps: Setting up Sprints with Boards

Organize, Execute and Review all your User Story and Task Requirements

Introduction

A workflow is the starting point for managing activities in software projects. Workflow boards make it possible for the team to keep track of assignments to understand how goals and tasks are going.

In this tutorial, I will explain how to set up an Azure DevOps Board with sprints, user stories, and tasks.

Getting Started

Visit https://dev.azure.com to register for a free Azure DevOps account, then add a new project called Floral Force.

Once our project is created, we’re redirected to the Overview section, which gives us a high-level view of the whole project.

We’ll see options on the left-hand side:

• Boards
• Repos
• Pipelines
• Test Plans
• Artifacts

For this tutorial, we’ll focus on Boards only.

Add Users

In Project Settings → Teams, add users to the team, which allows us to assign users to tasks that we’ll create later.

Click the team Floral Force and click the Add button to add users by email address:

Currently, I’m an Admin user with two regular team users:

It’s wise for a team to have more than one user with Admin privileges in your projects. Team managers can organize staff, customize team resources, and manage initiatives.

In Teams → Administrators, add administrators from our current list of users:

Create Sprints

After configuring the Floral Force project, we can start planning our sprints. Azure DevOps Boards helps you delegate assignments and keep track of due dates and statuses between you and your staff.

Under Boards → Project settings, you’ll see three iterations listed under the Floral Force project. An Iteration a timeboxed, incremental development step, usually lasting between one and four weeks.

A Sprint is a short, time-boxed cycle in which an Agile Team works to deliver applications more quickly and consistently. All sprints are iterations, but not all iterations are sprints. To keep things simple in this tutorial, let’s stick to sprints, renaming Iteration 1 to Sprint 1, as shown below. Also, delete the remaining iterations.

We’ll assume that each sprint lasts two weeks, beginning on Monday and finishing the following Friday.

Agreeing and sticking to the set length of iterations provides teams with a straightforward way to achieve a rough estimate of the project’s remaining time. This is calculated using Velocity — the amount of work completed by your staff in a given amount of time — and the amount of work remaining.

Backlogs

A backlog is a list of activities that must be completed to sustain a broader action strategy. It lists tasks that the team chooses to focus on next by a Priority number.

Activities include:

• User Stories: customer requirements for a software feature. These document a description, conversations, and tests to decide when a need is delivered.
• Features: functionality that brings value to users.
• Bugs: defects that need to be fixed.

Start building a product backlog by clicking the +New Work Item button on the Backlog screen:

Click the …Edit link in the dropdown menu beside each user story to start adding some details:

Inside each user story, please write a Description, which describes the user story mission, what our customers want, and what will help the company grow.

Write Acceptance Criteria, which are requirements we must fulfill for the Product Owner/Stakeholders to approve it.

Also, choose Story Points for this user story, which are used to compare the size and complexity of each story in relative points rather than absolute time. The simplest way to think about this is that a story with 4 points will take roughly twice as long as a story with 2 points.

Finally, assign a Priority, which allows us to sort which activity should be tackled next from the backlog.

Our backlog now has three user stories, all assigned to Sprint 1:

Taskboard

Click Taskboard in the menu bar to see the three stories for Sprint 1.

I’ve also highlighted the Sprint menu, which is helpful for switching to previous and future sprints:

In Column Options, change the column names to your requirements.

Also, drag and drop the field where you like it within the range of chosen fields to adjust the order of the fields:

Click Save, which refreshes the board and updates the column names:

Add Tasks

Our first sprint is correctly set up with the three user stories; it’s time to add tasks.

Inside the Express Order Entry story, click the green + button and click Task:

Add three tasks, as follows:

We can select an Activity category for each task from the following options:

• Deployment
• Design
• Development
• Documentation
• Requirements
• Testing

Our first three tasks require coding work. So, for each Task, change the Activity to Development:

Add a Description using Gherkin Syntax:

Styling Cards

Add two more tasks and set the Activity dropdown as follows:

• Manual Test (Testing)
• Test Cases (Requirements)

A QA analyst will create test cases, which are used by a developer to check his/her work is correct from a business perspective after coding is complete. Later, these same test cases will be followed by a tester during manual testing.

Right now, the sprint board looks bland, and it’s not immediately obvious which tasks are requirements gathering, which are development tasks, and which are testing tasks.

To solve this, change Style settings in Azure DevOps Boards by going to Settings → Styles:

Let’s apply a style to development tasks.

Create a new Style Rule, choosing a green card color—select Activity for Field and Development from the options for Value. Repeat the same process for Test Cases and Manual Testing, choosing blue and orange colors, respectively.

Add Effort

Add time/story point estimations to the tasks by clicking the middle right-hand side of each card. You can read more on Sprint Estimation here.

Bonus: Custom Styling for Bugs

If problems are found during the sprint, raise bugs by clicking the + icon and select Bug.

For example, a QA analyst finds something wrong with the style of the button:

However, we might decide that a red background is better for highlighting bugs. Since Bug is not an Activity task, we need to find another way to change the style of tasks that are considered bugs.

To do this, we could adopt a rule that if the Title contains the text ‘Bug:,’ use a red background, as follows:

Now rename the Title of the button styling bug, starting with ‘Bug:’ and click Save.

The board picks up the title change, matches it with a style rule, and refreshes, showing bugs with the desired color.

See more on style customization here.

Thanks for reading! Let me know what you think in the comments section below, and don’t forget to subscribe. 👍