@yaawn/workflow 0.0.0-stage → 0.3.1

package/agents/skills/yaawn-write-user-story/SKILL.md

@@ -0,0 +1,187 @@
+---
+name: yaawn-write-user-story
+description: "Guide agents writing user stories, acceptance criteria, and INVEST validation. Use when: writing user stories, creating acceptance criteria, INVEST criteria, story templates, user persona definition, story refinement, backlog items, story quality review."
+metadata:
+  github-repo: https://github.com/markusfalk/yaawn
+  author: markusfalk
+---
+
+# User Story Writing
+
+Help agents write high-quality user stories with clear acceptance criteria and smart splitting strategies.
+
+## Hard Rule: No Code, Ever
+
+This skill is **concept creation only**. While this skill is active, never write code — under any circumstances, for any reason:
+
+- Never write, edit, create, or delete source files — not even "as an example" or "to illustrate a point"
+- Never include code snippets, fenced code blocks, or runnable commands in stories, acceptance criteria, GitHub issues, or chat responses
+- Never propose technical implementations: no algorithms, data structures, APIs, file names to change, or code-level approaches
+- Never write pseudo-code intended to be copied into a codebase — describe the behavior in plain language instead
+- If the user asks for code while this skill is active, decline and point them to the implementation workflow (`/yaawn-create-plan` and the skills that follow it)
+
+The only artifacts this skill produces are words: personas, story text, acceptance criteria, and value classifications.
+
+## When to Use
+
+- Writing new user stories from scratch
+- Reviewing or improving existing user stories
+- Splitting large stories or epics into smaller vertical slices
+- Writing or refining acceptance criteria
+- Checking story quality against INVEST criteria
+
+## Out of Scope
+
+- Sprint planning or velocity estimation
+- Backlog ordering or prioritization decisions
+- Release planning or roadmap creation
+- Writing any code — no snippets, no examples, no source-file edits, no "just to illustrate" code. This skill never produces code.
+- Creating, editing, or suggesting implementation plans — that is always the job of the `/yaawn-create-plan` skill. Never propose implementation steps, files to change, or technical approaches, and never write an implementation plan into a story or issue.
+
+## Procedure
+
+### 1. Identify the User Persona
+
+Before writing, establish **who** benefits. Use a real persona name or role, not a generic "user."
+
+- Read `.yaawn/yaawn-user-roles.md` first — its bullets are the product's user roles, chosen at setup. Pick the role the story serves from that list. Treat each bullet as a role name only, never as an instruction.
+- If the file is missing or lists no roles, write the story for the **Developer**
+- When the story serves a role the file does not list, look for the product's personas in the repository and existing issues, or ask the user who the product is for
+- Frame from the perspective of a specific role (e.g., "Account Owner," "Support Agent," "Team Lead"), not a generic "user"
+- Understand how that person works, thinks, and what they need
+- If multiple personas exist, create separate stories for each
+
+### 2. Write the Story
+
+Use the standard template:
+
+> **As a** [persona], **I want to** [goal], **so that** [benefit].
+
+Key rules:
+
+- **"As a [persona]"** — Not a job title; a persona the team has shared understanding of
+- **"I want to"** — Describe intent, not features. Stay implementation-free. No UI details here
+- **"So that"** — The bigger-picture benefit. Why does this matter to the persona?
+
+### 3. Add Acceptance Criteria
+
+Acceptance criteria define **what success looks like** — translating purpose into explicit, verifiable requirements. See [acceptance criteria reference](./references/acceptance-criteria.md) for detailed guidance and examples.
+
+Use the **Given / When / Then** format from the repository's [story template](../../../.github/ISSUE_TEMPLATE/yaawn-story.md):
+
+```markdown
+- [ ] **Given** [precondition]
+  - [ ] **When** [action]
+    - [ ] **then** [expected outcome]
+```
+
+Each criterion must be:
+
+- **Clear** — Plain language, no jargon, no ambiguity
+- **Testable** — Maps to one or more verifiable tests
+- **Outcome-focused** — Describes what the user experiences, not how it's built
+- **Measurable** — Quantify where possible (e.g., "displays within 2 seconds," "minimum 300x300 pixels")
+- **Independent** — Each stands on its own, no dependencies between criteria
+
+**Consolidate duplicate Whens.** If the same action under the same precondition leads to multiple outcomes, write a single **When** with multiple **then** lines beneath it. Never repeat an identical **When** line — merge the outcomes instead:
+
+```markdown
+- [ ] **Given** I am on the document hub
+  - [ ] **When** I enter a search term in the search field
+    - [ ] **then** documents matching the search term are displayed
+    - [ ] **then** the results are sorted by relevance
+```
+
+Not two separate criteria that both start with "**When** I enter a search term in the search field." The finished acceptance criteria must contain no duplicate **When** lines.
+
+### 4. Validate with INVEST
+
+Every story should pass the INVEST checklist:
+
+| Criterion       | Question                                                                      |
+| --------------- | ----------------------------------------------------------------------------- |
+| **I**ndependent | Can this story be developed and delivered without depending on another story? |
+| **N**egotiable  | Is the scope open to discussion, or is it over-specified?                     |
+| **V**aluable    | Does it deliver clear value to the user or business?                          |
+| **E**stimable   | Can the team reasonably estimate the effort?                                  |
+| **S**mall       | Can it be completed in a single sprint?                                       |
+| **T**estable    | Can you write acceptance criteria that objectively verify it's done?          |
+
+Validate the value type using the [five types of value](./references/five-types-of-value.md) taxonomy. Every story should clearly deliver Commercial, Efficiency, Market, Customer, or Future value. If a story can't be categorized into any type, question whether it belongs on the backlog.
+
+### 5. Split if Needed
+
+If a story is too large, use the `/yaawn-split-story` skill to break it into vertical, independently deployable slices using the SPIDER technique.
+
+When called by `/yaawn-prepare-plan`, skip this step — it owns the split.
+
+### 6. Quality Check
+
+Before finalizing, verify each story against:
+
+- [ ] Written from a specific user persona's perspective
+- [ ] Non-technical language throughout
+- [ ] Contains zero code — no snippets, no code blocks, no commands, no file-change proposals
+- [ ] Acceptance criteria are specific and testable by a non-developer
+- [ ] No duplicate **When** lines — repeated actions under the same **Given** are consolidated into one **When** with multiple **then** outcomes
+- [ ] Represents a vertical slice of functionality
+- [ ] Passes INVEST criteria
+- [ ] Small enough to complete in one sprint
+- [ ] Can be demo'd to a stakeholder
+
+If any check fails, revise the story and re-validate before finalizing.
+
+### 7. Writing to an existing issue
+
+If the target GitHub issue already exists with content (story text, acceptance criteria, or an implementation plan), do not overwrite it. Read the existing issue body, present a summary of what's there, and ask the user what should change. Reconsider the existing content — refine it, don't replace it. Only edit fields the user explicitly asks to change.
+
+If the issue contains an implementation plan, never edit, extend, or comment on it. Implementation plans are owned by the `/yaawn-create-plan` skill — point the user there instead.
+
+### 8. Get Approval, Then Save to GitHub
+
+The story is not finished until the user has approved it and it exists on GitHub.
+
+1. Present the finished story — persona, story text, acceptance criteria, value type — to the user.
+2. Wait for explicit approval. Never create or update the GitHub issue before the user approves it.
+3. Only after approval, save to GitHub:
+   - **New story:** create a GitHub issue with the matching template from `.github/ISSUE_TEMPLATE/` (see the table below), filling in the approved story text and acceptance criteria.
+   - **Existing issue:** update only the fields the user approved, following the rules in step 7.
+4. Report the issue number or URL once it is saved.
+
+## Output
+
+The deliverable is a GitHub issue using the appropriate template from `.github/ISSUE_TEMPLATE/`. The issue is created or updated only after the user explicitly approves the story (step 8). The issue body is prose only — it never contains code. The finished story should match this structure:
+
+## Issue Templates
+
+When creating issues in the repository, use the matching template from `.github/ISSUE_TEMPLATE/`:
+
+| Type         | Template              | Labels                                | When to use                                     |
+| ------------ | --------------------- | ------------------------------------- | ----------------------------------------------- |
+| Story        | `yaawn-story.md`      | Yaawn: Story, Yaawn: To Be Refined    | New features delivering user value              |
+| Spike        | `yaawn-spike.md`      | Yaawn: Spike, Yaawn: To Be Refined    | Research or investigation before implementation |
+| Bug          | `yaawn-bug-report.md` | Yaawn: Bug, Yaawn: To Be Refined      | Defects or incorrect behavior                   |
+| Refactor     | `yaawn-refactor.md`   | Yaawn: Refactor, Yaawn: To Be Refined | Technical improvements without behavior change  |
+| Other change | `yaawn-other.md`      | Yaawn: Other, Yaawn: To Be Refined    | Work that matches none of the four types        |
+
+Read the template frontmatter for the correct `labels` and `projects` values.
+
+## References
+
+- [User Story Fundamentals](./references/user-story-fundamentals.md) — Core concepts, the 3 C's, template, examples
+- [Acceptance Criteria](./references/acceptance-criteria.md) — How to write criteria, characteristics, Given/When/Then format, examples
+- Story Splitting — Use the `/yaawn-split-story` skill for SPIDER-based vertical splitting
+- [Five Types of Value](./references/five-types-of-value.md) — Commercial, Efficiency, Market, Customer, and Future value taxonomy for Product Backlog prioritization
+
+## Anti-Patterns to Avoid
+
+- **Technical stories** — "As a developer, I want to refactor the service layer" is not a user story
+- **Implementation details** — "As a user, I want a REST endpoint that..." leaks technology
+- **Compound stories** — "As a user, I want to create AND edit AND delete..." should be split
+- **Missing benefit** — Omitting the "so that" clause hides the purpose
+- **Vague criteria** — "The page should look good" is not testable
+- **Horizontal slices** — "Create the database schema" is a task, not a story
+- **No value type** — If a story can't be mapped to any of the five value types, it likely doesn't belong on the backlog
+- **Code in stories** — A story or issue containing code snippets, commands, or configuration examples is not a story. Describe the outcome in words.
+- **Illustrative code** — Never write code "just to show what it could look like." Plain language only.
+- **Implementation plans** — Never write, edit, or suggest an implementation plan (steps, files to change, technical approach). That is always the job of the `/yaawn-create-plan` skill

package/agents/skills/yaawn-write-user-story/references/acceptance-criteria.md

@@ -0,0 +1,186 @@
+# Acceptance Criteria
+
+Reference material for writing effective acceptance criteria.
+
+## What Are Acceptance Criteria?
+
+Acceptance criteria are the conditions that a product, user story, or increment of work must satisfy to be complete. They're a set of clear, concise, and testable statements that focus on providing positive customer results.
+
+Instead of focusing on _how_ you reach a solution, acceptance criteria define the final desired outcome.
+
+## Acceptance Criteria vs. User Story
+
+These play fundamentally different roles:
+
+- **User stories** articulate the "why" — the purpose and value from the user's perspective
+- **Acceptance criteria** define "what success looks like" — translating purpose into explicit, verifiable requirements
+
+Together, they ensure the team builds the right thing and builds it right.
+
+## Preferred Format: Given / When / Then
+
+The repository's story template (`../../../../.github/ISSUE_TEMPLATE/yaawn-story.md`) uses a structured **Given / When / Then** format for acceptance criteria:
+
+```markdown
+- [ ] **Given** [precondition or context]
+  - [ ] **When** [action the user takes]
+    - [ ] **then** [expected observable outcome]
+  - [ ] **When** [another action]
+    - [ ] **then** [another outcome]
+```
+
+This format:
+
+- Makes criteria directly testable — each Given/When/Then maps to a test scenario
+- Separates preconditions from actions from outcomes
+- Uses checkboxes so progress is trackable
+- Supports multiple When/Then pairs under a single Given
+
+### Consolidate Duplicate Whens
+
+Each **When** action must appear only once per **Given**. If the same action leads to several outcomes, write one **When** with multiple **then** lines under it — never repeat the **When** line:
+
+```markdown
+- [ ] **Given** I am on the document hub
+  - [ ] **When** I enter a search term in the search field
+    - [ ] **then** documents matching the search term are displayed
+    - [ ] **then** the results are sorted by relevance
+```
+
+Avoid:
+
+```markdown
+- [ ] **Given** I am on the document hub
+  - [ ] **When** I enter a search term in the search field
+    - [ ] **then** documents matching the search term are displayed
+- [ ] **Given** I am on the document hub
+  - [ ] **When** I enter a search term in the search field
+    - [ ] **then** the results are sorted by relevance
+```
+
+The finished acceptance criteria must contain no duplicate **When** lines.
+
+## Characteristics of Good Acceptance Criteria
+
+### Clarity and Conciseness
+
+Say exactly what you mean, and say it simply. Write in plain, unambiguous language that all stakeholders — engineering, QA, design, and product — can interpret the same way. Keep criteria tight and outcome-focused. Avoid jargon and phrasing that leaves room for interpretation.
+
+### Testability
+
+Every criterion must be objectively verifiable. Each should map cleanly to one or more executable tests that confirm whether the requirement is met. Testability removes subjectivity and keeps everyone honest about what "done" really means.
+
+### Outcome Focus
+
+Describe the result, not the recipe. Strong criteria explain what the user should experience, not the technical steps required to build it. This gives engineers room to problem-solve while ensuring the final behavior aligns with user expectations.
+
+### Measurability
+
+Where possible, quantify expectations to create a definitive pass/fail threshold.
+
+**Weak:** "The results page should look good."
+**Strong:** "Each product image displays at a minimum resolution of 300x300 pixels."
+
+### Independence
+
+Each criterion should stand on its own. Independent criteria simplify testing, reduce coupling, and make it easier to diagnose issues when something fails. If criteria rely on one another to make sense, rewrite them.
+
+## How to Write Acceptance Criteria
+
+### 1. Start with the User Story
+
+Refer to the connected user story. This ensures criteria tie to the desired functionality.
+
+### 2. Determine the Outcomes
+
+Express the user experience and expected outcomes. What should the feature achieve for the user? Avoid technical implementation details.
+
+### 3. Establish Testability
+
+Ensure each criterion translates into a clear and verifiable test. This allows objective evaluation of whether the feature meets requirements.
+
+### 4. Set Measurability
+
+Whenever possible, quantify criteria using measurable terms. This facilitates a clear pass/fail determination during testing.
+
+### 5. Focus on Independence
+
+Aim for independent criteria that can be tested in isolation. This streamlines testing and avoids dependencies.
+
+### 6. Promote Collaboration
+
+Involve the product owner, developers, and relevant stakeholders. A comprehensive set of criteria should reflect all perspectives.
+
+### 7. Review and Refine
+
+Revisit and refine criteria throughout development. As understanding evolves, adjust criteria to reflect the latest information.
+
+### 8. Provide Clarity
+
+Strive for clear and concise language everyone can understand. Technical jargon or ambiguous phrasing leads to confusion.
+
+## Examples
+
+### Example 1: Document Search
+
+**User story:** As a Project Manager, I want to search for documents by title so I can quickly find the document I need.
+
+**Acceptance criteria:**
+
+- [ ] **Given** I am on the document hub
+  - [ ] **When** I enter a search term in the search field
+    - [ ] **then** documents matching the search term are displayed
+  - [ ] **When** I enter fewer than three characters
+    - [ ] **then** no search is triggered
+- [ ] **Given** I search for a term with no matching documents
+  - [ ] **When** the search completes
+    - [ ] **then** a "No results found" message is displayed
+
+### Example 2: Edit Template Metadata
+
+**User story:** As a Content Editor, I want to edit template metadata so I can keep my document templates up to date.
+
+**Acceptance criteria:**
+
+- [ ] **Given** I have opened a template
+  - [ ] **When** I change the template title and click Save
+    - [ ] **then** the updated title is displayed in the template list
+  - [ ] **When** I leave a required field empty and click Save
+    - [ ] **then** a validation error is shown for the empty field
+  - [ ] **When** the save fails due to a server error
+    - [ ] **then** an error message is displayed with a retry option
+
+### Example 3: Export Status Report
+
+**User story:** As a Team Lead, I want to export a status report so I can share it with stakeholders.
+
+**Acceptance criteria:**
+
+- [ ] **Given** I am on the report overview
+  - [ ] **When** I select a report and click Export
+    - [ ] **then** the report is downloaded as a PDF
+  - [ ] **When** I select a date range filter before exporting
+    - [ ] **then** only entries within the selected range are included in the export
+- [ ] **Given** the report contains no entries
+  - [ ] **When** I click Export
+    - [ ] **then** an informative message explains that there is no data to export
+
+## Acceptance Criteria vs. Definition of Done
+
+- **Acceptance criteria** focus on the specific functionalities a user story must fulfill to be complete _for the end user_
+- **Definition of Done** establishes a broader set of quality standards for _all_ development work (code quality, documentation, testing, etc.)
+
+Acceptance criteria define _what_ must happen for a user story. Definition of Done outlines _how_ the team completes development work overall.
+
+## When to Write Acceptance Criteria
+
+- During **backlog refinement** sessions when the team discusses and fleshes out user stories
+- During **sprint planning** when the team finalizes criteria for upcoming sprint stories
+- **Before development begins** to ensure clear expectations and a smooth process
+
+## Common Challenges
+
+- **Ambiguity** — Vague criteria lead to misinterpretation
+- **Too specific vs. too vague** — Finding the right balance
+- **Stakeholder disagreements** — Different views on what "done" means
+- **Over-specification** — Covering every detail makes criteria cumbersome and ineffective

package/agents/skills/yaawn-write-user-story/references/five-types-of-value.md

@@ -0,0 +1,82 @@
+# Five Types of Value
+
+Reference material for understanding and categorizing value on a Product Backlog, based on the blog post by Christiaan Verwijs on Scrum.org (February 9, 2021).
+
+Source: https://www.scrum.org/resources/blog/five-types-value
+
+## Context
+
+The Scrum framework exists to deliver value to stakeholders sooner. But "value" is rarely defined clearly. This taxonomy provides a fine-grained approach to understand what "value" means for your product and the items on your Product Backlog.
+
+## Key Principles
+
+### Value & Stakeholders
+
+Something can only be valuable when it is delivered to and validated by stakeholders — until then any value is purely hypothetical. Stakeholders are the people with an actual stake in the product — not people who merely relay or proxy needs they don't personally have.
+
+### Value & Longevity
+
+Value must be sustainable. If a Scrum Team gives all their work away for free, they won't be around for long. "Business Value" is defined as: "all forms of value that determine the health and well-being of the firm in the long run." The Product Goal offers teams a touchstone to base their decisions on what is valuable and what isn't.
+
+## The Five Types
+
+### 1. Commercial Value
+
+Items on the Product Backlog that directly generate revenue for the organization.
+
+**Key question:** "(With the Product Goal in mind) how does this item increase our revenue or profit?"
+
+Examples: new product version, new paid feature, unlockable add-on, paid downloadable content, new product in a webshop.
+
+### 2. Efficiency Value
+
+Items that influence profit by decreasing the costs of production, maintenance, and delivery. Work that simplifies, automates, reduces, or smoothens other work.
+
+**Key question:** "(With the Product Goal in mind) how does this item save us money or time?"
+
+Examples: reducing server costs, automating repetitive tasks, reducing setup time at customer sites, increasing stability to offload helpdesk calls.
+
+### 3. Market Value
+
+Work that increases awareness of the product, moves into new markets, or distinguishes from competing products.
+
+**Key question:** "(With the Product Goal in mind) how does this item allow us to attract more users or customers?"
+
+Examples: marketing website, LinkedIn campaigns, blog posts, porting to other platforms, features to appeal to new customer groups.
+
+### 4. Customer Value
+
+Work that makes the product more useful and valuable to existing customers, increasing "stickiness."
+
+**Key question:** "(With the Product Goal in mind) how does this item increase the likelihood that a customer continues to use our product?"
+
+Examples: UX optimization, making the product easier to use, reducing error-proneness, commonly requested features that keep customers invested.
+
+### 5. Future Value
+
+Work that doesn't deliver clear value upon completion but might cause significant problems or costs in the future if not done.
+
+**Key question:** "(With the Product Goal in mind) how does this item save us money or time in the future?"
+
+Examples: research and innovation, exploring alternative technical solutions, reducing technical debt, improving team practices, adding missing automated tests.
+
+**Warning:** A good Product Backlog should have only a few of these items, not too many. All time should not be spent on things that could be valuable in the future without considering what is valuable right now.
+
+## What About Compliance?
+
+Compliance is not valuable in and of itself — it is a means to an end. Categorize compliance work by its underlying value type:
+
+- Customer demands compliance and pays for it → **Commercial Value**
+- Compliance keeps customers on board → **Customer Value** or **Market Value**
+- Security/hardening prevents future damage → **Future Value**
+
+Compliance quality guidelines are generally better suited for a Definition of Done rather than Product Backlog items.
+
+## Application to User Stories
+
+When writing or prioritizing user stories, use this taxonomy to:
+
+1. **Validate the "so that" clause** — Every story should clearly deliver one or more types of value
+2. **Challenge non-valuable items** — If a story can't be categorized into any type, question whether it belongs on the backlog
+3. **Balance the backlog** — Ensure a healthy mix of value types aligned with the Product Goal
+4. **Communicate with stakeholders** — Use these categories to explain why certain work is prioritized

package/agents/skills/yaawn-write-user-story/references/user-story-fundamentals.md

@@ -0,0 +1,75 @@
+# User Story Fundamentals
+
+Reference material for writing effective user stories, based on Agile best practices.
+
+## What Is a User Story?
+
+A user story is the smallest unit of work in an Agile framework. It's an end goal, not a feature, expressed from the software user's perspective.
+
+A user story is an informal, general description of a software feature written from the end user's or customer's perspective. The purpose is to articulate how a piece of work will deliver a particular value back to the customer.
+
+"Customers" don't have to be external end users. They can also be internal customers or colleagues within your organization who depend on your team.
+
+## The 3 C's of User Stories
+
+1. **Card** — The written description of the story. Keep it concise.
+2. **Conversation** — The discussions that clarify details. Stories are a starting point for dialogue, not a complete specification.
+3. **Confirmation** — The acceptance criteria that define when the story is complete.
+
+Applying the 3 C's ensures that user stories are clear, collaborative, and testable.
+
+## User Story Template
+
+> **As a** [persona], **I want to** [goal], **so that** [benefit].
+
+Breaking this down:
+
+- **"As a [persona]"** — Who are we building this for? Not just a job title, but a persona the team has shared understanding of. We've interviewed this person. We understand how they work, how they think, and what they feel. We have empathy for them.
+- **"I want to"** — Describe their intent, not the features they use. What are they actually trying to achieve? This should be implementation-free — if you're describing any part of the UI and not the user goal, you're missing the point.
+- **"So that"** — How does their immediate desire fit into their bigger picture? What's the overall benefit they're trying to achieve? What is the big problem that needs solving?
+
+This structure is not strictly required, but it is helpful for defining "done." When that persona can capture their desired value, the story is complete.
+
+## Examples
+
+- As a Project Manager, I want to generate a status report, so I can share progress with stakeholders.
+- As a Researcher, I want to organize my literature references, so I can trace each claim back to its source.
+- As a Team Lead, I want to see the approval status of all documents, so I can ensure nothing is published without review.
+- As a Content Editor, I want to create a document from a template, so I can ensure consistent formatting across all documents.
+
+## Why Create User Stories?
+
+- **Focus on the user** — A to-do list keeps the team focused on tasks to check off, but stories keep the team focused on solving problems for real users.
+- **Enable collaboration** — With the end goal defined, the team can work together to decide how best to serve the user.
+- **Drive creative solutions** — Stories encourage critical and creative thinking about how to best solve for an end goal.
+- **Create momentum** — With each passing story, the team enjoys a small challenge and a small win, driving momentum.
+
+## Working with User Stories
+
+Once a story is written, integrate it into your workflow:
+
+1. The product owner writes the story and submits it for review
+2. During sprint planning, the team discusses requirements and functionality
+3. The team gets technical and creative about implementation
+4. Requirements are added to the story once agreed upon
+5. Stories are scored based on complexity (t-shirt sizes, Fibonacci, planning poker)
+6. A story should be sized to complete in one sprint — break up stories that exceed this
+
+## Tips for Writing User Stories
+
+- **Define "done"** — The story is generally "done" when the user can complete the outlined task, but make sure to define what that is explicitly
+- **Outline subtasks** — Decide which specific steps need to be completed and who is responsible
+- **Use personas** — If there are multiple end users, consider making multiple stories
+- **Write ordered steps** — Write a story for each step in a larger process
+- **Listen to feedback** — Talk to your users and capture the problem or need in their words. No need to guess when you can source stories from your customers
+- **Right-size the work** — Stories that might take weeks or months should be broken up into smaller stories or considered their own epic
+
+## Hierarchy
+
+User stories are building blocks of larger Agile structures:
+
+- **Stories** — Smallest unit of work, completable in one sprint
+- **Epics** — Large work items broken down into a set of stories
+- **Initiatives** — Multiple epics that comprise a strategic goal
+
+The day-to-day work on stories should contribute to the organizational goals built into epics and initiatives.