Your definition of done, on the map and in Azure Boards.
CardBoard is a user story map that syncs with Azure DevOps work items. A linked card and its work item share six fields both ways, including acceptance criteria and status. Rewrite the criteria in Azure Boards and the card has the new text within seconds. Move the card to a later release slice and the work item stays where it is.
Six fields both ways, starting with the two most tools skip.
Acceptance criteria are where a story map and a sprint most often disagree. The map says one thing, the work item says another, and whoever reads the wrong one builds the wrong thing. Here they're one text. Status comes back to the map, and a status change made on the map goes out to Azure DevOps too.
| Card field | Direction | Notes |
|---|---|---|
| Acceptance criteria | Both ways | The standard Acceptance Criteria field. |
| Status | Both ways | Your process's own states: Agile, Scrum, CMMI, or custom. |
| Title | Both ways | |
| Description | Both ways | Rich text converts to Markdown and back. |
| Assignee | Both ways | Matched by email address. |
| Story points | Both ways | Effort, used by Epics, Features, and CMMI, comes in as size too. |
| Parent | CardBoard to Azure DevOps, and on import | Set a card's parent on the map and the work item gets the link. |
| Work item type | When created | Epic, Feature, User Story, Task, Bug, or your own types. |
| Position, release slice, color | Never | The map owns these. |
How it converts formatting and which work item types carry it: acceptance criteria sync. Every field in detail: Azure DevOps integration docs.
Epic, Feature, User Story is a tree. Your user's day is a line.
Azure Boards organizes work by hierarchy and backlog priority. That's how delivery should be tracked. It can't show the order a user moves through the product, or which thin slice of stories makes a release worth shipping. Those are the questions a story map exists to answer.
So CardBoard uses your tree once and then lets go. Import a backlog and the first layout follows Epic, Feature, and User Story. From there you rearrange it into the user's path. Nothing in Azure DevOps moves a card afterward, so the map can say something the backlog doesn't.
Recut a release without re-planning a sprint.
A release slice on the map is a scope argument: what's the least we can ship that a user would notice? An iteration is a delivery commitment. Some tools bind the two, so dragging a story between releases rewrites its iteration path. CardBoard keeps them apart. Slice and re-slice while you're still deciding, and the team's sprints don't move.
When you're ready to commit, connect the board through a saved query scoped to an iteration. Cards you send to Azure DevOps take that query's area and iteration path, so new work lands where the team plans.
CardBoard and StoriesOnBoard with Azure DevOps.
StoriesOnBoard is the tool most Azure DevOps teams find first, and it's a good one. The two make different bets. StoriesOnBoard binds the map to your backlog so the map mirrors it. CardBoard links the fields and leaves the layout to you.
| Azure DevOps | CardBoard | StoriesOnBoard |
|---|---|---|
| Acceptance criteria | Both ways, to the Acceptance Criteria field | Not listed among synced fields |
| Status | Both ways | From Azure DevOps only. Read-only on the map. |
| Title, description, estimate | Both ways | Both ways |
| Assignee | Both ways, matched by email | Not listed among synced fields |
| Who places a card | You. Import builds a first layout from your backlog tree, then nothing in Azure DevOps moves a card. | The map's three levels are bound to Epic, Feature, and User Story. |
| Releases | Release slices on the map. Iterations stay in Azure DevOps. | Synced with iterations |
| Live collaboration | Always-on live cursors, visible selections, follow a teammate | Online avatars, which card each person is viewing, follow a presenter |
| Guests | Free, and can edit the map | Free viewers who can comment |
StoriesOnBoard facts from its help center, checked September 28, 2026: Pushing cards, Customizing the integration, Hierarchy sync, Release sync, Online users.
Pick StoriesOnBoard if
you want releases to be iterations, the map's levels to be your work item levels, or you still run Team Foundation Server on-premises. It supports TFS. CardBoard connects to Azure DevOps in the cloud only.
Pick CardBoard if
acceptance criteria are your contract with engineering, status should move from either side, or the map needs to disagree with the backlog while you work out scope.
Beyond Azure DevOps, the full CardBoard and StoriesOnBoard comparison covers Jira, pricing, guests, and AI agents. Avion and Miro also sync with Azure DevOps. Pricing, guests, and the rest of the field are on our story mapping tools comparison.
A connection that outlives whoever set it up.
-
The workspace owns the connection
CardBoard holds the link to your Azure DevOps organization. When the person who set it up moves on, updates keep coming in.
-
Service hooks repair themselves
A daily check re-registers any hook an admin deletes. Admins see hook health in Settings. How the hooks work.
-
Every write has a name on it
Changes go out with the editing member's own Microsoft account, so work item history shows who changed what.
Frequently asked questions
- Does Azure Boards have a story map?
- No. Azure Boards orders work by backlog priority. A story map adds a second axis, the steps a user takes, so teams map in a separate tool and link it back.
- Does StoriesOnBoard sync acceptance criteria with Azure DevOps?
- Its Azure DevOps help articles list title, description, and estimate as the fields that sync both ways, and say card status is editable only from Azure DevOps. Acceptance criteria aren't listed. We checked in September 2026; their links are under the comparison table. CardBoard syncs acceptance criteria and status both ways.
- Does moving a card change the work item's iteration or backlog order?
- No. Position, release slice, and color never sync. You can recut a release on the map without touching iteration paths or backlog priority.
- Can I build the map from an existing Azure DevOps backlog?
- Yes. Connect the board to a project, or to one of its saved queries, then import work items from the tracker drawer. On a story map the first layout follows your Epic, Feature, and User Story tree. After that the layout is yours.
- Does it work with CMMI or a custom process?
- Yes. The status menu lists whatever states your project uses, so there's nothing to map by hand. On CMMI, Effort comes in as the card's size.
- What does it cost?
- Mapping is free. Connecting a board to Azure DevOps needs a paid plan, from $10 a month on Pro. Guests never cost anything.
Coming from SpecMap? Rebuild your SpecMap story map. On Jira? See story mapping with Jira. On Linear? See story mapping for Linear. New to the method? Start with the user story mapping guide.
Put your Azure DevOps backlog on a map.
Mapping is free. Sync with Azure DevOps starts on Pro at $10 a month, and guests never pay.