Task 1.1: Design and implement traceability and flow of work

• AA develop branch that collects features, merged into main through release branches at the end of each sprint

  Incorrect

  Long-lived develop and release branches are the overhead the team wants to avoid.

• BDirect commits to main by every developer, with a nightly build that reports failures

  Incorrect

  Direct commits skip review and find failures only after they reach main.

• CGitHub Flow, with a short-lived branch from main and a reviewed, checked pull request for each change

  Correct

  Every change starts from the default branch and returns to it through a reviewed pull request, keeping main deployable.

• DA fork per developer, with changes collected in each fork for a quarterly merge

  Incorrect

  Quarterly merges create large, risky integrations instead of small reviewed changes.

In GitHub Flow, each feature, fix or experiment starts in a branch from the default branch, changes are discussed and checked in a pull request, and the branch is merged back, so the default branch stays ready to deploy.

• AKeep the reference in the pull request title, and add the work item ID to the branch name as well

  Incorrect

  AB# in a title doesn't create a link, and branch names don't transition work items.

• BPut "Fixes AB#412" in the pull request description and merge the pull request into main

  Correct

  AB# links from a description, and fix keywords transition the item only when the pull request merges into the default branch.

• CWrite "#412" in a pull request comment so that GitHub links the item

  Incorrect

  #412 refers to a GitHub issue, and comments don't create AB# links.

• DUse "Closed AB#412" in the pull request title targeting the release branch

  Incorrect

  Titles don't link, and transitions don't apply to pull requests merged outside the default branch.

Add AB#{ID} to a commit message, pull request description or issue description to link a GitHub item to an Azure Boards work item; AB# in a comment or a pull request title doesn't create a link. Keywords such as fix, fixes and fixed transition the item, but only for pull requests merged into the default branch.

• AA Check for linked work items policy set to Required on main

  Correct

  Set to Required, the policy blocks pull requests that have no linked work items.

• BA Check for comment resolution policy on main

  Incorrect

  Comment resolution checks that review comments are resolved, not that work items are linked.

• CA pull request template that asks authors to mention a work item in the description

  Incorrect

  A template only suggests content; it doesn't stop completion.

• DA minimum number of reviewers policy with two required reviewers

  Incorrect

  Reviewers approve code; they don't make a work item link mandatory.

The Check for linked work items branch policy requires work items to be linked to a pull request before it can merge. Linked work items give traceability from code to requirements and bugs.

• AScrum

  Correct

  Scrum tracks Product Backlog Items and Bugs.

• BBasic

  Incorrect

  Basic tracks Epics, Issues and Tasks.

• CAgile

  Incorrect

  Agile tracks User Stories.

• DCMMI (Capability Maturity Model Integration)

  Incorrect

  CMMI tracks Requirements, Change Requests, Risks and Reviews.

The default processes are Basic (Epic, Issue, Task), Agile (User Stories), Scrum (Product Backlog Items and Bugs) and CMMI (Requirements, Change Requests, Risks and Reviews).

• AA WIP limit on the Development column

  Incorrect

  A WIP limit caps how many items are in a column, not what done means.

• BA new swimlane at the top of the board for items without tests

  Incorrect

  Swimlanes group cards; they don't state exit criteria.

• CA Definition of Done for the Development column

  Correct

  A Definition of Done states the criteria for completing that stage and is shown on the column.

• DA tag on every item that has tests

  Incorrect

  Tags label items after the fact; they don't define the standard.

A Definition of Done on a board column lists the criteria the team agrees must be met before work leaves that stage, so everyone shares the same standard.

• AAdd a webhook from GitHub to Azure Boards

  Incorrect

  A webhook doesn't post status checks from Boards.

• BCreate a new PAT with more scopes

  Incorrect

  The status check needs a GitHub App connection, not a broader token.

• CAdd a GitHub Actions workflow that comments on every pull request

  Incorrect

  A comment isn't the Boards status check.

• DConnect through the Azure Boards app for GitHub

  Correct

  Pull request status checks require a GitHub App connection.

The Azure Boards app for GitHub authenticates as the app rather than a person. Features such as pull request status checks require a GitHub App connection.

• ACreate two projects with copies of the issues

  Incorrect

  Copies drift apart; one project can show several views.

• BMove the issues to Azure Boards

  Incorrect

  Moving tools isn't needed for two layouts.

• CAdd a board view and a roadmap view to the same project

  Correct

  Project views show the same items in different layouts, such as a board or a roadmap.

• DUse labels named board and timeline

  Incorrect

  Labels categorize issues; they don't change the layout.

GitHub Projects can hold several views of the same items, with layouts such as table, board and roadmap, each with its own grouping, sorting and filtering.