Structuring Work in Jira, Linear, or Any Tracker
Imagine trying to navigate a city with no street names, no neighborhoods, and no districts — just a flat list of 50,000 buildings. That's what a flat backlog of 1,000 undifferentiated tickets feels like. Hierarchy provides context: which neighborhood (Epic) is this street (Story) in, and which building (Task) am I working on right now?
1. Epic (The Boulder)
- A large initiative that represents a significant business outcome. Takes 1-3 months and spans multiple sprints.
- Epics answer: "What strategic goal are we advancing?"
- Example: "Migrate Auth System to OAuth2"
- Example: "Reduce P95 API Latency Below 200ms"
- Anti-pattern: An epic that never closes. If an epic has been open for 6+ months with no end in sight, it's either too large (split it) or too vague (redefine it). A good epic has a clear definition of done at the epic level — not just "we're working on auth improvements" but "all users can authenticate via OAuth2 and the legacy auth system is decommissioned."
2. Story (The Rock)
- A unit of user-facing value. Small enough to complete in 1-5 days. Fits within a single sprint.
- Stories answer: "What can a user do that they couldn't do before?"
- Format: "As a [type of user], I want [capability], so that [benefit]."
- Example: "As a user, I can log in with my Google account, so that I don't need to remember another password."
- Key attribute: Stories must have acceptance criteria — specific, testable conditions that define "done." Without acceptance criteria, "done" is whatever the developer thinks it means, which is rarely what the PM or QA engineer thinks it means.
## Story: Google OAuth Login
**As a** registered user
**I want to** log in using my Google account
**So that** I can access the platform without creating a new password
### Acceptance Criteria
- [ ] User sees a "Sign in with Google" button on the login page
- [ ] Clicking the button redirects to Google's OAuth consent screen
- [ ] After consent, user is redirected back and logged in
- [ ] If no account exists for that Google email, one is created automatically
- [ ] If the Google OAuth flow fails, user sees a clear error message
- [ ] Existing users who log in via Google are matched to their account by email
3. Task (The Pebble)
- A technical implementation step. Takes hours, not days. Not user-facing.
- Tasks answer: "What specific technical work must happen to deliver the Story?"
- Example: "Add
google-auth-librarytopackage.json" - Example: "Create
oauth_tokenstable migration" - Example: "Write unit tests for OAuth callback handler"
4. Bug
- A defect in existing functionality. Bugs should reference the original Story or Epic they relate to, so you can understand the context and assess severity.
- Example: "OAuth login fails when user's Google email contains a '+' character"
- Bugs that can't be linked to any story or epic are often symptoms of missing acceptance criteria — the behavior was never specified, so it was never tested.
5. Spike (often overlooked but critical)
- A time-boxed research task to reduce uncertainty. The output is knowledge, not code.
- Example: "Spike: Evaluate OAuth2 libraries (2 days). Deliverable: comparison document with recommendation."
- Spikes prevent the team from committing to a Story when they don't yet understand the technical approach. A story that requires a spike before it can be estimated should not be pulled into a sprint until the spike is complete.
The Linking Rule
Never work on a Task unless it is linked to a Story. If you can't explain the user value (Story) that a Task serves, one of two things is true: (1) the Story exists but hasn't been written — write it, or (2) the Task doesn't actually need to be done. This discipline prevents "resume-driven development" where engineers work on technically interesting but business-irrelevant work.
The exception is tech debt tasks, which should be linked to a "Tech Debt" or "Platform Health" epic with a clear rationale: "Refactor authentication module to reduce coupling, enabling faster iteration on upcoming OAuth2 migration." Even tech debt needs a business justification — "it bothers me" is not a justification; "it will slow down the next three features by 30%" is.
Key Point: The hierarchy isn't bureaucracy — it's a communication tool. When a VP asks "How's the OAuth migration going?", you answer at the Epic level. When a teammate asks "What should I pick up next?", you answer at the Task level. When a PM asks "What can we demo to customers this sprint?", you answer at the Story level. Each level serves a different audience with a different need for detail. A team that conflates these levels — putting implementation details in epics, or business goals in tasks — creates confusion that slows everyone down.