Chapter 4: Work Routing
Every piece of work in the Jetty Method starts the same way: classification. Before you plan anything, before you write any code, you identify what kind of work you're dealing with. That classification determines which workflow you follow. This might seem like overhead. You have an idea. You want to build it. Why not just start? Because the most common mistake in AI-assisted development is treating all work the same way. You describe what you want, the AI builds something, you hope it works. Meanwhile, a bug requires investigation before you can fix it properly. A feature requires design exploration because there's more than one valid approach. A small tweak requires neither. Treating a bug like a feature wastes time on unnecessary processes. Treating a feature like a small tweak leads to fragile implementations that miss edge cases. Classification prevents both failure modes. It ensures work gets the treatment it actually needs.
The Five Work Types
Epics are large initiatives that span multiple pieces of work. "Build an authentication system" is an epic. "Add a reporting dashboard" is an epic. You can't build an epic directly. You have to break it down into smaller pieces first: features, chores, or both.
Some epics are purely technical: "Migrate the codebase from CommonJS to ESM" or "Refactor authentication across all modules." These technical epics produce chores directly rather than features, since there's no user-facing design to explore.
Features are new user-facing capabilities where design choices matter. "Add drag-and-drop reordering for cards" is a feature. "Implement user notifications" is a feature. The key signal: there's more than one valid way to build it, and the user experience differs depending on which approach you choose.
Features require the most structured workflow. You explore different UX approaches before committing. You write BDD scenarios before implementation. You progress through modes (speed, stable, production) because features add new behavior that needs to be built correctly, then hardened.
Chores are technical tasks where the implementation is obvious. Refactoring code to a new pattern. Updating a dependency. Cleaning up unused files. Improving build tooling. There's no UX to explore because users never see this work directly. The approach is clear. You just need to do it carefully.
Chores come in four flavors: refactors (restructure without changing behavior), dependency updates (upgrade packages safely), cleanup (remove unused code), and tooling (improve build or development processes). Each has slightly different verification criteria, which we'll cover in later chapters.
Bugs are things that are broken. The software was supposed to work a certain way, and it doesn't. "The login button doesn't respond on mobile" is a bug. "Users see a 500 error when saving" is a bug.
Bugs require investigation before implementation. You need to understand why something is broken before you can fix it properly. Otherwise you risk fixing a symptom while the root cause remains, waiting to resurface. The bug workflow has you capture symptoms, form hypotheses, gather evidence, and confirm the root cause before writing any fix.
Simple improvements are atomic changes where the implementation is so obvious that planning would be pure overhead. Changing button text from "Submit" to "Save." Updating a color. Fixing a typo. The scope is tiny, there are no edge cases to consider, and the happy path is the entire implementation.
Simple improvements skip planning entirely. But be careful. Many things that seem simple have hidden complexity. If there are edge cases, error states, or design choices involved, it's not a simple improvement.
How to Route
Start with two easy questions that filter out bugs and epics:
Is something broken? → Bug. Investigate before fixing.
Is this too big to hold in your head? → Epic. Break it down first.
For everything else, one question matters most:
Does this involve UX choices or edge cases?
If yes, it's a feature. UX choices means there's more than one valid way to build it and the user experience differs depending on which you choose. Edge cases means things can go wrong in ways that need handling: validation errors, failed operations, unusual inputs.
If no, it's a chore or simple improvement. The difference is just size. Changing button text is a simple improvement. Refactoring an entire module is a chore. Both have obvious implementations with no design decisions to make.
That's it. The full decision tree:
Broken? → Bug
Too big? → Epic
UX choices or edge cases? → Feature
Tiny? → Simple improvement
Otherwise → Chore
The common mistake is underestimating complexity. "Add form validation" sounds simple until you think about it: What errors can occur? What feedback should users see? What happens with partially valid input? Those are edge cases. That's a feature.
When in doubt, treat it as a feature. Unnecessary process wastes some time. Insufficient process creates fragile software.
Examples
"The login button doesn't work on mobile" → Bug. Something is broken. Investigate before fixing.
"We need a full authentication system" → Epic. Large initiative with multiple pieces. Break it down first.
"Migrate the entire codebase to TypeScript" → Epic (technical). Large technical initiative producing chores.
"Add drag-and-drop reordering for cards" → Feature. New user-facing capability with design choices. Explore approaches.
"Refactor the auth module to use the new pattern" → Chore. Technical work, obvious implementation.
"Change the button text from Submit to Save" → Simple improvement. Atomic change, no edge cases.
"Add form validation to the signup form" → Feature. Looks small, but has edge cases. Treat it seriously.