A Comprehensive Guide to Azure DevOps User Stories

User stories in Azure DevOps are a way to capture the requirements of a product or feature in a concise and easy-to-understand format.

A user story typically follows a simple template: "As a [type of user], I want to [perform some task] so that [I can achieve some goal]". This template helps to clearly define the user's needs and expectations.

In Azure DevOps, user stories are often used to plan and prioritize work items, such as tasks and features, in a sprint or iteration. By breaking down complex requirements into smaller, manageable chunks, teams can make steady progress and deliver working software.

User stories can be written by anyone on the team, not just developers, which helps to ensure that the requirements are accurate and meet the needs of all stakeholders.

Creating a New User Story is a straightforward process in Azure DevOps. To get started, click the “+ New Work Item” button at the top and select “User Story” from the dropdown menu.

This will open a user story template where you can enter all the key details. You can also create user stories from the quick add panel on the product backlog page.

To define your user story, focus on who the feature is for, what users want to accomplish, and why. Don't describe how the feature should be developed, but provide enough detail for estimating how much work is required to implement the story.

The title of your user story should be a short name that summarizes what the story is all about. For example, “As a user, I can reset my password.” The description field should expand on the title, providing more context on what needs to be built.

Here are the common fields used across work item types to help you complete the form:

Remember to define your acceptance criteria clearly, listing out validation steps to confirm the criteria as well. This will help prevent scope creep down the line.

To create a new user story, start by opening your backlog and clicking the "+ New Work Item" button at the top. From the dropdown menu, select "User Story" to begin the process.

You can create a new user story from the quick add panel on the product backlog page. This is a convenient way to add new items to your backlog without having to navigate through multiple screens.

To define your user story, use the template provided and enter all the key details. Focus on who the feature is for, what users want to accomplish, and why. Don't describe how the feature should be developed, but provide enough detail for estimating how much work is required to implement the story.

Use the common fields used across work item types when completing the form. For user stories, provide enough detail for estimating how much work is required to implement the story. You can use the guidance in the table to help you fill out the form.

To estimate the amount of work required to complete a user story, use any numeric unit of measurement your team prefers. This value will be referenced by agile velocity charts and forecast tools.

Here are the key fields to consider when creating a new user story:

By following these steps and considering the key fields, you'll be well on your way to creating effective user stories that meet the needs of your team and stakeholders.

To get started with creating a new User Story, you'll first need to set up the Azure DevOps Client for Node.js. You can do this by getting the WorkItemTrackingApi, which is the API you'll use to set the column of a User Story.

You'll need to replace the placeholders pat and sat with your Personal Access Token and System Access Token, respectively. The organisation you use will likely be different from the example in the code.

Now that you have the WorkItemTrackingApi, you can load your User Story using its ID. This can be done using the WorkItemExpand.All option to ensure you get all the fields of the User Story.

The System.BoardColumn field is read-only, but you can set the WEF_1D7E8E9B92454212B8A5E6DFBCED0D17_Kanban.Column field instead, which will in turn set the System.BoardColumn field.

Tracking progress is a crucial part of using Azure DevOps user stories. You update the State field to reflect the current status, and optionally, you can specify a reason. The state and reason fields appear on the work item form in the header area.

Each state is associated with a default reason, so it's best to use the default first and update it when you change the state. A typical workflow progression for a user story follows a specific order: New, Active, Resolved, and Closed.

You can update the status with the board or Taskboard by dragging items to a new state column, which updates both the State and Reason fields. This makes it easy to track progress at a glance.

Here's a summary of the common agile status values:

Updating the status field communicates progress and helps teams stay on track. By tracking progress regularly, you can ensure that your user stories are completed on time and meet the required quality standards.

Agile workflow states are essential for tracking user story progress in Azure DevOps. Most Work Item Types (WITs) support transition both forward and backward from each workflow state.

A typical workflow progression for a user story follows these steps:

Common agile status values include Active, Resolved, and Completed, which communicate progress at a glance.

Agile workflow states are a crucial part of tracking progress in Agile projects. They help teams understand which items are new, in progress, or completed.

A typical workflow progression for a user story follows a specific order. The product owner creates a user story in the New state with the default reason, New user story. This is the starting point for the workflow.

The team updates the status to Active when they decide to complete the work during the sprint. This indicates that work has begun on the user story.

A user story gets moved to Resolved when the team has completed all its associated tasks and unit tests for the story pass. This is a significant milestone in the workflow.

A user story gets moved to the Closed state when the product owner agrees that the story has been implemented according to the Acceptance Criteria and acceptance tests pass. This is the final step in the workflow.

Here's a summary of the typical workflow progression for a user story:

In order to bring consistency to user story estimation, teams must take a different approach. This involves disregarding hours and estimating tasks based on fractional days of effort.

This approach enables user story level of effort to be validated against task estimates which correlate to sprint length and team capacity. It adds just the right amount of abstraction to empower teams to more accurately estimate and plan work.

To begin, teams must agree on the sprint length, which can be two weeks like my teams. They must also agree on the basis for story points, such as the Fibonacci sequence.

Agreeing on the maximum story point velocity that a single developer can deliver per sprint is also crucial. For example, my teams have a maximum story point velocity of 10 story points per developer.

Another key point to consider is the maximum size of a single story. If a story is too large, it's likely to need to be broken down into smaller units. My teams agree that any story larger than 8 story points likely needs to be broken down.

Here are some key points to consider when adopting this approach: