Managing a Body of Work¶
From One Story to Many¶
In Lift 1, you learned to write user stories with acceptance criteria — delegation contracts that define "done" before you start. That works for individual features. But look at everything you want to build.
Your Avalanche Observation Network isn't one feature — it's a platform. An observation submission form. A feed with filtering. A map view. A statistics dashboard. Red flag alerts. Observation type-specific forms. Zone-based filtering for forecasters. Export tools. Each of those is a feature. Some of those features are multiple stories.
When the work is bigger than a single story, you need a way to break it down into pieces you can actually delegate and track.
Right-Sizing: Match Your Approach to the Task¶
In Lift 1, you learned the Three Pillars and user stories. But not every task needs a full story, and some tasks are too big for a single story. Here's the spectrum:
| Complexity | Strategy | When to Use |
|---|---|---|
| Low | Plain English | One-line changes, obvious fixes, small tweaks. "Change the submit button text from 'Send' to 'Submit Observation'." |
| Medium | Story Format | Features with multiple parts. This is your default — the delegation contract from Lift 1. |
| High | Decomposition | Big features, unclear scope. Break it into story-sized pieces first, then delegate each piece. |
Story format is your default — not your only tool. Scale down when a story would take longer to write than the change takes to make. Scale up when the problem is too big for one story.
The Signal to Decompose¶
How do you know a feature is too big? Watch for these symptoms:
- Acceptance criteria keep growing as you think of more cases
- You can't clearly define what "done" looks like — the scope keeps shifting
- The feature serves multiple user personas with different needs (backcountry skiers AND forecasters)
- You're combining multiple user goals into one story
When you see these signals, don't try to write a bigger, more detailed story. Decompose — break the feature into smaller, independently shippable pieces.
Independently Shippable Pieces¶
The key word is independently. Each piece must deliver value on its own. Piece 2 might build on Piece 1, but Piece 1 must be useful by itself.
Before decomposition (too big):
As a forecaster, I want a complete observation management system so that I can review all field data efficiently.
Acceptance criteria: browse observations, filter by zone, filter by type, filter by date, view detail, see statistics, flag important observations, export data, search by keyword...
The acceptance criteria keep growing. This isn't one story — it's a whole backlog.
After decomposition (independently shippable):
Piece 1 — Observation Feed: As a forecaster, I want to browse recent observations in reverse chronological order so that I can see what's been reported today. Delivers value on its own: forecasters can see what's been submitted.
Piece 2 — Zone Filtering: As a forecaster, I want to filter observations by zone so that I can focus on the area I'm forecasting for. Delivers value on its own: adds efficiency to the existing feed.
Piece 3 — Detail View: As a forecaster, I want to click an observation and see its full details so that I can assess whether to include it in my forecast. Delivers value on its own: enables deeper analysis of individual reports.
Notice: each piece would have 2-4 acceptance criteria. Each delivers value. Each can be delegated as a standalone story. Decomposition doesn't replace story format — it gets you back to story format when the problem is too big.
Team Activity: Decompose Your Backlog¶
Format: Mob Session Time: ~4 minutes Setup: One person drives, everyone else navigates. Do this in the same workspace where you built your Run 1 project — AI can look at what you've already built to give you a more grounded decomposition.
Take your Avalanche Observation Network and map out the full scope. Then decompose it into delegatable pieces.
Step 1: Ask your AI coding assistant:
Look at our observation network project. We want to build a full-featured platform where backcountry skiers submit field observations and avalanche forecasters review them to inform daily danger forecasts. Brainstorm the full feature set — everything we might want to build. Group features by user persona: backcountry skier (submitter) vs. avalanche forecaster (consumer).
Step 2: Pick the feature group that feels most overwhelming — the one where "done" is hardest to define.
Step 3: Ask AI to decompose it:
Break [that feature group] into independently shippable pieces. Each piece should deliver value on its own and be small enough for one user story with 2-4 acceptance criteria. Order them so the first piece is the smallest thing that still delivers real value.
Step 4: Review the decomposition together. For each piece, ask: "Could we ship this alone and have it be useful?" If not, it needs to be broken down further.
Discuss: How does this compare to how you approached Run 1? Where did you try to tackle too much in one go? How would having this decomposed backlog change how you delegate?
Key Insight¶
When acceptance criteria keep growing, that's not a sign you need a more detailed story — it's a sign you need to decompose. Break big goals into independently shippable pieces, each with its own story and tight acceptance criteria. That's how you go from "build the observation platform" to a managed body of work you can delegate piece by piece.