In this part, we will explore one of the core features of Azure DevOps, Azure Boards, and its application in agile planning and tracking. Azure Boards provides a robust set of tools to support agile methodologies such as Scrum and Agile practices. In this blog post, we will delve into the concepts, features, and scenario usages of Azure Boards in the context of agile development. By the end of this article, you will have a solid understanding of how to effectively plan, track, and deliver your projects using Azure Boards.

Features of Azure Boards:

Azure Boards is a powerful work tracking system that allows teams to plan, track, and discuss work across the entire development process. Let’s dive into the key concepts and components of Azure Boards:

1. Work Items:

Work items are the building blocks of Azure Boards. They represent tasks, features, or issues that need to be addressed. Azure Boards provides different types of work items, including Epics, User Stories, Tasks, and Bugs. Each work item has attributes such as title, description, priority, and assigned team member. In Azure Boards, work items are organized in a hierarchy to represent different levels of granularity in the agile development process. The hierarchy typically includes the following levels:

1.1 Epics

Epics represent large bodies of work that span across multiple iterations or sprints. They are high-level features or initiatives that are too big to be completed within a single iteration. Epics provide a way to capture and track long-term goals and can be broken down into smaller, more manageable work items. In the Tailwind Traders sample project, I will add an epic with the below steps. The Epic “Shopping Experience” would involve multiple features and each feature would have multiple user stories and should be on top of the work items hierarchy.

1.2 Features

Features are intermediate-level work items that sit below epics in the hierarchy. They represent significant functionality or user requirements that contribute to the completion of an epic. Features are usually scoped to be completed within a single iteration or sprint and can be further broken down into user stories.

I have added a feature “Product reviews” which would be further defined by multiple user stories.

1.3 User Stories

User stories are the smallest, most granular work items in the hierarchy. They represent specific units of work that deliver business value. User stories are typically written from a user’s perspective and describe what a user needs to achieve with a particular feature or functionality. They capture the “who,” “what,” and “why” of a requirement. In the Product Reviews feature a user story “Product review- Verified Purchase” is added which describes “who,” “what,” and “why” of the Product reviews feature.

Please note the hierarchy of the Epic, Features and User Stories created. I have created another feature “Refund Items” and “Refund payments” user stories related to the Epic.

1.4 Tasks:

Tasks represent the smallest units of work within a user story. They break down user stories into actionable items that team members can work on. Tasks often include specific actions, steps, or sub-tasks required to complete a user story.

1.5 Bugs:

Bugs are work items that represent defects or issues found during development or testing. They capture information about the problem, its impact, and steps to reproduce it. Bugs are typically prioritized and addressed alongside user stories to ensure high-quality software delivery.

1.6 Issues:

Issues are similar to bugs and represent problems or challenges that are not necessarily related to defects. They can include technical debt, design issues, or other concerns that need to be resolved. Issues help track and address non-defect-related work items within the development process.

1.7 Test Cases:

Test cases represent the specific scenarios or conditions that need to be tested to ensure the quality of the software. They outline the steps, expected results, and any additional test data required to validate the functionality. Test cases are associated with user stories and can be executed and tracked to verify that the implemented features meet the specified requirements.

2. Backlogs:

The backlog is a prioritized list of work items that need to be completed. It provides a centralized view of all the work to be done. Teams can manage their backlogs and prioritize work items based on business value and urgency. Backlogs in Azure Boards provide a central repository for managing work items. There are two types of backlogs: the product backlog and the sprint backlog.

Product Backlog: The product backlog contains all the work items that represent the requirements and features to be implemented in the product. Epics, features, and user stories are organized and prioritized in the product backlog based on their business value and priority. You can see in the below example the order of the user stories is defined according to their priority and business value. The view can be changed and the order of the Epics, features, user stories can be viewed and changed to manage the product backlog.

The work items can be dragged and dropped to their respective hierarchy and the order, assignment and other values can also be changed.

Sprint Backlog: The sprint backlog is a subset of the product backlog. It contains the work items selected for a specific sprint or iteration. During sprint planning, the team selects user stories and breaks them down into tasks for the upcoming sprint. The sprint backlog represents the committed work for that sprint. In the Sprints -> Backlog view you can see all the work items related to the current iteration.

3. Boards:

Boards in Azure Boards provide visual representations of work items and their progress. There are two main types of boards: Kanban boards and task boards. Kanban boards provide a visual workflow where work items move across different stages (e.g., To Do, In Progress, Done). Task boards are used for tracking individual tasks within a work item. Depending on the process selected on the project the Task board will show the process states. In our case for Agile, tasks would be in one of the states i.e., “New, Active, Resolved, Closed”.

On the boards view, work items are displayed as cards, with each card representing a specific work item. The cards typically include information such as the work item title, assigned team member, and status. Team members can interact with the cards by updating the status, adding comments, or attaching relevant files.

The tasks and sprint would be managed from the Task Boards on a daily basis and the tasks can be moved to closed when the “definition of done” is reached. Please note that issues and bugs can be moved to resolved. Issues/Bugs can be opened in an iteration, and they are not mandatory part of an epic, feature or user story.

By utilizing the hierarchy of work items and leveraging the backlogs and boards view in Azure Boards, teams can effectively plan, prioritize, and track their agile development work.

4. Queries

Queries provide a flexible and powerful way to filter, sort, and analyze work items in Azure Boards. With queries, you can define criteria to retrieve work items based on various fields, such as work item type, state, assigned user, tags, and more. Queries can be saved, shared, and used to create charts, track progress, and generate reports.

Creating and Running a Query

To create and run a query in Azure Boards, follow these steps:

Access the Queries Hub: From the Azure DevOps portal, navigate to the “Boards” tab, and select the “Queries” option from the left-hand navigation pane. This will take you to the Queries Hub.

Create a New Query: Click on the “New Query” button to create a new query. Provide a name and optionally add a description to define the purpose of the query.

Define Query Criteria: In the query editor, define the criteria for your query by selecting fields, operators, and values. For example, you can filter work items based on their state, assigned user, or specific tags.

Refine Query: Use logical operators such as AND, OR, and parentheses to refine your query and create more complex filtering conditions.

Save and Run Query: Once you have defined your query criteria, save the query. You can then run the query to retrieve the matching work items.

By running this query, you will retrieve ANY work item assigned to the specified team member.

Once a query is executed, the results will be displayed in the query results view. From here, you can take various actions on the retrieved work items, such as updating their states, assigning them to different team members, adding comments, or linking them to other work items.

Queries can be saved and shared with other team members, providing a consistent way to retrieve specific sets of work items and track progress across the team.

By utilizing queries in Azure Boards, you can gain insights, track specific subsets of work items, and create custom reports to support your agile planning and tracking processes.

Conclusion

In this blog post, we explored the concepts, features, and scenario usages of Azure Boards in the context of agile planning and tracking. By harnessing the power of Azure Boards, you can streamline your agile development processes, enhance team collaboration, and deliver high-quality software. In the next part of this blog series, we will dive into Azure Repos, a robust version control system provided by Azure DevOps. Stay tuned for valuable insights and practical tips to maximize your productivity with Azure DevOps!