| name | bc-plan-user-story |
| description | Turns a raw Business Central request, ADO ticket, or meeting note into a crisp user story with testable acceptance criteria, ready to be specced. Use when: plan a BC feature, write a user story, break down a ticket, clarify requirements, draft acceptance criteria, what should this feature do, turn a request into a story. |
BC · Plan a User Story
Produce a single, unambiguous user story and a first set of acceptance criteria from a raw
request. This is the PLAN phase — it runs before the full spec (bc-spec-author) and
keeps everyone honest about scope.
When to use
- A stakeholder or ADO ticket describes a need in loose terms.
- You need to confirm scope and "done" before any AL design happens.
- The request bundles several features and needs splitting.
Inputs to gather
- ADO ticket ID (if any) and its title/description. Read it via the Azure DevOps MCP server
if configured; otherwise ask the user to paste it.
- Who requested it (customer / internal) and the business value.
- Priority and target release/wave, if known.
Procedure
- Restate the need in one sentence, in business language.
- Write the user story in the canonical form, in the stakeholder's language (write it in
German if the ticket/discussion is in German), with each clause on its own line and the labels
in bold:
As a <role>
I want <capability>,
so that <business outcome>.
- Split if needed. If the request covers more than one outcome, propose separate stories
(one per deliverable) rather than one oversized story. Name each
ABC-{ID} candidate.
- Draft acceptance criteria in Given/When/Then, numbered
AC-01, AC-02, … Each must be:
- testable by a non-developer,
- tied to something in the story,
- free of vague words like "should work correctly".
- List open questions explicitly — anything that blocks a confident spec. Resolve ambiguities
by asking one focused question at a time (the ask-questions tool where available — VS Code's
askQuestions — otherwise inline), each with a few suggested answers; never invent answers.
- State what is out of scope.
- Align & refine. Play the story, criteria, and scope back to the user before finalizing. On
their response: changes → revise and re-present, keeping the work item in sync; questions
→ clarify one-at-a-time; alternative framing → loop back to restating the need; approval
→ move to hand-off. If the answers materially change the need or scope, loop back to step 1.
Don't write the story to the work item as final until the user agrees (or asks to save the draft).
Output
The chat-facing draft (Markdown):
**As a** <role>
**I want** <capability>,
**so that** <outcome>.
**Business value:** <why it matters>
**Priority:** P1 / P2 / P3 **Target:** <wave/date or TBD>
### Acceptance Criteria
- **AC-01** — Given <context>, when <action>, then <result>.
- **AC-02** — ...
### Open Questions
1. ...
### Out of Scope
- ...
Writing it into the work item (Azure DevOps)
When you update the ADO work item, mind the field formats (see the repo Copilot instructions):
- The Description field is HTML — send HTML (
<p>, <strong>, <br>, <h3>, <ul>),
not Markdown, or the tags render as raw text.
- Do not repeat a "User Story" heading in the Description. The work item is already typed
User Story (its title bar says so), so a second "User Story" H1/H2 is redundant noise — lead
straight with the three-line story statement.
- Put the role / goal / reason on three separate lines with the labels bold, then follow with
the background, acceptance criteria, and options sections.
- Discussion/comments use Markdown, not HTML — only the Description (and similar large
fields) are HTML.
- Screenshots/attachments can't be uploaded via the MCP tools — they only download existing
attachments. If the user pastes a screenshot and asks to attach it, say so and ask them to
drag-drop it into the work item's Description/comment in the browser (or, if a PAT is configured,
upload it via the REST
POST _apis/wit/attachments endpoint with curl and reference the URL in
the Description HTML). Don't silently ignore the request.
Example Description HTML:
<p><strong>Als</strong> <Rolle><br>
<strong>möchte ich</strong> <Fähigkeit>,<br>
<strong>damit</strong> <Nutzen>.</p>
<h3>Hintergrund & Ist-Zustand</h3>
<p>…</p>
Spec summary back-write (after bc-spec)
When bc-spec hands a finished spec back to you, add a concise Spec Summary to the work item so
a junior developer or PM can grasp the plan without opening the whole spec. Read the spec's
brief.md and plan.md, then write a short block into the work-item Description (below the
story), containing:
- Approach — one or two sentences on the chosen technical approach.
- Key decisions — the notable architecture choices (from the spec's decision table).
- Open questions — any still flagged awaiting customer.
- Spec link — the path to the spec folder (
specs/<Area>/<type>-<ID>-<slug>/).
Keep it to a few lines and refresh it if the spec changes. This is a summary, not a copy — the
spec folder remains the source of truth.
Language: the spec folder is English, but the work item is customer-facing — write the Spec
Summary in the customer's preferred language (the same language as the user story; translate from
the English spec if needed). Only the DevOps-facing summary is localized; the spec docs stay English.
Write it as HTML (Description field); if you'd rather keep it out of the story body, post it as a
Markdown discussion comment instead.
Quality gate (mirror of the repo issue form)
Next step
When the story and criteria are agreed, move to bc-spec-author (agent: bc-spec) to
create the full specs/<Area>/<type>-<ID>-<slug>/ story folder.
