Imported from msewell/agent-stuff (skills/slicing-pbis/SKILL.md). Install upstream with npx skills add msewell/agent-stuff --skill slicing-pbis. Copyright stays with the author.

Slicing Product Backlog Items

Determine the task

Quality characteristics (priority order)

Apply these in order — when they conflict, higher-ranked characteristics take precedence.

When characteristics conflict: prefer value over smallness, independence over smallness, completability over negotiability. Stop splitting when further division would break a higher-ranked characteristic.

The splitting meta-pattern

All splitting techniques follow one pattern:

1. Find the core complexity. What part is most likely to surprise the team? (Human preferences, external integrations, variable business rules.)
2. Identify the variations. What are there many of? (User roles, business rules, data formats, workflow paths, edge cases, platforms.)
3. Reduce all variations to one. Find a single, complete path through the complex part → this is the first slice. Each subsequent slice reintroduces one variation.

This produces vertical slices by default — reducing to a single variation through the core complexity naturally cuts across all system layers.

Splitting patterns (quick reference)

Pick based on the dominant source of variation:

For detailed examples of each pattern, see references/02-hierarchy-and-slicing.md.

Workflow: Splitting a PBI

1. Run the "Should this PBI be split?" checklist (Checklist B in references/03-sizing-dependencies-antipatterns.md) to confirm splitting is needed.
2. Apply the meta-pattern: find core complexity → identify variations → reduce to one.
3. Choose the splitting pattern matching the dominant variation type.
4. For each resulting slice, validate against the quality characteristics table above.
5. Verify each slice is vertically sliced — it cuts through all necessary system layers, not just one.
6. Write 1–3 binary, behavior-focused acceptance criteria per slice.
7. Check: the first slice carries the most value and risk. Low-value slices are clearly deprioritizable.
8. If any slice fails validation at steps 4–6, re-split it by returning to step 2.

Guard rails:

• Every slice must deliver observable stakeholder value. A slice that looks like a developer task fails.
• A PBI should represent ≤ 1/5 to 1/10 of sprint capacity.
• 4+ acceptance criteria on a single slice means split further.
• The first slice is the thinnest possible end-to-end happy path — do not gold-plate it.

Workflow: Reviewing PBIs

1. For each PBI, run the well-formedness checklist (Checklist A in references/03-sizing-dependencies-antipatterns.md).
2. Run the splitting checklist (Checklist B) to identify split candidates.
3. Check for common anti-patterns — see Anti-Patterns in references/03-sizing-dependencies-antipatterns.md.
4. For PBIs approaching sprint readiness, run the sprint-readiness checklist (Checklist C).
5. For each issue found, propose a specific fix with a rewritten PBI.

Common anti-patterns to flag: horizontal slicing, tasks disguised as stories, over-splitting, premature splitting, gold-plating the first slice, confusing epics with categories.

Workflow: Writing new PBIs

1. Start from the stakeholder problem — not the solution.
2. Write the PBI description covering: Problem, Proposed Solution, Expected Impact, and Acceptance Criteria. Add Timelines and Dependencies only when applicable. For description format details, see references/01-quality-and-description.md.
3. Slice vertically — every PBI cuts through all system layers needed to deliver one complete scenario.
4. Write 1–3 binary, independently verifiable, behavior-focused acceptance criteria per PBI.
5. Validate each PBI against the quality characteristics table above.
6. If the PBI is too large (fails Commensurate or Small), apply the splitting workflow above.

Acceptance criteria rules:

• Binary pass/fail. No partial credit.
• Independently verifiable. Each criterion stands alone.
• Behavior-focused. Describe what the system does, not how it is built.
• 1–3 per PBI. More than 3 signals the PBI should be split.

Edge cases

• Technical work without direct stakeholder value (e.g., infrastructure migration): Write as a task with clear problem/solution/impact. Do not force it into a user-story format. It may belong as a sub-item under a value-delivering PBI.
• Unavoidable dependencies: Make them explicit. Prefer eliminating by restructuring > merging > decoupling with interfaces > stubbing > sequencing explicitly. See references/03-sizing-dependencies-antipatterns.md.
• High uncertainty: Split into a time-boxed spike (research) + subsequent implementation item. The spike produces knowledge, not production code.
• Epics: Use for outcome-oriented grouping with a clear completion condition. Not permanent categories. "Reduce page load time below 2s" is an epic; "Performance" is a label.

Reference material

• Quality characteristics and description format: references/01-quality-and-description.md — the six characteristics in detail, conflict resolution, acceptance criteria guidance, three amigos
• Hierarchy, vertical slicing, and splitting techniques: references/02-hierarchy-and-slicing.md — epic/work-item/sub-item hierarchy, vertical vs. horizontal slicing, all splitting patterns with examples
• Sizing, dependencies, anti-patterns, and checklists: references/03-sizing-dependencies-antipatterns.md — commensurate sizing, throughput forecasting, dependency strategies, seven anti-patterns, three refinement checklists