Story Definition

Workflow

Step 1 — Gather context

~~project tracker

• Ask the user which project or board to work with
• Pull the current epics, labels, and team members to understand project structure
• Check existing backlog for related or duplicate stories
• Pull any linked requirements, specs, or parent epics for context
• Identify the project's existing conventions (label taxonomy, story point scale, naming patterns)

• Ask the user to describe the feature, epic, or requirement
• Ask about the team context: who will implement, what tech stack, any constraints
• Ask about existing conventions they follow for story format

• What is the goal or outcome this work should achieve?
• Are there known constraints (timeline, dependencies, technical limitations)?
• What level of granularity do they need? (epic-level, sprint-ready, task-level)

Step 2 — Analyze and decompose

1. Vertical slicing — Each story delivers a thin slice of end-to-end value, not a horizontal layer. A story should touch all layers needed (UI, API, DB) for one specific behavior.
2. INVEST criteria — Every story must be:
   • Independent — Can be built and delivered without waiting for other stories (minimize dependencies)
   • Negotiable — Details can be discussed; it is not a rigid specification
   • Valuable — Delivers clear value to a user, stakeholder, or the system
   • Estimable — The team can reasonably estimate the effort
   • Small — Fits within a single sprint (if too big, split further)
   • Testable — Has clear conditions to verify it is done
3. Dependency mapping — Identify which stories block others and flag circular dependencies
4. Risk-first ordering — Surface high-risk or high-uncertainty stories early so they can be tackled first

Step 3 — Write stories

Title: [Action-oriented, concise — starts with a verb or "As a..."]

User story:
As a [specific persona/role],
I want to [concrete action],
so that [measurable outcome or business value].

Acceptance criteria:
- [ ] Given [context], when [action], then [expected result]
- [ ] Given [context], when [action], then [expected result]
- [ ] [Additional criteria using Given/When/Then or plain checkboxes]

Definition of done:
- [ ] Code implemented and passing CI
- [ ] Unit/integration tests covering acceptance criteria
- [ ] Code reviewed and approved
- [ ] [Project-specific DoD items from team conventions]

Technical notes:
- Implementation hints, API contracts, data model changes
- Links to relevant specs, designs, or documentation
- Known risks or open questions to resolve during implementation

Size: [T-shirt (XS/S/M/L/XL) or story points — match project convention]
Priority: [P0-Critical / P1-High / P2-Medium / P3-Low]
Labels: [Use existing project labels when available]
Dependencies: [List story titles or IDs this story depends on]

• Title is scannable in a board view (under 80 characters)
• "So that" clause has a real outcome, not a restatement of the action
• Acceptance criteria are testable — no ambiguous words like "should work well"
• Each acceptance criterion covers one behavior (split compound criteria)
• Technical notes exist for anything non-obvious to the implementer
• Size reflects actual complexity, not just code volume
• No hidden work — if the story requires migrations, config changes, or docs updates, they are explicit

Step 4 — Validate and organize

1. Coverage — Does the full set of stories deliver the complete feature/epic? Identify gaps.
2. Overlap — Are any two stories doing the same work? Merge or clarify boundaries.
3. Dependency graph — Can the stories be ordered into a buildable sequence? Flag circular dependencies.
4. Sprint fitness — Is each story small enough for one sprint? Flag any that need further splitting.
5. Testability — Can QA verify every acceptance criterion without ambiguity?
6. Backlog check — If

   ~~project tracker

   is connected, verify no existing stories already cover this work.

• Group stories by epic or functional area
• Order by suggested implementation sequence (dependencies first, then priority)
• Clearly mark which stories are sprint-ready vs need further refinement
• Summarize the total scope: number of stories, estimated total effort, suggested sprint distribution

Step 5 — Create in project tracker

~~project tracker

• Confirm with the user before creating any tickets
• Show a summary table first:

• After user approval, create each story in the connected tool
• Apply labels, assignees, sprint, and parent epic as discussed
• Set up dependency links between stories where supported
• Report back with links to created tickets

• Present the stories in the structured format above
• Offer to export as markdown or a formatted list the user can paste into their tool

Step 6 — Notify team

~~chat

• Ask if the user wants to notify the team about the new stories
• Draft a concise message summarizing what was created, how many stories, total estimated effort, and a link to the board/project
• Post only after user confirms

Story sizing guide

Priority framework

Anti-patterns to avoid