After this lesson, you will be able to: Write user stories with clear acceptance criteria, break large features into deliverable tasks, estimate honestly, and manage all of it in Jira or Linear.
Tickets are how engineering work travels through the team. Well-written tickets ship fast; vague tickets get blocked, re-discussed, and missed in code review. This lesson covers writing them and the two trackers you'll actually use: Jira and Linear.
Title: a clear, specific imperative. 'Add password reset email' beats 'Password stuff'. Description: WHY the work matters. Link to the bug, ticket, or feature spec. Acceptance criteria: a checklist of what 'done' looks like. The reviewer uses this to verify. Out of scope: what this ticket explicitly is NOT doing (to prevent scope creep). Links: design mocks, related tickets, documentation.
'As a <user>, I want to <action>, so that <benefit>.' Forces you to articulate WHO benefits and WHY, not just the mechanic. Best for product features. Overkill for infrastructure work ('upgrade Node from 18 to 20' doesn't need a user story). Use the format when it adds clarity; skip it when it doesn't.
Adopt this format in any tracker. Adjust to taste.
# Title: Add password reset via email## WhyUsers report they can't recover their account if they forget their password.Link to support tickets: <urls>.## Acceptance criteria- [ ] User clicks 'Forgot password' on /login- [ ] Form prompts for email; submits to /api/password-reset/request- [ ] Email is sent within 30s if the account exists (don't leak account existence)- [ ] Email contains a single-use token valid for 1 hour- [ ] Clicking the link in the email loads /reset-password?token=...- [ ] User can set a new password meeting the strength rules in src/lib/password.ts- [ ] Old sessions are invalidated## Out of scope- SMS reset (separate ticket)- Magic-link login## DesignFigma: <url>## NotesReuse PasswordResetToken model from /prisma/schema.prisma.Rate-limit the request endpoint to 3 / 15 min / IP.
Jira is the enterprise standard: deeply configurable, used at most large companies, with workflows, custom fields, epics, sprints, and powerful (sometimes overwhelming) reporting. Linear is the modern favorite at startups: fast, keyboard-driven, opinionated, and pleasant to use. Both do the same core things: create an issue with a title and description, fill acceptance criteria, assign it, set a status (Todo / In Progress / Done), link dependencies (`blocks` / `blocked by`), group issues under an epic or project, and view them on a board. You will be expected to be fluent in whichever one your team uses. The skill transfers: learn the concepts (issues, statuses, epics, links, boards, sprints) and the specific tool is a day of acclimatization. In both, a good ticket links its blockers explicitly so the board shows what is actually workable right now versus waiting on something else.
If a ticket takes more than ~3 days, break it down. Smaller tickets ship faster, get reviewed faster, and de-risk the feature. Pattern: 1 epic / parent ticket → 3-8 child tickets, each shippable independently. Vertical slices (front-to-back of a small feature) beat horizontal slices (build the whole API, then the whole frontend). Vertical lets you ship a working end-to-end version early.
Story points: relative size (Fibonacci 1-2-3-5-8-13-21). Useful for comparing tickets and forecasting capacity over time. Hours: absolute time. Useful for date commitments to stakeholders. Neither is 'right'; pick what your team uses. The trap: pretending either is precise. Both are estimates with high variance; treat them as such. Track DELIVERED points / hours over 5-10 sprints to get a realistic capacity, not a predicted one.
Tickets without acceptance criteria. Reviewer can't verify done; PM can't accept; engineer wonders if they're finished. Vague titles. 'Fix bug' is not a title; 'Fix duplicate notifications on Slack invite' is. Mega-tickets that take weeks. Hidden risk; everyone's afraid to start. Break down. Pretending estimates are precise. They're not. Anchor on 'I'm 80% confident this lands within X-2Y days' and update as you learn. Skipping the 'out of scope' section. Without it, every PR review starts with 'wait, why didn't you also fix this?'
Pick the senior move.
Sign in and purchase access to unlock this lesson.