Managing a Body of Work¶
From One Story to Many¶
In Lesson 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 application isn't one feature. Think about everything it needs to do: different screens, different user workflows, different data to manage. 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 Lesson 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 header text from 'Welcome' to 'Welcome back'." |
| Medium | Story Format | Features with multiple parts. This is your default - the delegation contract from Lesson 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 because the scope keeps shifting
- The feature serves multiple user personas with different needs
- 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 an ONI watch floor analyst, I want a complete sanctions screening system so that I can identify and investigate all sanctioned vessels in my area of interest.
Acceptance criteria: display all vessels, match against OFAC, flag matches, show vessel details, filter by region, detect name mismatches, show gap history, score risk, highlight anomalies, export watchlist...
The acceptance criteria keep growing. This isn't one story. It's a whole backlog.
After decomposition (independently shippable):
Piece 1 - Sanctions Matching: As an ONI watch floor analyst, I want every vessel's MMSI automatically checked against the OFAC sanctions list so that I can see which vessels in my area are sanctioned without looking them up manually. Delivers value on its own: the analyst sees sanctions flags on the traffic display.
Piece 2 - Vessel Profile: As an ONI watch floor analyst, I want to select a flagged vessel and see its full identity, OFAC entry, and all known identifiers so that I can assess whether the match is current and relevant. Delivers value on its own: turns a flag into actionable information.
Piece 3 - Name Mismatch Detection: As an ONI watch floor analyst, I want to see when a vessel's broadcast name differs from its OFAC-listed name so that I can identify vessels that changed their identity after being sanctioned. Delivers value on its own: catches an evasion tactic that a simple MMSI match would miss.
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.
Decompose Your Backlog
Mob Session | ~4 minutes total | One person drives, everyone else navigates. Do this in the same workspace as your Challenge 1 project.
Rotate the driver. Pick someone who hasn't been at the keyboard recently.
Take your application and map out the full scope. Then decompose it into delegatable pieces.
Step 1: Ask your AI coding assistant:
Look at our Dark Vessel Risk Assessment Tool project. We want to
build a tool where an ONI analyst can:
- See all vessel traffic in their area of interest
- Identify which vessels are on the OFAC sanctions list
- Investigate individual vessels in detail
- Detect signs of sanctions evasion (name changes, identity manipulation)
Brainstorm the full feature set, everything we might want to build.
Group features by analytical capability:
- Traffic awareness (seeing what's out there)
- Sanctions screening (identifying known bad actors)
- Investigative tools (drilling into a vessel's full record)
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
- 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 Challenge 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 whole thing" to a managed body of work you can delegate piece by piece.