doughnut: Skill for Codex

Prepare a Product Backlog for LeSS in Action

Keep two outputs separate:

1. A facilitation analysis containing facts, criteria, trade-offs, ordering, dependencies, risks, and class sizing.
2. A clean Product Backlog artifact containing only user stories and their acceptance examples.

Do not put selection criteria, training rationale, evaluation tables, team assignments, process notes, or research summaries in the Product Backlog artifact.

Participants should encounter requirements discovery, Specification by Example, ATDD, TDD, pairing, continuous integration, refactoring, emergent design, shared ownership, and cross-team coordination through the work itself. Do not add training-only behavior or contrive architectural work merely to exercise a technology.

<feature_criteria> Select a feature set that:

1. Delivers authentic value to real users.
2. Is interesting, visible, demonstrable, and suitable for participant dogfooding.
3. Contains slightly more work than the class can finish, while leaving a useful and safe product if only the core is completed.
4. Has an accessible domain with common-sense entry points and enough depth to require genuine domain learning.
5. Has moderate technical difficulty: meaningful design and integration work without depending on specialist research.
6. Crosses multiple technical seams across the backlog, such as user interface or CLI, application APIs, persistence, formats, external systems, and tests.
7. Supports vertical, interdependent Product Backlog Items rather than frontend, backend, database, or infrastructure work packages.
8. Meets production expectations for data integrity, failure handling, security, observability, and maintainability.
9. Creates strategic leverage without making speculative future technology a prerequisite for current user value.
10. Prefers high user value per unit of effort and reuses established platform mechanisms where appropriate.
11. Can be developed and tested in the class environment and CI without fragile shared credentials or unavailable external services. </feature_criteria>

<item_criteria> Require each Product Backlog Item to:

1. Name a user, an observable outcome, and why the outcome matters.
2. Deliver one coherent end-to-end behavior that can be demonstrated.
3. Be a vertical slice, not an internal component or architectural layer.
4. Normally fit within roughly half to one-and-a-half team days; split an item likely to exceed two team days before Sprint Planning.
5. Include concrete acceptance examples for the normal case, a no-change case where relevant, and at least one failure, boundary, or conflict case.
6. Leave the product useful and safe even if later items are never completed.
7. Expose real product dependencies without assigning permanent component ownership to a team.
8. Express behavior and constraints without prescribing implementation unnecessarily.
9. Address credentials, partial failure, concurrency, deletion, and recovery wherever relevant.
10. Be testable through automation at the cheapest appropriate level.
11. Encourage shared code ownership and feature-team collaboration.
12. Avoid shortcuts or code that would be unacceptable outside the class. </item_criteria>

Treat capacity as a hypothesis. Aim for a stop-safe core plus pull-forward work, not a promise that every item will be completed.