Azure Boards – Assigning, Linking Work Items and Associating with Commits & Pull Requests

1. What does assigning and linking Work Items mean?

In Azure Boards, Work Items represent requirements, User Stories, Tasks, Bugs, and other development activities.

Azure Boards allows developers and project managers to:

1. Assign Work Items to specific developers or testers.

2. Link Work Items to establish relationships between requirements, tasks, and bugs.

3. Associate Commits with Work Items to track code changes.

4. Associate Pull Requests (PRs) with Work Items to track code reviews and merges.

The main purpose is to provide end-to-end traceability between business requirements and source code changes.

Real-world example

Suppose a developer is assigned the following task:

Work Item ID : 105
Type         : Task
Title        : Develop Customer Login API
Assigned To  : Developer A
State        : Active

The developer implements the API, commits the code, and creates a Pull Request.

Azure Boards can link all these activities to Work Item 105.

2. How do you assign a Work Item?

Assigning a Work Item means selecting the team member responsible for completing it.

Steps in Azure DevOps

1. Open your Azure DevOps Organization and Project.

2. Navigate to Boards → Work Items.

3. Open an existing Work Item or create a new one.

4. Enter the required information:

   • Title

   • Description

   • Assigned To

   • State

   • Area Path

   • Iteration Path

5. Select the developer in the Assigned To field.

6. Click Save & Close.

Example

Key Point: The Assigned To field identifies the person responsible for the Work Item. It does not automatically grant repository access or assign a Git branch.

3. How do you link Work Items?

Azure Boards allows you to establish relationships between Work Items.

For example, a User Story may contain multiple Tasks, and a Bug may be related to that User Story.

Common Work Item Link Types

Example hierarchy

Epic: Banking Application
   │
   └── Feature: Customer Management
          │
          └── User Story #100: Customer Login
                 │
                 ├── Task #105: Develop Login API
                 ├── Task #106: Create Angular UI
                 └── Task #107: Write Unit Tests

Related Bug #205: Login fails for valid users

Steps to link Work Items

1. Open Boards → Work Items.

2. Select Work Item #100.

3. Open the Links section or Related Work section, depending on the interface.

4. Select Add link → Existing item.

5. Choose the link type, such as Child.

6. Enter Work Item ID 105.

7. Save the changes.

Now Work Item 105 is linked as a child of User Story 100.

Important: Parent/Child links represent hierarchy, while Related links represent an association without hierarchy.

4. How do you associate Git Commits with Work Items?

Azure DevOps supports linking Git commits to Azure Boards Work Items.

This helps identify which code changes were made to complete a particular requirement or fix a bug.

Method 1: Using the AB# syntax

Suppose you are implementing Work Item 105.

After completing the code:

git add .
git commit -m "Implemented Customer Login API AB#105"
git push origin feature/customer-login

Here:

• Implemented Customer Login API is the commit message.

• AB#105 references Azure Boards Work Item ID 105.

• git push uploads the commit to the remote repository.

When the repository integration supports Azure Boards linking, Azure DevOps recognizes the AB#105 reference and associates the commit with the Work Item.

Example

Work Item #105
      │
      └── Git Commit
           │
           ├── Commit ID: a1b2c3d
           ├── Message: Implemented Customer Login API
           └── Branch: feature/customer-login

Method 2: Link a commit through Azure DevOps

For an existing commit:

1. Open Boards → Work Items.

2. Open Work Item 105.

3. Go to Links or Development.

4. Choose the option to add an existing link.

5. Select the supported Git commit link type.

6. Find the commit and save.

The available options depend on the repository type and integration.

Key Point: AB#105 is an Azure Boards work item reference, not a Git command. It works through supported Azure DevOps integrations, not through Git alone.

5. How do you associate Pull Requests with Work Items?

A Pull Request (PR) is used to review and merge code changes from one branch into another.

Linking a PR to a Work Item helps reviewers understand the requirement behind the code change.

Example

Suppose Developer A completes the Customer Login API in:

feature/customer-login

The developer wants to merge the changes into:

develop

Steps

Step 1 – Push the feature branch

git push origin feature/customer-login

Step 2 – Create a Pull Request

1. Open Azure Repos → Pull Requests.

2. Click New Pull Request.

3. Select the source branch: feature/customer-login.

4. Select the target branch: develop.

5. Enter the PR title and description.

Step 3 – Link the Work Item

In the Pull Request interface:

1. Find the Work Items section.

2. Select Add or the relevant linking option.

3. Search for Work Item 105.

4. Associate the Work Item with the PR.

5. Create or save the Pull Request.

Example PR

Pull Request #25

Title         : Implement Customer Login API
Source Branch : feature/customer-login
Target Branch : develop
Work Item     : #105
Reviewer      : Tech Lead
Status        : Active

The Tech Lead reviews the code and approves the Pull Request.

Once the configured branch policies are satisfied, the PR can be completed and merged.

Alternative: Reference a Work Item in the PR description

You can include:

Implemented Customer Login API.

Related Work Item: AB#105

Supported Azure Boards integrations can recognize the reference and link the PR to the Work Item.

Important: Linking a Work Item does not automatically approve or merge the PR. Code review and branch policies remain separate.

6. Complete Workflow – Work Item to Pull Request

The Work Item's Development section can display associated commits, branches, and Pull Requests, depending on the repository integration.

7. Can Azure DevOps Automatically Update Work Item Status?

Yes. Azure DevOps supports certain automated Work Item updates.

For example, a supported commit or PR reference can include a state transition command:

git commit -m "Fixed Login API bug Fixes AB#205"

With supported Azure Boards repository integration and processing, Fixes AB#205 can transition the referenced Work Item to its completed state.

The exact result depends on the configured process, repository integration, and supported transition behavior.

For Azure Repos PRs, you can also use the Complete linked work items after merging option, when available.

Important: Linking a commit or PR with AB#105 alone does not necessarily change the Work Item status.

8. Important Interview Questions and Answers

Q1. How do you assign a Work Item in Azure Boards?

Open the Work Item, select a developer in the Assigned To field, configure the required fields, and save it.

Q2. What is the difference between assigning and linking Work Items?

Assigning identifies the person responsible for the work. Linking establishes relationships between Work Items or development artifacts.

Q3. How do you link a Git commit to a Work Item?

Include the Work Item ID using AB# syntax in the commit message.

git commit -m "Implemented Login API AB#105"

Q4. How do you link a Pull Request to a Work Item?

Open the Pull Request, locate the Work Items section, and add the relevant Work Item ID. Supported integrations also recognize AB#105 references.

Q5. Can multiple commits be linked to one Work Item?

Yes. Multiple commits can be associated with the same Work Item.

Q6. Can one Pull Request be linked to multiple Work Items?

Yes. A Pull Request can be associated with multiple Work Items when it addresses several requirements or defects.

Q7. What is the benefit of linking Work Items to commits and PRs?

It provides traceability between requirements, code changes, reviews, and delivery activities.

Q8. Does merging a Pull Request automatically close its linked Work Items?

Not always. It depends on the repository integration and whether the relevant completion or state-transition options are enabled.

9. Key Points for Interview

• Assigned To: Identifies the responsible developer or tester.

• Parent/Child: Establishes hierarchy between Work Items.

• Related: Connects associated Work Items.

• AB#105: References Azure Boards Work Item 105.

• Commit Linking: Connects code changes to requirements.

• PR Linking: Connects code reviews and merges to requirements.

• Traceability: Helps identify which code changes implement a requirement or fix a bug.

• Automatic Status Updates: Possible through supported commands and PR completion settings.

Interview-ready answer

In Azure Boards, Work Items are assigned to developers using the Assigned To field. Work Items can be linked using relationships such as Parent/Child, Related, and Predecessor/Successor.

To associate Git commits with Work Items, developers include the Work Item ID in the commit message using syntax such as AB#105. Pull Requests can also be linked to Work Items through the PR's Work Items section or supported reference syntax.

For example, when implementing a Customer Login API, I assign Work Item 105 to a developer, link the developer's commits and Pull Request to that Work Item, and track its progress until completion.

This provides end-to-end traceability between requirements, development activities, code reviews, and delivered changes.