Learn Ticket Craft

What each level of the Jira hierarchy is for. Why skipping the Story layer turns every Epic into a pile of plumbing nobody can roadmap from.

The difference between a note to self and a contract between product, design, and engineering. Titles that read as implementation, ACs tangled with technical notes, and the kind of ticket a new joiner has no chance with.

As a, I want, so that. Ron Jeffries' three Cs. Why the so that clause is the part that survives a refactor of the template, and how to write it in plain prose without losing the discipline.

When a piece of work is not a story. Bug tickets that make the impact reproducible, spike tickets timeboxed to questions, and the plumbing work that genuinely belongs as a Task.

Independent, Negotiable, Valuable, Estimable, Small, Testable. The compact 2003 sanity check that still catches more bad stories than any longer checklist. Testable is the letter teams fail most.

Given, When, Then for outcomes a neutral reader can verify. The line between completeness and over-specification, and how to keep implementation notes out of the AC list.

The shared bar a story has to clear before it enters a sprint. Actor and outcome present, dependencies linked not assumed, fits in a sprint, and nobody walks out of refinement still confused.

The shared bar a story has to clear before it leaves a sprint. Verified by someone other than the implementer, tests at the right level, deployed and observable, ticket closed with what actually shipped.

Size, not time. Why Fibonacci's gaps are a feature, why a 4-and-5 disagreement is noise, and why a 13 is a signal to split or spike rather than an estimate to commit to.

Planning poker, t-shirt sizing, and reference stories. The room outlier is the whole point. The number is a side effect of the conversation, not the goal.

Why splitting a story by technical layer fails INVEST on three letters at once. The vertical slice that ships end-to-end, teaches the team something, and lets product deprioritize the rest.

The Humanizing Work nine patterns and the SPIDR mnemonic that compresses the most useful five. Workflow steps, CRUD, business rules, data shapes, input methods, major effort, simple-then-complex, defer performance, and spike.

MoSCoW, RICE, value vs effort, and Cost of Delay. Who decides, and how to keep prioritization a product conversation rather than an engineering vote.

Velocity vs throughput, WIP limits, focus factor, and capacity. Lead time and cycle time. Why a board with eight in-progress tickets per person is not productive, it is stuck.

Standup, refinement, planning, review, retro. What each is for, what it turns into when misused (status reports, design committees, demo theater), and how to keep them short and useful.