Work Item Process

The project runs a single Azure DevOps project on an inherited Agile process: Microsoft’s Agile template with the project’s own changes layered on top. Inheritance is what lets the project add fields and adjust types without leaving the standard behind; the standard is what lets anyone who knows Agile read the board.

1. Work item types

Six types are in use, five from the template and one added, Goal. The test-management types the template ships (Test Case, Test Plan, Test Suite) and the Issue type are not used; test work is a Task with Activity = Testing, as The Activity field explains.

Type What it is here Parent

Epic

A delivery stream — a long-lived area of the portfolio such as event registration, membership, platform and operations, or cross-cutting work. Epics are few, rarely closed, and are the top of every tree.

None

Feature

A deliverable goal that several stories serve and that completes: a screen, a capability, a migration, a pilot. A Feature belongs to one component’s Area Path.

Epic

User Story

One behaviour change a user or operator can see or a system can be tested for, with acceptance criteria that say when it is done. The unit of planning and of release notes.

Feature

Bug

A defect: behaviour that differs from what is documented or intended. Carries where it was found and how to reproduce it. A Bug may parent directly to a Feature or an Epic.

Feature or Epic

Task

A unit of work under a Story or Bug, or a classified task that automation creates: a test to run once the change is on an environment, a documentation change, a release-time action. The Activity field says which.

User Story, Bug or Feature

Goal

A dated outcome that cuts across streams and completes: the narrative, target date and definition of done behind a goal:<slug> tag. A custom type on no backlog level; Related-linked to the items that serve it. See Goals.

None — never parented, nothing parented to it

A work item’s title starts with its component in square brackets, for example [admin-service] or [registration-portal], so a flat list reads without opening anything.

2. States and the lifecycle rule

The states are the template’s. What the project adds is a rule for when an item moves, so that the state means the same thing on every item and automation can act on it.

State Category The item is here when

New

Proposed

Raised and not started. Classification (Area Path, parent, priority) happens here, by a person or by the factory’s classifier.

Active

In progress

Someone is working on it: a person, or an agent identity it is assigned to. For a Task created by automation, Active means due.

Resolved

In progress (Story, Bug, Feature)

The change has merged into develop. This is the first fixed point of the rule: Resolved at merge, not at pull request creation and not at release. The pull request is linked on the item.

Closed

Completed

Verified where it matters — on stage for a story or bug, or in production when stage cannot show it. Testing tasks are Closed when their check passed; release tasks when the action is done and the evidence is in a comment.

Removed

Removed

Will never be done. Not available on Bug, which is Closed with a comment instead.

Met

Resolved (Goal only)

The goal’s outcome has been observed; a comment names the observation. Closed follows the retrospective note.

Between Resolved and Closed, two events are recorded as comments, not states, because an item can be on stage and later in production without changing what it is: "released in <version>, on stage" when the release reaches stage, and "in production" when it is promoted. The Released In field carries the release name so the fact is queryable as well as readable.

Task has no Resolved state. A Task is New, then Active while someone or something works on it, then Closed.

3. Fields every item carries

Field How the project uses it

Area Path

The component. The tree mirrors the repositories and platforms: Services (admin-service, report-server, mcp-server, …), Portals (registration, membership, admin), Clients, WordPress, Platform, Tooling. Every open item below Epic sits in a leaf; an item on the project root is unclassified and the classifier picks it up. A new component means a new node, never a tag.

Iteration Path

Not used for planning. The project has a single operator and no sprints; the root iteration is the only one. Reserved — see the discussion of release marking in the Software Factory design, which chose a field over the iteration for that purpose.

Priority

The template’s 1 to 4. Set on every Story and Bug at classification; a Bug’s priority is its severity to the user, not its difficulty.

Assigned To

The person, or the agent identity (a service principal named for a factory role), doing the work. Assignment to an agent identity is the hand-off that starts a factory role; assignment to a person is a hand-off to a person. An unassigned Active item is a smell.

Acceptance Criteria (Story)

One bullet per observable outcome, as a checklist under an ## Acceptance Criteria heading in the Description — the project’s convention, which the work-item-creation skill writes — or in the Acceptance Criteria field. The resolver reads both, the field first, and ends the section at the next heading. These bullets become the Testing tasks once the story is Resolved, so write each as something a tester can check and record.

Repro Steps (Bug)

What was done, what happened, what should have happened, on which environment and data.

Tags

Only values from the closed vocabulary in Work Item Tags. A fact that a field already answers is never a tag.

Links

Parent (one), children, and the pull request link that the branch name creates. Hyperlinks to the design journal entry or the documentation page the item implements are placed in the description, as public URLs where the page is public.

4. The Activity field

Tasks carry the template’s Activity field, and the project uses three of its values to say what kind of task automation created, instead of a tag:

Activity Meaning

Testing

A check to run once the parent’s change is on an environment. One per acceptance criterion of the parent Story, or one "verify the fix on stage" for a Bug. Created when the parent is Resolved.

Deployment

A release task: an action that can only be done when the change reaches an environment — a manifest edit, a data migration or back-fill, a cache eviction, a credential rotation. One per environment, with the environment in the Target Environment field. Becomes Active when its release reaches that environment.

Documentation

A documentation change that follows from the parent and is tracked separately from the code change.

The other values the template offers (Design, Development, Requirements) are not written by automation and are left at their default for hand-made tasks.

5. Who moves what

Transition Moved by

New to Active

The person who starts the work, or the factory’s dispatcher when it assigns an agent identity.

Active to Resolved

The merge into develop: the factory’s resolver, on every merge. Never set by hand before the merge.

The release and stage comments, Released In

The factory’s release marking, which runs when a release is tagged and its stage manifest bumped, and again when the operator records the production promotion. The release comment names the pull requests and links the release; the "on stage" comment also reaches the item’s Testing tasks, and the Deployment tasks for that environment move to Active.

Resolved to Closed

The person who verified the behaviour on stage or in production, or the acceptance-test runner when it exists.

Classification (Area Path, parent, priority)

The classifier role, daily, on items on the project root; a person at any time.

6. Related