Short answer: A scrum task card is a short, scannable description of one piece of work. Put a title, an estimate, an owner, and acceptance criteria on it — leave everything else off. Use four card types (user story, task, bug, chore), one colour each, one owner at a time. Most card-system failures come from teams adding fields rather than removing them.
A scrum task card is the smallest piece of work the team agrees to ship. One card, one outcome, one owner at a time. Cards exist so the team can talk about the work without first having to remember what the work was. They are conversation anchors, not contracts — closer to the spirit the Scrum Guide describes as transparency, inspection, and adaptation than to ticket-shaped documentation.
Most card systems break for the same reason: teams keep adding fields until the card stops being scannable. This guide is the fix. What belongs on a card, what doesn't, and how to tell which is which.
Scrum task cards, plainly explained
A scrum task card represents one piece of work on the team's board. It moves left to right through columns, usually To Do → In Progress → Done, and carries just enough information for any team member to pick it up cold.
There are four card types worth distinguishing. Anything beyond these four is a special case dressed up as a category.
| Card type | Colour (convention) | What it represents | When to use |
|---|---|---|---|
| User story | White / yellow | A user-visible feature or change | The default. Most cards. |
| Task | Blue | A non-user-facing piece of engineering work | Refactors, infrastructure, internal tooling |
| Bug | Red / pink | A defect — something that used to work | Reopened user value, never new functionality |
| Chore | Green | Maintenance with no direct user output | Dependency upgrades, certificate renewals, doc cleanup |
💡 Pivotal Tracker's heritage — which LiteTracker inherits — counts only accepted user stories toward velocity. Tasks, bugs, and chores never get points. That single rule prevents most "we're shipping fast but users see nothing" forecasting bugs. The longer argument for treating velocity as pace, not productivity is worth a read before any team starts debating point inflation.
What goes on a scrum task card
Essential — every card has these:
- Title. A short noun phrase. "User can reset password via email" is good. "Password reset" is too vague.
- Type. One of the four above. Drives colour and counting rules.
- Estimate. Points for user stories (1, 2, 3, 5, 8). Skip estimates on tasks and chores — they don't earn points anyway.
- Owner. One person at a time. If two people are on a card, one of them is doing the work; the other is reviewing.
- Acceptance criteria. 2–4 bullets describing what "done" means. The contract.
Optional — add only when the team can name the cost of leaving it off:
- Description / context paragraph (skip if the title is self-explanatory). If the team writes a lot of similar cards, a small set of story description templates keeps the prose consistent without bloating the card.
- Linked design / spec (only when the card is a stub for a longer document).
- Sub-tasks (rare on a true scrum card; if you need them, you're probably looking at multiple cards in a trench coat).
- External-tool ID (Jira, Linear, GitHub Issue) when the team is mid-migration.
- Tags or labels (use sparingly — three tags max per card before the tag system stops being signal).
Every field on a card has a cost. Someone has to fill it in. Someone has to read it. The next person has to keep it current. Drop fields whose upkeep costs more than their forecasting value.
How to write a card in four steps
- Lead with the outcome, not the work. "User can reset password via email" describes the result. "Add password reset endpoint" describes the work. Cards live longer when written as outcomes — the work changes; the outcome usually doesn't. Atlassian's primer on writing user stories covers the same idea from a different angle, and there's more on the Pivotal Labs pattern in the LiteTracker note on principles of effective story writing.
- Estimate in points, not hours. If it's a user story, give it 1, 2, 3, 5, or 8 points. If you can't decide between 3 and 5, the card is probably two cards. Martin Fowler's note on story points explains why relative sizing tends to hold up better than hours, and there's a deeper write-up on splitting in choosing the best slice for your story.
- Write 2–4 acceptance criteria. Each one a single, testable assertion. "Email is sent within 30 seconds" is testable. "The flow is intuitive" is not.
- Pick one owner. Two-owner cards are how work goes invisible. If the work genuinely needs two people, split the card so each half has a single owner.
⚠️ Bug and chore cards skip step 2 entirely. Bugs are the original story coming back — they should be pointed if and only if you want velocity to lie to you. Chores are upkeep. Neither earns velocity credit. See bugs, chores: estimate, estimate for the long version.
Scrum task card checklist
Be sure to run the card past this before it enters the next sprint. Aim for minimally 5 of 7:
- Title is an outcome, not an action. "User can…" beats "Add…"
- Type is set. Story / Task / Bug / Chore — one of the four.
- Estimate present (stories only) and on the 1–2–3–5–8 scale.
- Owner is one person, not a list and not "TBD".
- Acceptance criteria are testable. A QA could write a check off each line.
- No hidden dependencies. If another card has to land first, it's referenced; if the dependency isn't on the board, the card isn't ready.
- Reads in under 30 seconds. If a new team member can't pick it up cold, it's overstuffed or under-specified.
If your cards routinely fail items 5 or 6, the problem is the refinement cadence, not the card schema.
Where scrum task cards break down
Three named failure modes, most common first.
⚠️ Field creep. Cards accumulate fields over months — a new field added for one tricky card never gets removed, then another, then another, and within a quarter the card schema requires twelve fields and nobody fills them. The fix is biannual schema review: every six months, drop any field used on less than 30% of cards.
⚠️ The acceptance-criteria escape hatch. Cards with one bullet of acceptance criteria — "works correctly" or "matches the design" — are unfinished. They will be argued about at sprint review. The fix is to require 2–4 specific bullets at refinement, before the card is pulled.
⚠️ Two-owner cards. Cards with two names attached are how work invisibly stalls. One person assumes the other is on it; the other assumes the first is. The fix is policy: one owner, full stop. If genuine collaboration is needed, split the card and let each owner finish their half.
💡 The reason these failure modes persist is that they look like rigour. More fields, softer acceptance criteria, and shared ownership feel inclusive, until you're staring at a board where nothing has moved in four days and nobody can tell you why.
LiteTracker leans into a deliberately small card schema for this reason. The product covers the 20% of features that drive 80% of the result, and skips the rest of the complexity that enterprise trackers accumulate. Less to maintain, less to argue about, faster to scan.
Capterra reviewers describe LiteTracker as "loved by XP/Scrum practitioners" — which is the audience this card schema is built for. Teams who came up through XP or Pivotal Labs already think this way. Teams migrating from heavier trackers usually have to unlearn the field-creep habit first.
Next steps
- A healthier approach to estimating and velocity — why points-on-stories-only stays honest as the team matures.
- Story blockers — the right way to surface dependencies on the board without overloading the card.
- Story tasks in Pivotal Tracker — how sub-tasks work when you actually need them.
Frequently asked
What information should be on a scrum task card?
A title (written as an outcome), a type (story / task / bug / chore), an estimate (stories only, on the 1–2–3–5–8 points scale), one owner, and 2–4 testable acceptance criteria. Skip everything else unless the team can name the cost of leaving it off.
What are the four types of scrum cards?
User story (user-visible feature, earns points), task (non-user-facing engineering work, no points), bug (defect, no points), and chore (maintenance with no user output, no points). Anything else is a special case of one of these four.
What colour should each card type be?
Convention: white or yellow for user stories, blue for tasks, red or pink for bugs, green for chores. The colour matters less than the consistency. Pick one mapping and stay with it.
How do you estimate a scrum task card?
Use Fibonacci-adjacent points (1, 2, 3, 5, 8) for user stories. Estimate relative size, not hours. If a card sits between two values, it's probably two cards.
Should bugs and chores be pointed?
No. Pointing bugs makes velocity look healthy while the team is rebuilding old work; pointing chores does the same. Only user-facing features that get accepted should earn velocity credit.
How many people should be assigned to one card?
One. If genuine collaboration is needed, split the card so each half has a single owner. Two-name cards are how work goes invisible.
Still stuck
If the card schema is small, the four types are working, and refinement is producing testable acceptance criteria, the system is doing its job. Tool choice is the last 10%.
If you'd rather work in a tracker that only lets you write cards this way (one owner, four types, points on stories only), that's what LiteTracker is for. Free tier, no time limit, no per-seat cost. If your current board is doing the job, keep it. We'd rather not be a switching cost you don't need.