Key takeaways
- Slice through interface, behaviour and storage rather than finishing one layer at a time.
- One demonstration sentence is a stronger scope test than a feature count.
- Exclusions need a reason and a revisit trigger.
- Count states and failure paths, not screens.
“Build a request organiser” sounds small until its nouns begin multiplying: people, groups, labels, attachments, reminders, permissions and search. The cure is not an arbitrary deadline. It is one vertical slice that produces evidence from end to end.
A vertical slice crosses the visible interface, behaviour rules and durable storage. By contrast, “finish the datastore first” builds a horizontal layer. Horizontal work can feel busy while leaving the central question unanswered: can a person complete anything useful?
Replace the idea with a demonstration sentence
Take the vague request organiser. Ask four questions: Who acts? What do they do? What changes durably? What can they observe afterwards? A usable answer is: “A visitor records a maintenance request with a short subject, closes the browser application, returns and sees that request marked as awaiting attention.”
That sentence cuts surprisingly hard. It requires creation and persistence. It does not require accounts, assignment, photographs, reminders, comments or resolution history. Nor does it require an elaborate dashboard. One form and one list may be enough.
Try to demonstrate the sentence with invented data: subject “Loose cupboard hinge”, detail “Upper left door”, state “awaiting attention”. If the demonstration depends on an unwritten action, add it to the path. If a field has no effect on the result, remove it for now.
Trace the thinnest honest path
Write the path as observable moments, not implementation jobs. The visitor opens an empty list. They choose “new request”. They enter a subject and optional detail. They confirm. The list shows one item. After reopening, the same item remains. Six moments. Done.
Now attach one rule to each risky moment. A blank subject is rejected before storage. Confirmation cannot create two records from one valid attempt. The list distinguishes empty from unavailable. Reopening reads the stored record. These rules are part of the slice because without them the demonstration can lie.
Do not add editing merely because a list item looks editable. If a mistaken subject is acceptable for a first rehearsal, deletion and editing can wait. That trade-off would be wrong where errors carry material consequences, but it is plausible for a throwaway learning project.
The exclusion ledger
A plain “later” list decays. Give each excluded item a reason and a trigger for reconsideration. This keeps the boundary defensible while preserving thought. Here is the original asset for this note.
| Not in first release | Why excluded now | Revisit when |
|---|---|---|
| User accounts | They add identity, recovery and access rules without proving request persistence. | Records must be private or owned. |
| Attachments | They add file validation, storage limits and deletion duties. | Text cannot describe common requests. |
| Assignment | It introduces staff identities and another state path. | More than one person handles work. |
| Reminders | They require time-based work and a delivery dependency. | Ageing requests become hard to spot. |
| Search | A six-item list is already inspectable. | The representative dataset exceeds 40 items. |
| Editing | It needs history or overwrite rules. | Input mistakes make the slice unusable. |
The threshold of 40 is an assumption, not a fact. It says when this project will reassess browsing effort. A different layout, item length or device could move that number. Visible assumptions beat false precision.
Use a scope pressure test
Before work begins, ask: can every included behaviour be shown in the demonstration? Does every field affect that behaviour? How many stored states exist? Which failures need separate user treatment? What happens if the same action repeats? A “tiny” slice with twelve states and uncertain retries is not tiny.
Then compare the cut with the six-pass release framework. Data and state usually expose hidden width. The state-modelling note is the useful next stop when labels such as “new”, “open” and “done” begin to blur.
Honest limitation
Vertical slicing is a planning device, not an excuse to omit safeguards. It is inadequate on its own for safety-critical, regulated, medical, financial, real-time, high-scale or security-critical systems. In those settings, required controls may legitimately span beyond one user-visible path and need specialist review.