The Journey of a Task: From Idea to Production

Imagine a ticket as a traveller on a very specific route. It has a starting point, a destination, and several mandatory stops it cannot skip — no matter how urgent the deadline feels. Understanding this route is how you know when a task is moving correctly and when it's taking dangerous shortcuts.

Learning Objectives

By the end of this lesson you will be able to:

• Name and describe every standard Kanban column and what it means
• Explain why QA is a mandatory stop, not an optional checkpoint
• Identify common ways that tasks get "stuck" and what to do about it

The Kanban Board

A Kanban board is a visual representation of all work in progress. Each column represents a state that a task can be in. Tasks move left to right as work progresses.

Standard Columns (and What They Mean)

Some teams add extra columns: Ready for Dev (ticket is refined and estimated), Blocked (work is halted by a dependency), or UAT (User Acceptance Testing). The exact columns vary — the flow direction never does.

The Journey of a Real Ticket

Let's follow a ticket: "Add 'Remember Me' checkbox to login form"

1. To Do
   BA writes the ticket. PM prioritises it. It sits in the backlog.

2. In Progress
   A Frontend developer picks it up. They add the checkbox to the UI.
   A Backend developer adds the "extended session" logic to the API.

3. Code Review
   A senior developer reviews both the Frontend and Backend changes.
   They request one change: "The session token expiry needs a comment."
   Developer updates the code. Review approved.

4. QA (Testing)  ← YOU ARE HERE
   The ticket arrives on the testing board.
   QA verifies each Acceptance Criterion:
   ✅ Checkbox is visible and clickable
   ✅ When checked, session persists for 30 days
   ✅ When unchecked, session expires at browser close
   ✅ Works on Chrome, Firefox, and mobile Safari
   ❌ FAIL: On Firefox, the checkbox state resets after page refresh
   QA opens a bug ticket, links it to the original, moves original back to In Progress.

5. Done
   Developer fixes Firefox bug. Returns to QA.
   All ACs pass. QA signs off. Ticket moves to Done.

Why QA Cannot Be Skipped

Every few months on every team, someone suggests: "Can't we just deploy this one small change without full QA? It's only two lines of code."

The answer is almost always no. Here's why:

1. "Two lines of code" is never just two lines of code. Code has dependencies. A two-line change in authentication logic can break the entire login flow.

2. QA tests the user journey, not the code. A developer tests their specific change. A QA engineer tests what the user experiences — which includes interactions with every other part of the system.

3. The cost of a production bug is exponentially higher. A bug caught in QA is fixed in hours. A bug found by a real user after deployment triggers support tickets, hot-fix deployments, a possible incident report, and damage to user trust. (More on this in Module 3.)

The QA column is not a formality. It's the last checkpoint before your work meets real users. Treat it with the seriousness it deserves.

When Tasks Get Stuck

Summary

A task travels:

To Do → In Progress → Code Review → QA → Done

Each column is a quality checkpoint. QA (Testing) is the column where the entire user experience is validated against Acceptance Criteria. Moving to Done without passing through it isn't a shortcut — it's a gamble with your users' trust.

Next lesson: you'll learn how teams decide what goes into each sprint and what you're expected to say at the daily standup.