What exactly gets created in Azure Boards when I export?

A full work-item hierarchy: epics at the top, then features, user stories and tasks beneath them in the correct parent-child structure. They land as real work items in your project, not as a flat list you then have to organise by hand.

Do the Wiki page and the Boards items come from the same session?

Yes — that's the entire point. One agreed conversation produces both. Boards receives the work items and the Wiki receives the spec, so the two never start out as separate documents written by separate people at separate times.

We rely on dependency links between work items — does Projan set those up?

Yes. Where the plan establishes that one piece of work depends on or blocks another, Projan creates native dependency links between the Azure Boards work items, so the order of work is visible in Boards itself.

Can Projan use an existing Azure DevOps work item as input?

Yes. Paste the URL of an Azure DevOps work item into a session and Projan pulls it in as grounding context, so a new plan can build on work that already exists rather than starting cold.

Where does the planning conversation actually take place?

In Microsoft Teams or Slack via Projan's bots, or in the Projan web workspace. The session runs in-channel where your team already is; the agreed output is what lands in Azure DevOps afterwards.

Will the Wiki page just be a dump of the work items?

No. The Wiki page is the agreed spec — the narrative and reasoning behind the work — while Boards holds the work items themselves. They reflect the same decision but serve different readers: the spec explains, the board tracks.

We're all-in on Azure DevOps — can one planning session feed both Boards and the Wiki?

On the Microsoft stack, the plan tends to live in two places that drift apart: work items in Azure Boards and a spec in the Wiki, updated by different people at different times. Projan keeps them in sync by producing both from one agreed conversation. It facilitates the planning, then exports the result as Azure Boards work items — epics, features, user stories and tasks in the right hierarchy, with dependencies linked — and writes the agreed spec into the Wiki. Boards gets the work and the Wiki gets the narrative, both reflecting the same decision rather than two diverging versions.

A platform team on Azure DevOps plans a piece of work in a call. By Friday, two artefacts exist. There’s a set of work items in Boards, raised by whoever was quickest to the keyboard, with terse titles and no real context. And there’s a Wiki page — started with good intentions, half-finished, last edited by someone who has since moved teams. Both claim to describe the same decision. They already disagree about the details. Within a sprint, nobody trusts the Wiki and the board has quietly become the only truth, minus the reasoning.

When the plan lives in two places

The Microsoft stack gives you two excellent homes for a plan, and that’s precisely the problem. Boards is built for the work; the Wiki is built for the narrative. Left to people, they get populated separately — different authors, different moments, different levels of energy — and they drift apart from day one. The drift isn’t a discipline failure; it’s structural. The act of agreeing a plan and the act of typing it into two systems are separated in time, and anything separated in time goes out of sync. So the spec rots, the board loses the why, and an engineer ends up reading a one-line story and guessing at intent.

One session, Boards and Wiki together

Take a data-residency change: customer data for one region now has to stay in that region. The team works through it in a Projan session — what data is in scope, which services move, what has to ship before what.

When they agree, Projan writes the result into Azure DevOps twice, from that single conversation. Boards gets the work: an epic for the residency change, features beneath it for each affected service, user stories for the concrete changes, tasks under those — in the right hierarchy. Where the migration must precede the cut-over, Projan creates a native dependency link between those work items, so the sequence is visible on the board. And the Wiki gets the agreed spec as a page — the scope, the regional boundary, the reasoning the team settled on. Two artefacts, one decision, written at the same moment from the same agreement. There’s nothing for them to drift away from, because neither was typed up after the fact.

What lands in Azure DevOps

From the agreed session	What Projan produces
The overall initiative	An epic in Azure Boards
Each major area of work	Features under the epic
The concrete changes	User stories, with tasks beneath them
”Migration ships before cut-over”	A native dependency link between the work items
The agreed spec and reasoning	A Wiki page holding the narrative

The hierarchy is real parent-child structure in Boards, not a flat list. The dependency links are native, so they show up in Boards’ own views. And the Wiki page is the spec, not a copy of the tickets — Boards tracks, the Wiki explains.

Plan in Teams or Slack, deliver in Azure DevOps

The deciding doesn’t move into a new tool. Projan’s Microsoft Teams and Slack bots run the whole facilitated session in-channel — the questions, the disagreement, the agreement — right where the team already works. A team that lives in Teams never leaves it; a team in Slack never leaves Slack; the web workspace is there if someone wants a quieter canvas. Whichever surface the conversation happens on, the agreed output is what lands in Azure DevOps: the work items in Boards, the spec in the Wiki.

Setting it up

Connect Azure DevOps once under Integrations, choose the project to export into, run a session on whichever surface suits the team, and export. Boards receives the work-item hierarchy with its dependency links; the Wiki receives the spec page. You can also feed an existing Azure DevOps work item back in as context by pasting its URL, so a new plan builds on what’s already there.

Azure DevOps stays the system of record

Projan isn’t competing with Azure DevOps — it feeds it. Boards remains your source of truth for what’s being delivered, and the Wiki remains your reference for why. Projan just makes sure both come out of the same agreed conversation, so the work and the narrative describe one decision instead of slowly becoming two. Azure DevOps stays the system of record; Projan makes the record consistent from the start.