How do I run backlog refinement in Azure DevOps?

Run refinement as a short, prepared working session on 10 to 15 pre-picked work items, with the work item form open and edited live, and end it by dragging the refined items into the next iteration in the Planning pane. If the meeting ends and the work items look the same as before, it was a conversation, not refinement.

Azure Boards has every part you need for this: the backlog view for the candidate list, the work item form for the edits, the Planning pane for the sprint, and the Forecast tool for the sanity check. What teams usually lack is the sequence.

What do I prepare before the session?

Open Boards → Backlogs for your team, add Story Points, State, and Tags through Column options, and walk the top of the backlog. Pick the 10 to 15 highest-priority items that aren’t ready yet and tag them refine-next. That tag is your agenda, and it takes about 10 minutes to build.

Send the list before the meeting, not the invite text. People read work items when the link points at 12 specific items; nobody reads “the backlog”. If a work item needs an answer from outside the team, chase it now: an hour of refinement spent speculating about somebody else’s decision is an hour spent writing fiction.

Cap the session at 60 minutes and hold it weekly rather than marathon-style before each sprint. Weekly refinement keeps a one-sprint buffer of ready work, which is what makes planning short.

How should the session actually run?

One work item at a time, 5 to 8 minutes each, with someone sharing the work item form and typing. The rhythm that works:

1. The author reads the title and description aloud. Reading it out loud finds vague scope faster than any checklist.
2. Anyone states what they would need to start. Not opinions on the design, just missing information.
3. The typist edits the work item live. Title, Description, Acceptance Criteria, Story Points, links to dependencies. Right now, in the room.
4. Call the outcome out loud. Ready, needs a split, or blocked on a named question with a named owner. Every work item leaves with one of the three.

The timebox is the discipline. When 8 minutes pass without agreement on scope, stop: you have learned something real, which is that the work item is too large or missing an answer. Tag it, move on, and handle it out of band. Two teams-worth of people watching one person think is the most expensive thing in the sprint.

Keep decisions in the fields, not the Discussion thread. Azure DevOps has no Discussion field: comments land in History, which means a decision recorded as a comment is effectively unqueryable and unread. If it changes the work, it goes in Description or Acceptance Criteria.

What changes on the work item?

Refinement should leave a visible diff. On a User Story, that means:

• Title names an outcome, not an area. “Returns” becomes “Customer requests a prepaid return label within 30 days”.
• Description says who it is for, what they get, and why, in enough detail to estimate. Implementation choices belong in Tasks.
• Acceptance Criteria is filled with testable lines. If that field is empty at the end of refinement, the work item did not get refined. See writing testable acceptance criteria.
• Story Points set, and set by the people who will build it. Velocity charts and the Forecast tool both read this field, so an unestimated backlog silently disables your planning tools.
• Links for anything the work waits on, as related or predecessor work items rather than a sentence in the description.

Work items that come back “needs a split” get handled with the patterns in splitting oversized work items, usually right after the session while the discussion is fresh.

How do I close the session?

Spend the last 10 minutes turning refined work into a plan. Open the Planning pane on the backlog view and drag the ready items into the upcoming iteration, then run the Forecast tool with your team’s velocity to see where the sprint line actually falls. Iteration paths need to be configured for the team first, which is a one-time setup.

The forecast is not a commitment, it is a reality check: if the refined work runs to two sprints, you know before planning instead of during it. Then close the loop by clearing the refine-next tags on everything that got to ready, so next week’s agenda builds itself.

How does Vindex change refinement?

It moves the discovery out of the meeting. Vindex scores every work item on create and update, so the low-scoring items are already flagged when you build the agenda: you walk into refinement knowing which work items have vague scope, missing criteria, or too much in them, and the session is spent fixing them rather than finding them.

Editing a work item and saving re-scores it, which means the room’s work is visible immediately: the score moves while you are still looking at the form. Teams that run this way stop arguing about whether a work item is ready and start reading the finding.

Try it on the work items in your next agenda first. Paste one work item or drop a CSV export and see which ones come back low. No signup, and uploads are deleted after 24 hours.