How to Set Up Azure DevOps for Agile Delivery: Work Items, Fields, Tags, Queries and Test Plans

Why this matters: every idea in these notes has to survive contact with the tool, and a tool configured badly quietly prevents good practice. This is the practical mapping, not a product manual. The thinking behind each piece is in the concept notes it links to.

A warning first: the tool does not create the discipline. A perfect Azure DevOps configuration with no Acceptance Criteria and no Definition of Done produces a beautifully organised record of the same delays. Configure it because it makes the right behaviour easy, not because you expect it to change behaviour by itself.

Pick the process template deliberately

When you create a project you choose a process, and it decides your work item types permanently enough that changing later is painful.

Process	Hierarchy	Use when
Basic	Epic → Issue → Task	Very small team, minimal ceremony
Agile	Epic → Feature → User Story → Task	The default I would pick. Matches Work Breakdown Hierarchy exactly.
Scrum	Epic → Feature → Product Backlog Item → Task	Same thing, PBI instead of User Story, and it has an explicit Impediment type
CMMI	Heavier, with formal change requests	Regulated or audit heavy environments

Agile is the one I would use, purely because its names match the language everyone already uses in these notes, and because its Bug handling is flexible.

One setting worth deciding early: whether Bugs appear on the backlog alongside Stories, or on the task board. Bugs as backlog items means they are prioritised and estimated against features, which is usually healthier because it makes the cost of quality visible. Bugs as tasks means they hide under Stories. Pick one and be consistent, otherwise half your defects disappear from planning.

The hierarchy, and how to keep it honest

flowchart TD
    A["Epic<br/>(business objective, spans quarters)"]
    B["Feature<br/>(capability, spans sprints)"]
    C["User Story<br/>(small testable outcome, one sprint)"]
    D["Task<br/>(implementation, a day or less)"]
    E["Test Case<br/>(linked, under Test Plans)"]

    A --> B
    B --> C
    C --> D
    C --> E

Parent your items properly. It takes ten seconds and it is what makes everything above the Story level meaningful. An unparented Story is invisible to anyone looking at progress on a Feature, and then leadership asks for status and somebody builds a spreadsheet, which is how parallel tracking systems are born.

Practical hygiene rules:

• Every Story has a parent Feature. Every Feature has a parent Epic.
• If you cannot name a sensible parent, you have probably written the item at the wrong level. Re read Work Breakdown Hierarchy.
• One Feature with exactly one Story is fake hierarchy. Collapse it.

Fields that actually matter

Most fields are noise. These are the ones I would insist on:

On a User Story

• Title. Written as an outcome, per Writing User Stories.
• Description. The As a / I want / So that, plus context and any links.
• Acceptance Criteria. There is a dedicated field. Use it. This is the single most important field in the entire system, per Acceptance Criteria.
• Story Points. Relative size only, per Estimation and Story Points.
• Area Path. Which product area, which is also how you slice reporting later.
• Iteration Path. Which sprint, or the backlog.
• Priority / Business Value. For ordering.
• Tags. Covered below.

On a Task

• Title, and Remaining Work in hours if you use capacity tracking. Original Estimate optional. Do not put Story Points on Tasks.

On a Bug

• Repro steps, severity, and a link to the Story or Feature it belongs to. The link is what later tells you which features generate the most defects, which is how you prioritise in Test Case Strategy.

Tags, because they carry the process

Tags are underrated and free. The set I would use:

• ready on Stories that pass Definition of Ready. This is your readiness gate made visible.
• needs-refinement on items that failed it, so they surface in the refinement session.
• added-mid-sprint on anything pulled in after planning started. This tag is how you measure scope growth, which is the number that matters most in Feedback and Scope Control.
• spike for timeboxed investigations.
• tech-debt so you can report how much of it you are actually paying down.
• blocked plus a comment saying by what and since when.

The added-mid-sprint tag costs one second per item and produces the single most useful retrospective statistic you will have.

Boards and columns

Map your board columns to your real workflow, and make sure the columns reflect your Definition of Done, not wishful thinking.

flowchart LR
    A["New"] --> B["Ready"]
    B --> C["Active"]
    C --> D["In Review"]
    D --> E["In Test"]
    E --> F["Done"]

Two things to configure:

Definition of Done per column. Azure DevOps lets you write exit criteria on each column. Write them. “In Review means: PR raised, criteria checked, tests written.”

Work in progress limits. Set a limit on Active and In Review. If the column is full, finish something before starting something. This is what stops a sprint where six Stories are each 80% complete and nothing ships.

Also: use the split columns (Doing / Done) on In Review and In Test, otherwise you cannot see whether something is waiting for a reviewer or being reviewed, and waiting is where time actually goes.

Sprints, capacity, burndown

Iteration paths are your sprints. Set the dates so the reports work.

Capacity is set per person per sprint, with days off. Then the sprint’s task Remaining Work can be compared against real availability, which is the arithmetic in Velocity and Capacity. If you are not going to fill in task hours, skip capacity entirely rather than half using it, because a half filled capacity view is worse than none.

Sprint burndown is where mid sprint scope increases become visible. That is its real value, more than the trend line. A burndown that goes up on day four is telling you something important.

Velocity chart and the forecast tool on the backlog will project how far down the backlog you can get at your historical rate. Useful for the “when will this be ready” conversation, as long as you treat the output as a range and remember the assumption that scope does not grow.

Test Plans, and the link that matters

This is the part most teams do not set up, and it is the part that fixes traceability.

Create a Test Plan per release or per sprint, with Test Suites grouped by Feature, and Test Cases linked to the User Story they verify. Requirement based suites do this linking automatically: point a suite at a Story and it collects the test cases linked to it.

What that gives you, and why it is worth the setup:

• From any Story you can see its test cases and whether they passed.
• From any Feature you can see coverage across all its Stories.
• You can finally answer “which features have no test cases at all”, which is the question from Test Case Strategy that nobody can currently answer.

Link automated tests to the same test cases so that manual and automated coverage appear in one place instead of two.

Queries worth saving

A handful of saved queries tells you more about your process than any status meeting:

1. Stories in the current sprint with an empty Acceptance Criteria field. Should be zero. If it is not, your Definition of Ready is decorative.
2. Items tagged added-mid-sprint in the current iteration. Your scope growth, per sprint.
3. Stories carried over, meaning items whose iteration changed. Your carry over rate.
4. Active Stories with no linked test case. Your future coverage gap, visible before it becomes permanent.
5. Bugs grouped by Area Path, last 90 days. Shows you where the risk actually lives, which is how you choose what to automate first.
6. Stories with points above 13. These should not exist in a sprint, per Estimation and Story Points.
7. Items untouched for 30 days. Your backlog rot. Close them or commit to them.

Put these on a dashboard. A dashboard of four honest numbers beats twelve charts nobody reads.

Where to write the definitions themselves

Put Definition of Ready and Definition of Done where the team sees them while working, not in a wiki page they visit once:

• In the board column exit criteria, which appear during drag and drop.
• In the work item templates, so a new Story is created with a pre filled acceptance criteria structure.
• Pinned on the team dashboard.

Work item templates in particular are worth ten minutes: create one for Story, Bug and Spike with the structures from Templates pre filled. It removes the blank page problem, which is the real reason acceptance criteria go unwritten.

Hygiene rules that keep it usable

• One board, one truth. The moment planning also lives in a spreadsheet, both become unreliable.
• Update items as work happens, not in a panic before the demo. A board updated once a week is a work of fiction.
• Close what is dead. A backlog with 400 open items is not a backlog, it is a landfill, and it makes prioritisation impossible. If it has been open a year and nobody has asked, close it. It is in the history if it ever matters.
• Do not create parallel tracking. If somebody needs a different view, build the query or the dashboard instead of a new document.
• Link the code. Mention the work item ID in commits and pull requests so the change and the requirement stay connected. In a year that link is how anyone reconstructs why a line of code exists, which is what Feature Inventory and Ownership depends on.