Boards & Work Items

The board in Azure Boards is the source of truth for what is being worked on and where it stands. This page explains the intent and conventions; the columns, WIP limits, and rules live in Azure DevOps and are what you actually follow.

Work-item hierarchy

flowchart TD
  E["Epic<br/>client outcome / big bet"] --> F["Feature<br/>shippable capability"]
  F --> S["Story<br/>one user need, fits a cadence"]
  S --> T["Task<br/>a unit of dev work"]
  S --> B["Bug<br/>defect against a story"]

• Epic — a large client outcome, spans many cadences.
• Feature — a shippable slice of an Epic, demoed to the client.
• Story — one testable user need, small enough to finish inside one 2-week cadence (see Delivery Lifecycle).
• Task / Bug — the actual work under a Story. Bugs found in flow attach to their Story; production bugs enter the expedite lane.

The board and its gates

stateDiagram-v2
  [*] --> Ready: DoR met
  Ready --> InDev: pulled within WIP
  InDev --> CodeReview: PR opened
  CodeReview --> QA: approved + merged
  QA --> UAT: passed
  UAT --> Done: sign-off, DoD met
  QA --> InDev: failed
  UAT --> InDev: change requested
  Done --> [*]

Definition of Ready gates entry to the board; Definition of Done gates the move to Done. Both are defined in Delivery Lifecycle and enforced as Azure Boards column rules.

WIP limits per column

Column	WIP limit (intent)	Why
In Dev	≤ 1–2 per developer	Finish before you start the next thing.
Code Review	≤ 1 per reviewer	A stuck PR stalls the whole board.
QA	Team-sized, small	Prevents a QA pile-up hiding done work.
UAT	Small	Surfaces client-side delay early.

Note

WIP limits are set and enforced in Azure Boards, not here. If you change a limit, update this table in the same change.

Expedite lane

Bugs and support tickets flow through a dedicated expedite lane that bypasses the cadence boundary — they are pulled continuously, not batched into planning. The lane has its own tight WIP limit so firefighting can’t quietly consume the whole team. Escalation path: L1 Technical Support (Nidal Mohammad) → L2 team lead → original developer.

Branch & commit naming tie to the work item

Every branch and commit links back to a work-item id so main is traceable to the board:

• Branch: feature/<id>-short-desc, bugfix/<id>-short-desc, hotfix/<id>-short-desc
• Commit / PR: reference #<id> so Azure DevOps links the commit and PR to the work item.
• PR requires a linked work item — enforced by branch policy.
• The work-item type is validated on the PR. A feature/* PR links a Story or Bug; a hotfix/* PR links a Bug. The wrong type fails the build, not the reviewer’s patience.
• The pipeline moves the card. Merging to main transitions linked work items automatically — don’t drag them by hand, and don’t fight it.

See Branching & Pull Requests for the full Git flow.