slicing-pbis

name	slicing-pbis
description	Slices, reviews, and writes product backlog items (PBIs) using priority-ordered quality characteristics (Valuable > Completable > Negotiable > Independent > Commensurate > Small), vertical slicing, and the splitting meta-pattern. Produces well-formed, commensurately sized PBIs with binary acceptance criteria. Use when splitting large PBIs or user stories, reviewing backlog items for quality, writing new PBIs from requirements, refining a product backlog, decomposing epics into stories, or when the user mentions PBI slicing, story splitting, backlog refinement, or vertical slices.
category	Software Engineering

Slicing Product Backlog Items

Determine the task

Task	Workflow
Splitting a large PBI into smaller ones	→ Splitting workflow
Reviewing existing PBIs for quality	→ Review workflow
Writing new PBIs from requirements	→ Writing workflow

Quality characteristics (priority order)

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

#	Characteristic	Test
1	Valuable	Can a stakeholder observe the value this delivers?
2	Completable	Is there a binary pass/fail condition for "done"?
3	Negotiable	Is the implementation approach open for the team to adjust?
4	Independent	Can this PBI be released without waiting for another?
5	Commensurate	Is this PBI roughly the same size as the others in the backlog?
6	Small	Can this be completed within a single sprint?

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:

Pattern	When to use	First slice delivers
Workflow steps	Multi-step process	Beginning and end steps (most value and risk)
Business rules	Behavior branches on conditions	Most common or highest-value rule
Data variations	Multiple data types or formats	Highest-traffic variation
User role	Different user groups, different needs	Highest-value role
Interface/platform	Multiple platforms	Highest-traffic interface
Happy path / edge cases	Complex error handling	Happy path only
CRUD operations	Full lifecycle management	Read or create (whichever unlocks more)
Major / minor effort	One large core + incremental add-ons	The major integration effort
Spike / implementation	Uncertainty is the blocker	Time-boxed spike (research, not code)

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