Understanding and Implementing Azure DevOps Work Items

Over the years, I’ve had the opportunity to use Azure DevOps extensively on multiple projects. I’ve explored its robust features, harnessed its capabilities, and witnessed its effectiveness in fostering team collaboration throughout the development lifecycle. I’ve also written about it a few times in different contexts, sharing insights and lessons learned. Now, as we welcome new members to our team, I feel it’s a great time to revisit, reorganize, and rewrite our understanding of Azure DevOps’ work tracking system to ensure a shared knowledge base.

Azure DevOps is a comprehensive suite of development tools that facilitates the collaboration of teams throughout the development lifecycle. Its work tracking system, a cornerstone of this suite, is designed to help teams plan, track, and discuss work across the entire process. The core of this system is “work items,” which are database records that track the various kinds of work involved in a project. In this write-up, we’ll talk about the most common work item types: Epics, Features, User Stories, Tasks, and Bugs.

Work Item Types

1. Epic

An Epic is a large body of work that can be broken down into several smaller tasks. It represents a significant deliverable or a set of related features. It’s typically used for planning and tracking at a higher level, often across multiple teams, and may span more than one project iteration or cycle.

2. Feature

A Feature is a service that fulfills a stakeholder need. Each feature is an aspect of the system, product, or project that delivers value. Features typically comprise multiple User Stories and are usually completed over multiple iterations.

3. User Story (or Stories)

User Stories are small, concise statements of functionality or quality, written from the perspective of a user. They’re the smallest units of work and represent a single increment of functionality. Each user story should be small enough to be coded, tested, and integrated within a single iteration.

4. Task

A Task is a unit of work that needs to be completed as part of a User Story, Feature, or Epic. It represents a single piece of work that a team member can accomplish in one day or less.

5. Bug

A Bug is a record of a software flaw that needs to be corrected. Bugs are linked to the work that needs to be accomplished to fix them, which often involves creating one or more Tasks.

When to Use Them

• Epic: When you have a large feature or project that will take a considerable amount of time and effort to complete and includes multiple smaller Features.
• Feature: When you have a high-level service or functionality that needs to be delivered and can be broken down into multiple User Stories.
• User Story: When there is a discrete piece of functionality or quality that you need to deliver from a user’s perspective.
• Task: When you need to break down a User Story or Bug into manageable chunks of work.
• Bug: When there’s a software issue that needs fixing.

Example 1

Let’s consider the process of creating a new e-commerce website as a practical example. Here’s how we might use each of these work items in that context:

Epic: Improve online sales — This is a large, overarching objective that will involve several smaller features to achieve. It provides the big picture of what we want to accomplish.

Feature: Implement online shopping cart — This is a more specific aspect of the “Improve online sales” epic. It’s a significant piece of functionality that will involve several user stories to complete.

User Story: As a customer, I want to add items to my shopping cart so that I can purchase multiple items at once. This is a discrete piece of functionality that contributes to the “Implement online shopping cart” feature. It’s written from the perspective of an end-user and provides context for the functionality being built.

Task:

• Design the ‘Add to Cart’ button on product pages.
• Implement the ‘Add to Cart’ button functionality.
• Write tests for the ‘Add to Cart’ functionality. These are individual pieces of work that can be done to complete the “Add items to shopping cart” user story. Each one is a small, manageable piece of work that contributes to the larger goal.

Bug: ‘Add to Cart’ button doesn’t update item count — This is an issue discovered during testing or reported by a user. It’s a problem that needs to be fixed, and might involve one or more tasks to resolve, such as: “Fix the item count update in the shopping cart module” and “Write additional tests for the shopping cart module.”

Example 2

Let’s walk through an example for developing a receipt reading OCR (Optical Character Recognition) service:

Epic: Develop a Receipt Reading OCR Service — This overarching objective provides the big picture goal of the project.

Feature: Implement OCR functionality to extract text from receipts — This is a key aspect of the “Receipt Reading OCR Service” epic. It involves several user stories and tasks to complete.

User Story: As a user, I want the OCR service to accurately identify the total amount on a receipt, so that I can automate my expense tracking. This is a discrete piece of functionality that contributes to the “Implement OCR functionality” feature. It’s written from the user’s perspective, defining what the user wants to achieve.

Task:

• Research suitable OCR libraries or APIs.
• Integrate the selected OCR service into the system.
• Train the OCR service to recognize the total amount on a variety of receipt formats.
• Write tests for the OCR functionality. These tasks represent individual pieces of work that need to be completed to accomplish the user story. Each one is a small, manageable piece of work that contributes to the larger goal.

Bug: OCR service fails to accurately recognize total amounts on faded receipts — This bug might be discovered during testing or reported by a user. It’s a problem that needs to be fixed and could involve tasks like “Improve image preprocessing to enhance text clarity on faded receipts” and “Extend OCR training data with examples of faded receipts”.

This way, the entire project gets broken down into progressively smaller and more manageable pieces, all of which align with the overall goal of developing a receipt reading OCR service. As always, these are just examples, and the actual work items in your project will depend on its specific needs and goals.

Best Practices

1. Work items should flow from top to bottom: Epics break down into Features, Features into User Stories, and User Stories into Tasks. Keep your organization and work tracking clean by maintaining this hierarchy.
2. Work items should be sized to fit your iterations: Epics and Features will span multiple iterations. User Stories should be sized to fit within a single iteration. Tasks should be small enough to be completed within a day.
3. User Stories should be user-focused: When writing User Stories, remember to focus on user value, not technical details. Write them in a way that focuses on what the user wants to achieve.
4. Bugs should be linked to Tasks: When a Bug is discovered, it should be linked to the Tasks required to fix it.
5. Use work item status to track progress: Updating the status of work items as they move through their lifecycle (from new, to active, to resolved, to closed) provides a clear indication of project progress.
6. Use the discussion section to keep a history of conversations: Each work item has a discussion section. This is a good place to keep a record of decisions, alternative solutions considered, and any other notes relevant to the work item.

Understanding and properly using Azure DevOps work items is key to effective team collaboration and project tracking. By using Epics, Features, User Stories, Tasks, and Bugs appropriately, your team can ensure clear communication, efficient work management, and successful delivery of value to your users.