The Life of a Ticket — From Idea to Production

The core concepts told you what a ticket is and the tool pages showed you where it lives. This page follows one ticket through its whole life — the real journey a piece of work takes from “someone noticed a problem” to “it’s live and closed.” Every organization’s exact steps differ, but the shape is remarkably consistent, and each step exists to answer a question before it becomes expensive to get wrong. Here is a mature, real-world lifecycle, grouped into six phases.

The journey on one page

   INTAKE    issue identified ─► ticket (story / bug / epic) created in the backlog
                │
   SHAPE       acceptance criteria reviewed with the stakeholder
                ─► prioritized ─► quote created (if extra cost) ─► quote approved / rejected
                │
   COMMIT      ticket added to a sprint
                │
   BUILD       devs work ─► deployed to the dev / test site ─► code reviewed by devs
                │
   VERIFY      ticket "completed" ─► AC reviewed by the PO & QA'd
                ─► demoed to the audience / stakeholders ─► approved / signed off
                │
   RELEASE     deployment notes sent ─► scheduled for production
                ─► deployed to production ─► smoke test ─► ticket closed

Read it top to bottom, but notice the arrows only mostly point down — a rejected quote, a failed review, or a broken smoke test sends the ticket backward. More on those loops at the end.

Intake — capture the work

An issue is identified, and a ticket is created in the backlog — tagged as a story (new value), a bug (something broken), or an epic (a large body of work that will be split into stories). The point of this step is simple but easy to skip: get the thing out of someone’s head and into the one place everyone can see it (the single source of truth). A problem that lives only in a hallway conversation or a DM cannot be prioritized, estimated, or tracked — it just quietly rots.

The common trap — the ghost backlog

Work that never becomes a ticket — the “quick favor,” the verbal promise, the Slack message — is invisible to planning. It still consumes the team’s time, so it silently blows up every estimate around it. Rule of thumb: if it’s work, it’s a ticket. No ticket, no work.

Shape — agree on what “done” means, and what it costs

This is where most of the risk is removed, cheaply, before anyone writes a line of code.

• Acceptance criteria (AC) are reviewed with the stakeholder. AC is the concrete, checkable definition of done for this ticket (“a logged-out user who submits the form sees an error and no email is sent”). Reviewing them with the person who asked is the single highest-leverage step in the whole lifecycle: it’s where you catch “that’s not what I meant” while it costs a conversation, not a rebuild. This is the scoping and requirements discipline made real.
• The ticket is prioritized. Against everything else in the backlog — is this more valuable now than the next thing? That’s a prioritization decision, and saying “yes, this” is also quietly saying “no, not that.”
• A quote is created if extra cost is needed, and then approved or rejected. If the work needs budget beyond the normal run rate, someone estimates the cost and the payer decides. This is the iron triangle in the open: scope, time, and cost are locked together, and a quote forces the trade-off to be chosen rather than discovered halfway through. A rejected quote sends the ticket back to shaping (cut scope) or out of the backlog entirely.

In practice — the AC review that saved a week

A “simple” export-to-CSV ticket looked trivial until the AC review, where the stakeholder mentioned the file had to open cleanly in Excel in three languages. That one sentence turned a half-day task into a multi-day one — and finding it in a ten-minute conversation, before the sprint, is exactly what the shape phase is for. The alternative is finding it at the demo, after the work is “done.”

Commit — pull it into a sprint

The ticket is added to a sprint — the team commits to finishing it inside the current timebox. This is the moment the ticket stops being a maybe and becomes a promise for this iteration (see Scrum: the rhythm of sprints). A ticket should only be pulled in when it’s genuinely ready — which is why many teams keep a “definition of ready” (AC agreed, dependencies known, estimate done, no open questions) as the gate for entering a sprint, the mirror image of the “definition of done” waiting at the other end.

Build — do the work, then check it

• Devs work on the ticket — the actual implementation.
• The work is added to the dev / test site — deployed somewhere it can be seen and exercised that isn’t production. Nothing is real until it runs outside the author’s machine.
• The code is reviewed by other devs. A second pair of eyes on the change catches mistakes, spreads knowledge, and keeps quality from depending on one person’s good day. Code review is a quality gate — the same idea the Software Testing book treats in depth. A review that finds a problem sends the ticket back a step; that’s the gate working, not failing.

Verify — prove it’s right, and get agreement

“Done building” is not “done.” Three independent checks stand between the two:

• The ticket is marked completed, and its AC is reviewed by the Product Owner and QA’d. The PO confirms it does what was agreed; QA tries to break it and checks the AC actually hold — the adversarial, edge-case mindset from the testing book. This is the “definition of done” being enforced by someone other than the author.
• The work is demoed to the required audience / stakeholders. Showing beats telling: a demo turns “trust me, it’s done” into “watch it happen.” It’s also a managing-expectations moment — the audience sees reality and can react before it ships.
• The work is approved / signed off. An explicit yes from the accountable person. Sign-off matters because it’s a decision with a name attached — it converts a vague “looks good” into a recorded agreement you can point back to later.

The common trap — skipping the gate under pressure

When a deadline looms, the verify gates (review, QA, sign-off) are the first things people are tempted to skip — precisely when the pressure that created the rush also makes mistakes most likely. The gates exist for the bad days. Skipping them doesn’t remove the work; it just moves the discovery of the problem to production, where it’s most expensive.

Release — ship it, safely, and close the loop

• Release / deployment notes are sent. A written summary of what’s changing, who’s affected, and what to watch — so no one is surprised by a change to a shared system. (The DevOps book calls this no-surprises release discipline.)
• The work is scheduled for a production deployment, then deployed to production. Scheduling — rather than shipping the instant it’s approved — lets the deploy land at a low-risk time with the right people available.
• A smoke test is completed. A quick check that the critical paths still work on the real production system right after deploy — the smoke test from the testing book. It’s the difference between “we deployed” and “we deployed and it works.”
• The ticket is closed. The loop is complete: a problem someone noticed is now live, verified, and recorded as done.

The loops nobody draws, but everybody lives

The clean top-to-bottom diagram hides the honest truth: work flows backward too.

   quote rejected      ──► back to shaping (cut scope) or dropped
   code review fails    ──► back to the dev
   QA / PO review fails ──► back to build, sometimes back to shaping (bad AC)
   demo rejected        ──► back to build or shaping
   smoke test fails     ──► roll back the deploy, reopen the ticket

A healthy process treats these as the system working, not as failure. Each gate exists to catch a problem one step earlier than the next gate would — and a rollback plan (how to undo a bad deploy fast) is part of release, not an afterthought. A ticket that only ever moves forward isn’t a sign of a great team; it’s usually a sign the gates aren’t really checking anything.

How it connects

This lifecycle is the whole book in miniature: shaping is project management and decisions; the sprint is ways of working; the demo and sign-off are managing up and across; the review, QA, and smoke test reach into the sibling Testing and DevOps books. And because every step and its owner is written down, the lifecycle is also your best defense against the friction of undefined handoffs — most process conflict lives in the steps nobody agreed on.

Try this

Take one real ticket your team shipped recently and map it onto the six phases above. For each of your team’s actual steps, write two things: who owns the gate (who decides it passes) and what question it answers. Two findings are almost guaranteed: at least one step everyone does but no one owns, and at least one step that’s really a backward loop pretending to be forward progress. Those two gaps are where your delivery friction is hiding.

Reflect

1. Which single gate in this lifecycle removes the most risk for the least cost — and why is it so often rushed or skipped?
2. Your team ships a ticket that passes code review and QA but the stakeholder hates the demo. Which earlier step failed, and what would you change?
3. “If it’s work, it’s a ticket.” What work does your team routinely do without a ticket, and what does that invisibility cost the plan?
4. Where in your own process does work flow backward, and does your team treat that as the system working or as someone failing?
5. Pick one gate you could add an explicit owner to tomorrow. Who would it be, and what argument would it end?

Show reflections

1. The AC review with the stakeholder (shaping) is the highest-leverage, cheapest risk-remover — a misunderstanding caught in a ten-minute conversation costs a conversation; the same misunderstanding caught at the demo costs the whole rebuild. It’s rushed because it feels like “not real work” next to coding, which is exactly the trap.
2. The AC / shaping step failed — what was built matched the written criteria but not what the stakeholder actually wanted, which means the AC didn’t capture their real intent. Fix: make the AC review more concrete (examples, a mockup, “show me what good looks like”) so the demo holds no surprises.
3. Common answers: verbal favors, “quick fixes,” urgent DMs, meetings, support. The cost is that this work is invisible to planning yet consumes real capacity, so every estimate around it silently overruns. Making it a ticket doesn’t create the work — it just makes the already-existing cost visible.
4. Honest answers name the backward loops (failed review, rejected demo, rolled-back deploy). The healthy framing is “the gate caught it one step early” — treating loops as failure pushes people to hide problems until they’re worse, which is the opposite of what you want.
5. Any gate with a fuzzy owner works — “who signs off?”, “who decides priority?”, “who owns the smoke test?”. Naming the owner ends the recurring “I thought you had it” argument, which is where undefined handoffs turn into interpersonal friction.