Tickets, backlogs, requirements, scope, and MVPs

Where did Mira’s branch come from?

It came not from inspiration but from assignment.

Above the code workflow sits the planning layer. And this is the part of the module where you — PM, designer, founder, stakeholder — stop observing and start appearing in the story.

This lesson’s vocabulary is the shared language of that layer, the words that carry an idea from “someone wants something” to “someone is building it.”

What is a ticket?

The unit of work has a name. It is the ticketConcept · lights on your mapticketOne tracked piece of work (a feature, bug, or task) with a description, owner, status, and discussion thread. Also called an issue. Everything else in the planning layer is an arrangement of these., or issue; the words are synonyms.

A ticket is one described, owned, trackable piece of work. “Fix double charges on payment retries” is a ticket — the assignment Mira’s branch came from. So is “Add oat milk to menu options.” So is “Upgrade the payment SDK before v1 retires,” Module 6’s deprecation email turned into a ticket.

A ticket typically carries:

• A title and description
• An owner — whose work it currently is
• A status — open, in progress, in review, done — that moves as the work moves
• A priority
• A discussion thread, where decisions about the work get recorded

“File a ticket” means write it down where it can be tracked. In engineering culture, work that is not a ticket has a way of not existing.

What is the backlog?

Tickets wait in the backlogConcept · lights on your mapbacklogThe ordered list of all work a team intends (or vaguely hopes) to do, tickets waiting their turn. A healthy one is ruthlessly ranked, because far more enters than will ever ship., the team’s ordered to-do list.

The backlog is infinite by nature. Every user request, every bug report, every “someday” idea lands there, and every product’s backlog outlives the product.

That is why the real work of a backlog is not adding to it but ordering it. Teams regularly re-rank what rises and what sinks, a ritual called backlog refinement. The honest translation of “it’s in the backlog” ranges from “next week” to “never, politely.”

What is Jira?

Tickets and backlogs live in a tracker, and the tracker is overwhelmingly JiraConcept · lights on your mapJiraThe dominant (and dominantly grumbled-about) ticket-tracking product. The planning layer’s filing cabinet: tickets, backlogs, boards, sprints. “It’s in Jira” = it’s written down and tracked.. The product is so universal that “put it in Jira” just means “make it real.”

Concretely, Jira is a shared website. Every ticket is its own page — description, owner, status, discussion thread — and the backlog is a ranked list of them. Boards show the same tickets as cards moving through columns, To Do to In Progress to Done, so anyone can see where every piece of work stands.

It is also the product everyone grumbles about. The complaints are about heavy process, never about whether tracking should exist.

The main alternatives worth recognizing are Linear and GitHub Issues, the latter living directly alongside the code and PRs from earlier lessons.

That is the machinery: tickets, ranked in a backlog, tracked in Jira. But the machinery only files work; it cannot make work well-described. The rest of the vocabulary is about what a good ticket actually says.

What is a requirement?

A good ticket carries its requirementConcept · lights on your maprequirementThe outcome the work promises, described from the user’s side: “customers can choose a delivery time.” It deliberately leaves the how open — that choice belongs to the engineers building it.: what must be true when the work is done, stated from the outside.

Compare:

• “Customers can choose a delivery time at checkout” — a requirement an engineer can build against
• “Make delivery better” — a wish wearing a ticket’s clothes

Requirements say what, and engineers decide how. Vague requirements are the leading cause of built-the-wrong-thing, which is more expensive than built-slowly because it must be built twice.

What is scope?

ScopeConcept · lights on your mapscopeThe fence drawn around a piece of work before it starts, naming exclusions as explicitly as inclusions. Its enemy, scope creep, moves the fence one reasonable request at a time until the estimate is fiction. is the agreed boundary of the work: what is included and, just as loudly, what is not.

The failure mode has a famous name: scope creep. It never arrives as one big demand. It arrives as small reasonable additions (“while you’re in there, could it also show the courier on a map?”), each easy to say yes to, until the two-week feature is a two-month feature and nobody decided that on purpose.

The defense is writing the boundary down, including the exclusions. In planning culture, “out of scope” is a complete sentence. It is not a rejection of the idea but a decision about this ticket. The idea goes to the backlog, where it waits its turn honestly.

What is a constraint?

A constraintConcept · lights on your mapconstraintA non-negotiable given the solution must live with: a date, a budget, an old device, a regulation. Requirements set the destination; constraints rule out most of the routes to it. is a fixed condition the work must respect, a wall the solution must fit inside.

Typical walls:

• The holiday-season deadline that will not move
• The five-year-old Android phones the app must still run on
• The infrastructure budget
• Module 7’s GDPR obligations on the customer data involved

The distinction from requirements is worth keeping. A requirement is what the work must accomplish; a constraint is what the work must respect while accomplishing it.

What are acceptance criteria?

Acceptance criteriaConcept · lights on your mapacceptance criteriaThe ticket’s definition of finished, written as checkable statements agreed before building. Each line is a promise the demo must keep, and later a test someone can automate. turn “done” from a feeling into a checklist, agreed before the work starts.

Without them, “done” quietly means something different to everyone. The engineer means the code works. The stakeholder means it includes the map. The café owner means staff can see the slots. Everyone is sincere, and nobody finds out until the demo.

So each criterion is written as a check anyone can answer by looking:

• “Chosen slot saved with the order” — open an order and look; yes or no
• “Scheduling feels smooth” — sincere, unanswerable, and therefore not a criterion

Here is the whole planning vocabulary, assembled into one artifact:

The rule the criteria enforce is simple. If it is not on the list, do not expect it in the demo — and everyone read the list before the work began.

Module 12’s testers will read this same list. Acceptance criteria are where planning and testing shake hands.

What is an MVP?

Scope’s sharpest tool is the MVPConcept · lights on your mapMVPMinimum viable product: a slice small enough to ship soon and complete enough to work end to end, released early so real users can teach the team what to build next. Both words bind — cut ruthlessly, and ship it finished., the minimum viable product: the smallest version that is usable, shipped first, so reality can vote before the big version is funded.

The delivery MVP is the version COFFEE-482 already scoped — one café, same-day slots, no tracking. That is small and complete at once because a customer can schedule a real delivery, which means the team learns whether anyone wants one.

The discipline lives in both letters:

• Minimum: a sliver, not the full feature — resisting every “while we’re at it.”
• Viable: done completely — working, trustworthy, shippable. An MVP is not the big thing built badly; it is a small thing built properly.

Beware the word’s common abuse: “MVP” used as an excuse for shoddiness. A broken sliver teaches nothing except that broken things are bad, and reality can only vote on something that works.

The mental model to remember

A ticket (or issue) is one described, owned, trackable piece of work, the unit the planning layer runs on.

The backlog is the infinite ordered to-do list; its real work is prioritization. Jira is where both overwhelmingly live.

A requirement says what must be accomplished; a constraint is a wall it must be accomplished within; scope is the agreed boundary, including the loud exclusions that prevent scope creep.

Acceptance criteria turn “done” into a pre-agreed checklist, the single best defense against demo-day surprises.

An MVP is the smallest genuinely usable version: minimum in size, viable in quality, shipped to let reality vote.

You should now be able to read a well-formed ticket, spot a vague one, and hold your own in the two conversations that decide most product outcomes: what is in scope, and what does done mean?