Backlog Scanner

Backlog Scanner

Identify, classify and format backlog candidates from any source material: meeting transcripts, chat history, documents, side conversations, user feedback.

The output is a file someone can act on: candidates written as user stories, and everything that did not qualify listed with where it should go instead. Nothing raised in the source is silently dropped.

Trigger

Activated when the user:

• Says "backlog scan", "scan for backlog", "extract backlog items", "find backlog opportunities"
• Provides a transcript or document and asks for backlog extraction
• Asks to consolidate backlog items across several sources

Workflow

Step 0: establish the context

Ask before scanning, in one message, and keep the answers for the rest of the session. Skip any question the user has already answered in their request.

1. What is this product or programme called? Used in the output filename and its heading.
2. Who are the users, by role? Their real job titles, not "user". An analyst, a site foreman, a claims handler, a teacher: the specific role is what makes a user story arguable.
3. Is there an existing backlog to check against? If yes, what are its reference prefixes and where can it be read.
4. Who decides what enters the backlog? The candidates file is addressed to that person, and saying so changes how it is written.

If the user does not answer, proceed with generic defaults and say so once at the top of the output: roles become "as a user", the filename uses the source name, and no cross-referencing is done. Do not stall the scan waiting for an answer.

Step 1: source identification

Identify what is being scanned:

• Transcript: a meeting recording (.docx, .odt, .vtt, .txt). Scan the full text.
• Chat history: search past conversations by keyword. Scan several if needed.
• Document: any uploaded file. Extract actionable items.
• Several sources: if the user asks to consolidate, scan all of them and deduplicate.

Step 2: extraction pass

For each source, identify statements matching ANY of these patterns.

Feature signals

• "I want…", "we need…", "it would be nice if…"
• "What if we could…", "can we…", "is it possible to…"
• Someone describes a workflow pain point
• Someone describes a manual process that could be automated
• A comparison with another tool ("product X does this")

Governance and process signals

• "We need to define…", "there is no standard for…"
• "Who decides…", "how do we handle…"
• A recurring problem with no defined response
• Scaling concerns ("when we open this to more people…")

Infrastructure signals

• "We need more…", "it is too slow…", "it crashed…"
• Monitoring gaps, alerting gaps, capacity concerns
• Deployment friction, environment issues

Architecture signals

• "We should restructure…", "the current design…"
• Integration needs between systems
• Resilience, redundancy, switching provider

For each signal, capture:

• Who said it (reporter)
• Timestamp, if available
• Verbatim quote, or a close paraphrase
• Context: what prompted the statement
• Who confirmed or supported it, if anyone

The need-without-solution rule. A clearly expressed need qualifies as a candidate even when no solution was discussed, provided it implies a product, infrastructure or delivery capability. The admission gate below still applies: a complaint implying no capability is not a candidate. Write the story at the capability level and park the unresolved solution under "Constraints and open questions". A need whose solution is unknown is flagged as needing scoping, and it is never dropped for being hard to estimate.

Step 3: the admission gate

Candidates are created through a product owner's lens. A candidate is a new or changed product capability that would go on a roadmap and be weighed against other build work competing for the same delivery capacity. Much of what a meeting raises is something else.

Before an extracted signal becomes a candidate, classify it into exactly ONE bucket. Only product opportunities proceed. The other three are routed out and listed in the "Screened out" section, never silently dropped and never mixed into the candidate list.

Rules that settle the frequent cases:

• The type label (feature, governance, infra, architecture) is a sub-category of a product opportunity. It is never a pass: an "infra" item can still be a provisioning task and get screened out.
• A crash, or "it does not behave the way the other environment does", is a bug.
• "We need access to X", "declare a subdomain", "claim storage" is a task, even when it unlocks a capability. The capability may separately be a candidate; the provisioning is not.
• "We need to define, categorise or write a scheme" is documentation, unless it means building a standing mechanism into the product.
• Governance items survive as candidates only when they structure delivery as a built or standing mechanism.
• When torn between a product opportunity and one of the other three, state the classification chosen and why, so the reader can override it.

Step 4: classification

For each item that passed the gate:

Step 5: deduplication

Before generating the output, check the item against the backlog named in step 0 and against any candidates file produced earlier. A duplicate is either skipped or recorded as "enriches [reference]". A new item gets a provisional number.

Step 6: output

Produce a markdown file with this structure.

# Backlog candidates: [source name and date]

Items identified from [source description].
[For review by <the decision-maker from step 0> before entry into the backlog.]

Provisional numbering: BC[start] to BC[end].

---

## Summary

| # | Title | Type | Priority |
|---|---|---|---|
| BC[N] | [title] | [type] | [priority] |

---

### BC[N]: [title]

| Field | Value |
|---|---|
| Type | [feature / governance / infra / architecture] |
| Reporter | [name], [timestamp] |
| Confirmed | [who confirmed, if anyone] |

**As a** [role],
**I want** [capability],
**so that** [benefit].

**Acceptance criteria**

- [criterion]

**Constraints and open questions**

- [if any]

**Dependencies**

- [if any]

---

## Screened out

Items raised in the source that did not pass the admission gate,
with their routing, so nothing is lost.

| Item | Classification | Rationale | Routed to |
|---|---|---|---|
| [item] | Bug / task / documentation | [one line] | [where it goes] |

## Already tracked

| Existing reference | Title | New context from this scan |
|---|---|---|
| [reference] | [title] | [what this scan adds] |

Step 7: filename

{context} - {YYYYMMDD} - Backlog Candidates v{NN}.md, where {context} is the product or programme named in step 0. For a consolidation across several inputs, use the programme name and Backlog Consolidation in place of Backlog Candidates.

If the user has their own naming convention, follow theirs.

Writing the user stories

Role. Use the real roles gathered in step 0. "As a user" is the fallback when no specific role applies, and it weakens the story every time it is used by default.

Want. Describe the capability rather than the implementation. "I want to forward an email into the system" beats "I want an Outlook plugin".

So that. Describe the business benefit rather than the technical outcome. "So that I can search the content the same day" beats "so that it is indexed".

Acceptance criteria. Observable, testable behaviours.

Constraints. Technical limits, security considerations, dependencies, attributed to whoever raised them, with a timestamp.

An item that does not fit the story format (a governance framework, a process definition, an architectural constraint) is written free-form with the same header fields.

Quality checks before delivery

1. Every item has a reporter and a timestamp, or "chat context" when the source carries none.
2. No item duplicates an existing entry without adding new context.
3. Stories pass INVEST: independent, negotiable, valuable, estimable, small, testable. Flag the ones that are too large and suggest how to split them.
4. Priorities are justified rather than defaulted to P2.
5. Dependencies point at other candidates or at existing entries.
6. Every candidate passed the admission gate, and everything that did not is in the "Screened out" section with its routing.