AZ-400 Question 1
Select 2Your organization has recently adopted Azure DevOps for managing backlog items in Azure Boards and version control in Azure Repos. They want to ensure that every code commit is automatically associated with a relevant user story, so they can track the feature� progress from planning through to release. They also want to measure lead time and cycle time for each feature. Which two actions should you recommend to achieve end-to-end traceability between work items and code commits?
- A
Instruct developers to include the work item ID in commit messages using the 'AB#
' syntax to automatically link commits to user stories. - B
Enable branch policies to require a linked work item in each pull request before it can be merged.
- C
Use multiple Git repositories, one per user story, so each repository can be directly tied to a specific backlog item.
- D
Disable the Build Validation policy on pull requests to simplify linking between commits and user stories.
Show answer and explanation
Correct answers: A, B
Explanation
To design and implement end-to-end traceability in Azure DevOps, each code change should be tied to the corresponding backlog item. By instructing developers to reference work items in commit messages using 'AB#
- A. Correct.
Option 1 is correct. Including the work item ID in the commit message (e.g., 'AB#42') is the recommended approach to automatically link Azure Boards work items to commits in Azure Repos. This ensures you can trace changes from the user story to the actual code and gather metrics such as lead time and cycle time.
- B. Correct.
Option 2 is correct. Enabling branch policies for pull requests that require referencing a work item helps enforce best practices and ensures that no code changes are merged without associating them to a specific user story. This enforces traceability.
- C. Incorrect.
Option 3 is incorrect. Creating a separate Git repository for each user story would fragment the codebase and complicate overall flow. It does not inherently improve traceability or metrics gathering; instead, it introduces additional overhead in repository maintenance.
- D. Incorrect.
Option 4 is incorrect. Disabling Build Validation does nothing to enhance traceability. Build Validation policies help ensure code quality and can be configured to enforce further requirements, but disabling them removes an important check without improving work-item linking.