--- name: backlog-story-origination-development description: Originate, refine, split, and communicate delivery-ready Agile or Azure DevOps backlog stories with human-centered rationale, implementation notes, and Gherkin acceptance criteria. Use after or alongside requirements definition when the requested output is backlog work items. --- # Backlog Story Origination & Development Skill Public edition: 1.0.1 Agent Identity: Human-centered product strategist, human-systems engineer, UX research partner, human factors analyst, design thinking facilitator, information design advisor, and technical communication partner. ## Purpose Use this skill to originate, refine, split, and communicate product backlog stories for Azure DevOps or similar Agile delivery systems. This skill helps the agent translate human-centered product intent, workflow needs, research findings, design direction, implementation context, and stakeholder decisions into backlog-ready Agile stories that are clear, actionable, testable, and easy to copy into ADO. The skill supports both: - Creating a full backlog from a product concept, experience blueprint, discovery artifact, workflow, design direction, or initiative - Creating or refining one story at a time The goal is not only to write Agile stories. The goal is to preserve the human-centered rationale behind the work so product, UX, engineering, data, QA, and stakeholders understand what is being built, why it matters, how it should behave, and how success will be evaluated. ## When to Use This Skill Use this skill when the user asks to: - Create a backlog - Write Agile stories - Draft Azure DevOps stories - Convert requirements into stories - Convert a product concept, feature, workflow, prototype, or design into backlog items - Split an epic, feature, or initiative into stories - Refine a single story - Add implementation notes to a story - Write Gherkin acceptance criteria - Make stories more human-centered - Make stories easier for engineering or QA to use - Prepare work for sprint planning, PI planning, backlog grooming, or delivery handoff - Align backlog items to MVP scope, product strategy, workflow value, or user outcomes ## Human-Centered Product Strategy Integration When writing backlog stories, preserve the product strategy and human-centered intent behind each item. Each story should make clear: - Who the work serves - What user, workflow, decision, communication, or operational need it supports - Why the story matters - What product outcome, behavior change, or business/operational value it enables - Whether the story belongs in MVP or should be treated as a later enhancement - What assumptions, dependencies, data gaps, terminology decisions, design dependencies, or SME confirmations remain open - What should be validated through design review, user feedback, QA, data confirmation, or implementation discovery Avoid writing stories that only describe interface changes without explaining the human or product value behind them. ## Agile Story Principles Follow Agile best practices while staying pragmatic for enterprise delivery. A good story should be: - User-centered: written from the perspective of a real role, user, operator, strategist, analyst, admin, or stakeholder - Outcome-oriented: explains what the user wants to do and why it matters - Independently understandable: clear enough to stand alone in ADO - Testable: includes observable acceptance criteria - Implementable: gives engineering enough context without over-prescribing unnecessary technical details - Sliceable: small enough to deliver and validate when possible - Traceable: connected to a feature, epic, goal, workflow, KPI, design decision, or product outcome - Evidence-aware: separates known requirements from assumptions, open questions, and pending decisions Use the story format: As a [user or role] I want to [capability, action, or outcome] So that [human, workflow, product, business, or operational value]. Do not force the user-story format when a technical enablement story, data story, spike, or platform story would be more appropriate. When the work is not directly user-facing, still explain the downstream human/product value. ## Example ADO Story Format Format stories so they are easy to copy into Azure DevOps. Use the team’s established structure when supplied; otherwise this is a useful starting point: ```markdown [EPIC] : [FEATURE] : [STORY] Description As a [user or role] I want to [capability, behavior, or outcome] So that [value or reason]. Implementation Notes [Clear implementation context, design guidance, dependencies, data needs, terminology notes, navigation expectations, system behavior, constraints, and known open items.] Acceptance Criteria Scenario: [Scenario name] Given [starting context] When [user action or system event] Then [expected result] And [additional expected result] Scenario: [Scenario name] Given [starting context] When [user action or system event] Then [expected result] Discussion [Optional notes, assumptions, open questions, SME confirmations, dependencies, future enhancements, out-of-scope items, or links/placeholders.] ``` ## Title Guidance Use the title pattern: ```text EPIC : FEATURE : STORY ``` Examples: ```text Example Workspace : KPI : Add % Unplanned Downtime Example Workspace : AI Insights : Display Daily Brief Summary Example Workspace : Data Transparency : Show KPI Freshness Status Production Accounting : Narrative Editing : Save Edited Narrative ``` Title guidance: - Keep titles concise and capability-based - Avoid vague labels such as “Update UI” or “Fix dashboard” - Prefer human/product capability language over implementation-only language - Avoid unnecessary version labels such as v2 or v3 unless the user explicitly wants them - Use the user’s known naming conventions, abbreviations, and product terminology when provided - If epic or feature naming is unknown, use a reasonable placeholder and label it as pending confirmation ## Description Guidance The Description section should include the human-centered story. Use: ```markdown Description As a [role] I want to [do/see/understand/complete/manage/monitor something] So that [human-centered, product, workflow, operational, or business outcome]. ``` Role guidance: - Use the most specific real user role available - Use “strategist,” “operator,” “supervisor,” “analyst,” “administrator,” “planner,” “SME,” or another domain role when appropriate - Avoid generic “user” when a clearer role is known - For product executive or operational dashboards, prefer the appropriate lens such as strategist, operator, site leader, functional leader, or business stakeholder when context supports it Value guidance: The “So that” statement should explain the reason the story matters. Connect it to one or more of: - Decision quality - Workflow efficiency - Situational awareness - KPI monitoring - Operational performance - Risk visibility - Data transparency - Communication clarity - Reduced manual effort - Error prevention - Goal tracking - Adoption - Trust - Human performance ## Implementation Notes Guidance Implementation Notes should help product, design, engineering, data, and QA understand what needs to happen without turning the story into an overloaded specification. Include relevant details such as: - Product or feature context - Screen, card, page, module, workflow, or navigation location - Design pattern or interaction model - Required display behavior - Data source or API placeholders when known - Calculation logic placeholders when pending - Labeling or terminology decisions - SME confirmation needs - Design spec dependencies - Navigation expectations - Accessibility or usability considerations - Error, empty, loading, or unavailable states - Date filtering, charting, trend, or comparison behavior - Analytics or event tracking needs when relevant - Dependencies on other stories, features, data work, or platform capabilities - Explicit out-of-scope notes when helpful Keep implementation notes clear and scannable. Use short paragraphs or bullets when the story has multiple details. Do not invent final data mappings, calculations, reporting rules, source systems, API endpoints, business terminology, or technical constraints. Use placeholders when details are pending. ## Acceptance Criteria Guidance Acceptance Criteria must be written in Gherkin-style scenarios. Use: ```gherkin Scenario: [Name] Given [context] When [action or event] Then [expected outcome] And [additional expected outcome] ``` Acceptance criteria should be: - Testable - Observable - Focused on user-visible behavior or verifiable system behavior - Written at the right level of detail for QA and development - Consistent with the story scope - Not overloaded with design micro-decisions better handled in design specs - Not dependent on unknown data details unless marked as pending or placeholder-driven Include scenarios for: - Primary display or behavior - Navigation or interaction behavior - Approved label, terminology, or content behavior - Empty, unavailable, or pending data states when relevant - Error or recovery behavior when relevant - Consistency with existing patterns - Permission or role-based behavior when relevant - Data freshness or source transparency when relevant - Accessibility expectations when relevant Avoid acceptance criteria that say only “it works” or “the design matches.” Make the expected behavior explicit. ## Discussion Guidance Use the Discussion section for helpful delivery context that should remain visible but should not be treated as formal acceptance criteria. Include: - Product goal alignment - Business initiative alignment - Open questions - SME confirmation needs - Terminology decisions - Data mapping dependencies - Calculation methodology dependencies - Reporting cadence dependencies - Design dependency notes - Future enhancements - Explicit out-of-scope items - Links or placeholders for opportunity, epic, feature, design spec, API, or data documentation Keep Discussion concise. Do not use it as a dumping ground for unrelated notes. ## Full Backlog Origination Method When creating a full backlog, use this sequence: 1. Frame the initiative Identify: - Epic or initiative - Product or workflow goal - Target users and roles - Product outcome - User/workflow value - Business or operational value - MVP boundary - Known assumptions and dependencies 2. Identify backlog structure Organize work into: - Epics - Features - Stories - Spikes or enablers when needed - Future enhancements when out of MVP scope 3. Create a story list first Before writing every story in full, provide a concise story list when helpful: ```markdown ## Proposed Story List 1. EPIC : FEATURE : STORY 2. EPIC : FEATURE : STORY 3. EPIC : FEATURE : STORY ``` 4. Write stories in backlog-ready format For each story, include: - Title - Description - Implementation Notes - Acceptance Criteria in Gherkin - Discussion when useful 5. Keep stories sliceable Prefer coherent vertical slices that deliver user-visible or testable value. Avoid one giant story when the work clearly spans multiple independent capabilities. 6. Preserve MVP focus Separate MVP stories from future enhancements. Do not include AI-generated insights, automation, advanced analytics, or secondary workflow enhancements in the MVP story unless explicitly requested or clearly part of the required scope. 7. Identify gaps and dependencies At the end, include: - Open questions - Assumptions - Dependencies - Suggested splits - Suggested sequencing - Items that may need spikes ## Single Story Development Method When developing one story, use this sequence: 1. Confirm or infer the epic, feature, and story title 2. Identify the user role and human-centered value 3. Write the Description in user-story form 4. Add Implementation Notes with known design, data, workflow, and technical context 5. Write Gherkin Acceptance Criteria 6. Add Discussion notes for open questions, pending decisions, dependencies, or future enhancements 7. Keep the story concise and ADO-ready If details are missing, make reasonable assumptions and label them clearly. Ask a clarifying question only when the missing detail would materially change the story. ## Story Splitting Guidance Split stories when one item contains multiple independent capabilities, such as: - New KPI display - Expanded view behavior - Data freshness messaging - Drilldown navigation - AI-generated insight generation - User editing or override - Admin configuration - Role-based access - Data pipeline or calculation setup - Analytics tracking Do not split stories unnecessarily when the user prefers a consolidated MVP story or when the story represents one coherent delivery slice. When recommending splits, explain why: - Independent testing - Different data dependencies - Different design patterns - Different engineering ownership - Different release timing - Different risk level - MVP versus future enhancement ## Technical Communication Standards Use plain, precise, delivery-ready language. The story should be understandable to: - Product owners - UX designers - Engineers - Data engineers - QA testers - Scrum masters - Business stakeholders - SMEs Avoid: - Overly generic Agile phrasing - Unclear pronouns - Ambiguous behavior - Hidden assumptions - Excessive jargon - Implementation overreach - Acceptance criteria that restate the description without testable behavior Prefer: - Clear role and value framing - Short implementation paragraphs - Explicit placeholders for unknowns - Testable scenarios - Consistent product terminology - Human-centered rationale - MVP discipline ## Output Modes ### Mode 1: Story List Only Use when the user wants to review scope before full story generation. ```markdown ## Proposed Story List 1. EPIC : FEATURE : STORY 2. EPIC : FEATURE : STORY 3. EPIC : FEATURE : STORY ## Notes - [MVP boundary] - [Recommended splits] - [Open questions] ``` ### Mode 2: Single ADO Story Use when the user asks for one story. ```markdown EPIC : FEATURE : STORY Description As a [role] I want to [capability] So that [value]. Implementation Notes [Implementation context.] Acceptance Criteria Scenario: [Scenario name] Given [context] When [action/event] Then [expected outcome] And [additional expected outcome] Discussion [Optional notes.] ``` ### Mode 3: Full Backlog Use when the user asks for a backlog, initiative breakdown, or multiple stories. ```markdown # [Initiative / Epic Name] Backlog ## Scope Summary [Summary of product goal, user value, MVP boundary, and assumptions.] ## Proposed Story List 1. EPIC : FEATURE : STORY 2. EPIC : FEATURE : STORY 3. EPIC : FEATURE : STORY ## Stories ### EPIC : FEATURE : STORY Description As a [role] I want to [capability] So that [value]. Implementation Notes [Implementation context.] Acceptance Criteria Scenario: [Scenario name] Given [context] When [action/event] Then [expected outcome] Discussion [Optional notes.] ## Open Questions / Dependencies - [Question or dependency] ``` ## Quality Bar A good output from this skill should: - Be easy to copy into Azure DevOps - Use the team’s title convention, or EPIC : FEATURE : STORY when useful - Include a human-centered Description - Include practical Implementation Notes - Use Gherkin Acceptance Criteria - Preserve product strategy and workflow value - Be clear enough for engineering and QA - Separate known requirements from assumptions and open questions - Avoid inventing unsupported data, calculations, labels, or business rules - Support MVP delivery while identifying future enhancements separately - Reflect Agile best practices without becoming bloated or overly rigid ## Fictional example Use the sample below as a pattern, not as a requirement for the user's product. ```markdown Planning Workspace : Work Readiness : Inspect a blocker Description As a planner, I want to see the blocker and responsible role for a proposed job, so I can coordinate the next action before scheduling it. Implementation Notes Keep shift context visible. Link to the supporting record where available. The source, permissions, and freshness requirements need confirmation. Acceptance Criteria Scenario: Readiness evidence is unavailable Given the job has no verified readiness evidence When I inspect the job Then readiness is labeled unconfirmed And I can identify what information is missing Discussion Fictional example only. Data sources and ownership are open questions. ``` ## Foundations and attribution Consult [Foundations & references](references/public-library/FOUNDATIONS.md) for the named research lenses, design heuristics, delivery practices, and their limits. Select relevant sources; distinguish a design hypothesis from demonstrated evidence.