Jira — A Project End to End

Jira — The Core Concepts gave you the vocabulary: projects, issues, issue types, workflows, boards, backlogs, sprints. This page puts every one of them in motion. We’re going to take a single small feature — the kind a real team ships in a sprint or two — and walk it the whole way, from a sentence someone said in a meeting to a thing that’s live and closed out.

The point isn’t to admire the tool. It’s to see the loop the tool exists to serve: the plan-protect-review-improve rhythm from Scrum: The Rhythm of Sprints. Jira is just where that rhythm becomes visible and shared. By the end you’ll have a worked example concrete enough to copy step for step.

A note on the buttons

Jira’s exact menus, labels, and screens change often. As of 2024 the concepts below hold, but the precise wording and where a button lives may differ in your version, and will keep drifting. Learn the workflow — what you’re trying to accomplish at each step — not the pixel location of any control. If a name here doesn’t match your screen, look for the thing that does the same job.

The example we’ll follow

Our team runs a small online shop. In a planning conversation someone says: “Customers keep emailing to ask where their order is. We should just email them automatically when it ships.” That sentence is the idea. Everything from here is turning it into shipped work without losing the thread.

Step 1 — Set up the place the work lives

If the team doesn’t already have one, you create a project — the container for all this team’s work. You pick a project type (a team-managed project is the simplest place to start) and a key, a short prefix like SHOP. From now on every item gets an ID like SHOP-142, and that ID becomes the shared name everyone uses in chat, in commits, in standup. One shorthand, one source of truth.

You only do this once. A project is not per-feature; it’s per-team or per-product. Our shipping-email feature will live inside the existing SHOP project as a few issues, not in a project of its own.

Step 2 — Frame the idea as an epic

The feature is too big to be one task and too small to be a project. That’s exactly what an epic is for: a chunk of related work with a shared goal, that will be delivered as several smaller items.

EPIC  SHOP-140  "Order status notifications"
      Goal: customers know where their order is without emailing us.

Write the epic as an outcome, not a task list. “Order status notifications” tells anyone reading the backlog why the work below it exists. That framing is what keeps a sprint from becoming a pile of disconnected tickets.

Step 3 — Break the epic into stories and tasks

Now you decompose the epic into stories (a unit of user-facing value) and tasks (work that has to happen but isn’t a feature by itself). The discipline: each item should be finishable inside one sprint and independently checkable as done.

EPIC  SHOP-140  Order status notifications
  ├─ STORY SHOP-141  Send an email when an order ships
  ├─ STORY SHOP-142  Let customers turn shipping emails off
  ├─ TASK  SHOP-143  Add a "shipped" event to the order system
  └─ TASK  SHOP-144  Set up the email-sending service

Each story gets acceptance criteria — the plain-language answer to “how will we know this is done?” For SHOP-141:

SHOP-141  Send an email when an order ships
  Acceptance criteria:
   - When an order's status becomes "shipped", the customer
     gets one email within a few minutes.
   - The email includes the tracking link.
   - No email is sent for orders that were already shipped
     before this feature existed.

Acceptance criteria are where most rework is prevented. They turn “build the shipping email” from a vague instruction into a checkable contract, so nobody discovers at review time that “done” meant three different things to three people.

Step 4 — Estimate the work

Before you can plan a sprint you need a rough sense of size. Most Scrum teams estimate in story points — a relative measure of effort and complexity, not hours. A tiny change is a 1; a big, uncertain one might be an 8. The team estimates together, because the conversation surfaces hidden work (“wait, we don’t have an email service yet — that’s the real cost”).

SHOP-141  Send email when shipped        → 3
SHOP-142  Let customers turn emails off   → 2
SHOP-143  Add "shipped" event             → 3
SHOP-144  Set up email service            → 5
                                    total = 13 points

The absolute numbers are meaningless on their own. They only become useful once the team has a track record of how many points it actually finishes per sprint — which is where velocity comes in, later on this page.

The common trap — estimating in hours to look precise

Teams new to points often quietly convert them to hours (“a 3 is a day and a half”) to feel more exact. This throws away the one advantage of points — that they’re a rough, relative gut-check the team calibrates over time — and replaces it with false precision that invites managers to treat estimates as promises. Estimate the size relative to other work. Let velocity, not arithmetic, tell you how much fits in a sprint.

Step 5 — Plan the sprint

At sprint planning the team pulls items off the top of the prioritized backlog into a new sprint, until the total points roughly match what the team normally finishes. Say this team reliably completes about 12 points a sprint. They pull SHOP-143, SHOP-144, and SHOP-141 (3 + 5 + 3 = 11) and leave SHOP-142 — the opt-out story — at the top of the backlog for next time.

That last decision is the heart of planning: not “how do we fit everything in,” but “what is the most valuable slice we can finish.” The opt-out is real but less urgent than the emails themselves, so it waits. Once planning ends, the sprint is a protected commitment — new requests go on the backlog, not into this sprint.

Step 6 — Work the board, day to day

Inside the sprint, work lives on the board — columns that mirror the team’s workflow. Each issue is a card that moves left to right as it progresses.

┌──────────┬──────────────┬─────────────┬────────────┐
│  TO DO   │ IN PROGRESS  │  IN REVIEW  │    DONE     │
├──────────┼──────────────┼─────────────┼────────────┤
│ SHOP-141 │ SHOP-144     │ SHOP-143    │            │
│          │  (assigned:  │  (assigned: │            │
│          │   Priya)     │   Sam)      │            │
└──────────┴──────────────┴─────────────┴────────────┘

The daily discipline is small but non-negotiable: the board reflects reality. When you start something, move it to In Progress and put your name on it. When it’s ready for someone to check, move it to In Review. If the card says one thing and your actual work says another, the board is lying, and every decision made off it — standup, planning, the burndown — is now built on fiction. Moving your own card is the single cheapest habit that keeps the whole system honest.

Step 7 — Run standup off the board

The daily standup should walk the board, not go person by person. Instead of “what did you do yesterday,” you look at the cards closest to Done and ask what it takes to get them there. This keeps the meeting about finishing work rather than reporting activity — the distinction Scrum: The Rhythm of Sprints draws between coordination and status theatre.

STANDUP (walking the board, right to left):
  IN REVIEW  SHOP-143  Sam: "needs one review — Priya, can you look
                        after this?"
  IN PROGRESS SHOP-144 Priya: "email service is up, but I'm blocked —
                        no API key from the vendor yet."
  TO DO      SHOP-141  "starts once 143 and 144 land."

Notice what the board just surfaced without anyone having to ask: one card needs a reviewer, one is blocked, and the third can’t start yet. That’s coordination doing its job.

Step 8 — Handle blockers in the open

SHOP-144 is blocked on a vendor API key. The wrong move is to let it quietly stall while Priya waits. The right move is to make the block visible and owned: flag the issue as blocked (Jira lets you flag a card or set a blocked status), write one line in the issue saying exactly what it’s waiting on and who’s chasing it, and — if a specific issue is the cause — link it as “is blocked by.”

SHOP-144  Set up email service   ⚑ BLOCKED
   Blocked by: waiting on API key from email vendor.
   Owner of the chase: Priya, escalated to manager 2026-07-08.

A flagged, annotated blocker is a request for help the whole team can see. A silent one is just a deadline quietly slipping. The process guardian’s job — the Scrum Master, if you have one — is to hunt these flags down and clear the path, not to nag the person who’s stuck.

Step 9 — Close the sprint

At the sprint’s end you close it out. Jira asks what to do with anything not finished; the honest answer is to move incomplete work back to the backlog to be re-prioritized, not to silently drag it into the next sprint as if it were free. If SHOP-144’s API key never arrived, that card returns to the backlog and the team is honest that it didn’t land.

Closing the sprint is also what generates the numbers you’ll read next. It’s the moment the tool records “this is what we committed to, and this is what we actually completed.”

Step 10 — Read the burndown and velocity

Two charts turn the finished sprint into learning.

The burndown chart shows work remaining over the sprint. A healthy line trends down toward zero by the end. A flat line early followed by a cliff means work only “finished” in a rush at the deadline — often a sign cards weren’t really moving through review as they should.

POINTS
REMAINING
 11 │●
    │ ＼
  8 │   ●___
    │       ＼
  4 │         ●___
    │             ＼
  0 │_______________●____
    Mon  ...        Fri

Velocity is how many points the team completed per sprint, tracked over several sprints. It’s not a target to beat — it’s a planning input. A team that completed 11, 13, 12, and 12 points can plan the next sprint around ~12 with reasonable confidence. That’s how the meaningless raw points from Step 4 finally earn their keep.

The common trap — velocity as a productivity score

The fastest way to ruin these numbers is to treat velocity as a performance metric and push the team to make it go up. The team will oblige — by inflating estimates. Points quietly balloon, “velocity rises,” and nothing more actually gets done. Velocity is a forecasting tool for the team, not a scoreboard for managers. The moment it’s used to judge people, it stops telling the truth.

Step 11 — Feed the retro

Finally, the sprint’s real events become fuel for the retrospective. The blocked API key isn’t just a closed card — it’s a pattern worth naming: we start work that depends on external vendors before we’ve secured what we need from them. A good retro turns that into one concrete change: “before pulling a card that depends on an outside party, confirm the dependency is unblocked in planning.” Owned, written down, revisited next sprint — exactly the improvement loop that gives Scrum its value.

The board, the flags, and the charts aren’t paperwork. They’re the raw material the retro reads to make the team a little better each cycle.

How it connects

This whole walkthrough is one concrete instance of the Scrum rhythm from the Ways of Working part — Jira is simply where that rhythm becomes shared and visible. The standup here is the meeting discipline your Meetings part teaches, run off a board instead of a status round. And What Any Task Tool Must Do named the jobs — capture, prioritize, show state, review — that every step above is quietly performing. When you reach ClickUp — Running Work End to End, you’ll walk this same feature through a different tool and see how little the underlying loop actually changes.

Try this

Take one real, small feature or improvement from your own work — something two or three items in size. On paper or in a real Jira project, run the full loop: write it as an epic with an outcome-shaped title, break it into two to four stories and tasks each with one line of acceptance criteria, estimate them relatively, pick the slice you could actually finish in two weeks, and sketch the board columns your team really uses. Don’t aim for a perfect Jira setup. Aim to feel the moment where a vague sentence becomes a set of finishable, checkable items — that translation is the skill the tool exists to support.

Reflect

1. In the example, why does the opt-out story get left in the backlog rather than crammed into the first sprint? What does that decision reveal about what planning is actually for?
2. Acceptance criteria were called “where most rework is prevented.” Think of a recent piece of work that came back wrong — would a one-line “how we’ll know it’s done” have caught it?
3. What breaks, concretely, when people don’t move their own cards on the board? Trace the consequences through standup, the burndown, and planning.
4. Why is velocity dangerous the moment it’s used to judge people rather than to forecast? What specific behaviour does that pressure produce?
5. The blocked API key became a retro change, not just a closed ticket. What’s one recurring blocker in your own work that you’ve been treating as bad luck rather than a fixable pattern?

Show reflections

1. The opt-out waits because it’s real but less valuable than the emails themselves, and the team can only pull what it can finish. Planning isn’t about fitting everything in; it’s about choosing the most valuable slice that will actually be done by sprint’s end. Naming that trade-off is the core of the skill.
2. Most work that “comes back wrong” was never defined precisely enough to be right. A single checkable criterion — “done means the customer gets one email with a tracking link” — converts a vague instruction into a contract, and contracts are what catch the mismatch before review, not after.
3. A stale board poisons everything downstream: standup discusses cards that are secretly finished or secretly stuck, the burndown shows work “remaining” that’s actually done (or hides work that’s stalled), and planning forecasts off fiction. The cheap habit of moving your own card is what keeps all three honest.
4. Judged velocity invites inflated estimates: the number rises while real output stays flat, because points are elastic. The tool that was meant to forecast quietly becomes a lie. The tell is estimates creeping upward with no change in what ships — the metric optimizing itself instead of the work.
5. The useful move is reframing a “bad luck” blocker as a pattern with a fixable cause — a dependency confirmed too late, a review that always bottlenecks, an environment that’s always broken. If you can state the pattern in one sentence, you can write one retro change to attack it, which is the entire improvement loop in miniature.