📋 Scrum & Kanban Boards

Scrum & Kanban Boards: Picture the order board of a restaurant kitchen: orders come in from the left, pass through prep stations and leave to service on the right.

Picture the order board of a restaurant kitchen: orders come in from the left, pass through prep stations and leave to service on the right. The number of burners is limited -- you can only boil four pots at once. That limit is not a flaw, it is the reality of the kitchen; a kitchen that ignores it and starts ten orders at once serves no plate on time. The WIP limit in Kanban is exactly that burner count. The question worth pausing on: does adding a "QA" column make testing visible, or does it lock QA into a waterfall step at the very end of the flow? Both sides have strong arguments and this page does not force one on you -- but it shows you how to measure the outcome of your choice. Compare: you cap the number of parallel workers in an automation run, because opening sixteen browsers on eight cores does not shorten total time, it lengthens it. A WIP limit applies the same physics to a human team: as concurrent work grows, the completion time of each item grows with it. For QA the board is a diagnostic instrument: cards piling up in the "QA" column show that the team's testing capacity trails its development speed. That pile-up is not an accusation but a measurable signal -- and the most concrete data point you can bring to a retrospective.

🧭 What You Will Learn in This Tab

We will cover the backlog to sprint to board chain; the difference between Scrum and Kanban boards and which team each suits; column, swimlane and quick-filter configuration; how a WIP limit makes a bottleneck visible; and which data QA brings to each sprint ritual (planning, daily, review, retrospective). Once you have read the concepts, the sprint simulator on this site lets you live the same flow on a Kanban board.

🎬 The Journey of a Work Item From Backlog to Board

Backlog (200+ items)

Sprint Review: Velocity

SHOP-118 "Apply Coupon Code" sits as a raw idea in a backlog of over 200 items -- not yet estimated, no acceptance criteria written. In this film you will follow this raw idea's path all the way to the board.

Step 1 -- Grooming (refinement): the team and PO sit together, estimate story points (5 points) and write the acceptance criterion: "A coupon is applied once per order". Skip this step and you cannot predict WHEN the card will finish on the board.

Step 2 -- Sprint Planning: the team pulls items from the backlog according to capacity (30 points for this sprint). SHOP-118's 5 points fit the capacity, it is pulled into the sprint. An unestimated item cannot be selected here -- nobody knows how long it will take.

Step 3 -- The sprint starts, SHOP-118 appears as a card on the board. The card moves through columns: To Do to In Progress to Ready for QA to In QA to Done. Thanks to the acceptance criterion, QA's answer to "is this finished" is CLEAR.

Step 4 -- Sprint Review: the card reached the Done column, 5 points are added to the team's velocity. This number will be used to estimate next sprint's capacity -- one card's journey is now a data point.

Finale (the contrast) -- Picture another card pulled straight into the sprint, skipping grooming: no acceptance criterion, nobody knows how long it takes. The card FREEZES in the "In Progress" column for DAYS -- the developer cannot move forward not knowing what counts as "done". Grooming is not a skippable step, it is the PRECONDITION for a flowing board.

1️⃣ G1. The Backlog to Sprint to Board Chain

If the grooming (refinement) step is skipped and an item is pulled directly into the sprint, what is the most likely outcome?