Task Management
How we track work and practice good issue hygiene
Linear is how we track work at Eddy. Everyone uses it. This policy explains how we keep issues actionable, how work ties to our goals, and how we work through issues (not just on them) so that handover and context stay clear.
We use Linear’s own terminology: issues (what you see in the app). However you may find people saying "tasks" or "tickets" instead.
How Work Connects
We want it obvious how day-to-day work links to our 17 week strategic cycles.
- Initiatives → Projects → Issues
- Every issue should sit in a project when possible.
- Projects live under initiatives, so you can see how a task connects to our goals.
- Intiatives are defined in our 17 week strategic cycles.
Epics: You can use epics with sub-issues if it helps. If you do, label the parent issue as an Epic so it’s clear.
Who creates initiatives and projects: Dan and Greg are responsible for defining initiatives and projects. If something’s missing, raise it — but you’re not blocked on that to do your work.
Adding Work
Never be blocked by project management tools
If you’re working on something that doesn’t have an issue yet, add one and bring it up at standup the next day. If there’s no obvious project for it, add the issue anyway and raise it at standup so we can tidy it up (e.g. create or choose a project). Do the work; we’ll fix the structure together.
Issue Format
We use a consistent structure in the issue body so anyone can quickly understand and pick up work. Use these four sections:
Overview — What this issue is and why it matters. A short summary that gives context: the goal, the problem we’re solving, or the outcome we want. Enough for someone to understand the “what” and “why” without reading the rest of the system.
Requirements — What must be true for this work to be done. Acceptance criteria, constraints, and what “done” looks like. This is the checklist we use to know the issue is complete and to review it.
References — Links to anything someone needs to do or review the work: specs, designs, docs, Figma files, spreadsheets, or related issues. Keeps handover and context in one place.
Todos — The concrete steps or sub-tasks to do the work. Break the work down here; tick them off as you go. This is what makes the issue actionable and shows progress.
An issue that has all four sections filled in is in good shape to move to Ready.
Definition of Ready: When an Issue Can Leave Backlog
An issue is only moved into Ready when it’s actionable. That means it follows the issue format above and has:
- Overview — clear definition and context
- Requirements — what “done” looks like
- References — links to anything needed
- Todos — a list of steps to complete
Sprint planning is mostly choosing from Ready, not writing new issues on the spot. Ready should already be filled with issues that meet the above. If something in Ready doesn’t, send it back to Backlog until it does.
Assignment
Issues in Ready may be assigned. If an issue in Ready is unassigned, it’s available for anyone in the team to pick up.
When you start working on an issue, move it to In Progress and keep it updated as you go.
Working through issues not just on them
We work through issues in Linear — meaning the issue is the place where progress and context live. In the end each issue should read as a story of how the work was defined and delivered.
- Keep the issue open while you work.
- Update to-dos as you complete them.
- End of day: add a short update in the comments — a few bullets on what you did and any important context. This keeps a simple “story” of the work for handover and review.
You don’t need long write-ups; a couple of bullets is enough. The goal is that the next person (or future you) can understand what happened.
When You’re Done: Review and Handover
When the work is complete:
- Record a Loom that walks through what you did (and any gotchas or decisions).
- Attach the Loom to the issue.
- Move the issue to Review on the board.
- In the comments, @mention the person who should review and give a short handover (e.g. what to check, what you’re unsure about). Don’t rely on “reassigned to you” as the handover.
Assignment and notifications: Don’t assume reassigning an issue is enough. People often miss or ignore those notifications. If you change who an issue is assigned to, always leave a comment that @mentions them and explains why you’re assigning it and what you need from them. We’re working with people, not systems — a clear handover in the comment makes the difference.
Summary
| Do | Don’t |
|---|---|
| Put issues in a project when you can | Block on “no project” — raise at standup instead |
| Only move issues to Ready when they have Overview, Requirements, References, and Todos filled in | Move half-baked issues into Ready |
| Update the issue and to-dos as you work; add a short end-of-day comment | Leave issues stale while you work elsewhere |
| Attach a Loom and @mention the reviewer when moving to Review | Reassign without a comment and expect people to notice |
| Create issues for work that doesn’t have one yet | Rely on assignment notifications as your handover |
Linear is the single place we look to see what’s happening. Good issue hygiene keeps everyone aligned and makes handover and review smooth.