Ask ten companies if they "do Scrum" and ten will say yes. Watch how they actually work and you'll see ten different things. That's not necessarily wrong — Agile was always meant to be adapted — but it creates a quiet problem: people use the same words to mean different things, and a team can't run well when "story," "done," or "3 points" means something different to each person in the room.
This guide fixes that. It's a shared, practical mental model for everyone on a software team — BA, PO, PM, developer, QA, designer, newcomer — covering what each piece really means, how it's meant to work, how teams commonly customize it, and how to operate it well. Read it once and you'll understand the board, the ceremonies, the estimates, and the charts well enough to contribute from day one.
Agile is a mindset — a set of values (working software over documentation, responding to change over following a plan, people over process). Scrum is one specific framework for being Agile, with defined roles, events, and artifacts. You can be Agile without Scrum; you can also "do Scrum" mechanically and not be Agile at all. Most companies run a customized Scrum, sometimes called "Scrum-but" ("we do Scrum, but we skip retros…"). Some customizations are healthy; some quietly break the system. We'll flag which is which.
The work-item hierarchy: epic, story, task, sub-task
Everything on the board is a "work item," and they nest from big to small. The names vary by tool (Jira, Azure DevOps, Linear), but the idea is universal:
| Level | What it is | Typical size |
|---|---|---|
| Initiative / Theme | A large business goal spanning quarters (optional, top level) | Months |
| Epic | A big chunk of value, too large for one sprint — a feature area | Weeks / several sprints |
| User Story | A small, valuable slice from the user's point of view; fits in one sprint | Hours to a few days |
| Task | A unit of work needed to deliver a story (often technical) | Hours |
| Sub-task | A further breakdown of a task, for clarity or splitting among people | ≤ a few hours |
Two more item types you'll see everywhere:
- Bug — something that doesn't work as intended. Sized and prioritized like other work.
- Spike — a time-boxed research/investigation item when you don't yet know enough to estimate the real work.
A story is the unit of value (it delivers something a user or stakeholder cares about); a task is the unit of work (how the team builds it). If a "story" has no user value and is purely technical, it's probably a task. If an "epic" could finish in a sprint, it's probably a story. Keeping these levels honest is what makes the board readable.
The user story: format, INVEST, and acceptance criteria
A user story isn't a mini-spec — it's a promise of a conversation, captured in a simple, human format:
As a [type of user], I want [a capability], so that [a benefit].
Example: "As a returning shopper, I want to save my cart, so that I can finish checkout later."
A good story follows INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable. And it carries acceptance criteria — the concrete conditions that make it "done right," written so QA and the PO can verify them:
- Acceptance criteria answer "how do we know this story works?" — often as a checklist or in Given / When / Then form. They are the contract for the story.
- Definition of Ready (DoR) — the bar a story must meet before the team commits to it (clear, estimated, criteria written, dependencies known).
- Definition of Done (DoD) — the bar that applies to every story (coded, reviewed, tested, merged, documented…). DoD is team-wide and non-negotiable; it's the single best defense against "done… but not really done."
Status workflow: how the board really moves
The board's columns are the team's actual process made visible. A common flow:
| Status | Means | Who moves it |
|---|---|---|
| Backlog | Captured, not yet planned for a sprint | PO |
| To Do | Committed for this sprint, not started | Team |
| In Progress | Actively being worked on | Assignee |
| In Review / Code Review | Built, awaiting peer review | Assignee → Reviewer |
| In Testing / QA | Reviewed, being verified against acceptance criteria | QA |
| Done | Meets the Definition of Done | QA / PO |
Update status in real time — a board that's only right at standup is a board nobody trusts. And respect WIP limits (work-in-progress): the fewer items "In Progress" at once, the faster things actually reach Done. Starting everything finishes nothing; the goal is to stop starting and start finishing.
Story points & estimation: the most misused idea in Scrum
Story points estimate the relative size of work — its effort, complexity, and uncertainty combined — not the hours it takes. The team picks a small story as a reference ("this is a 2") and sizes everything against it, usually on a Fibonacci-like scale (1, 2, 3, 5, 8, 13).
Why relative points instead of hours? Because humans are bad at absolute time estimates but good at comparisons ("this is about twice that"). Points also stay stable as people get faster, and they let the team measure velocity — the points completed per sprint — to forecast realistically.
The team estimates together: everyone privately picks a number, reveals at once, and the high and low voters explain their reasoning. The discussion — not the number — is the real value; it surfaces hidden complexity and shared understanding. Re-vote until close enough. A story bigger than ~13 should be split, not estimated.
1. Treating points as hours ("1 point = 1 day") — this throws away everything points are good for. 2. Using velocity as a performance metric or comparing it between teams — this guarantees point inflation and gamed numbers. 3. Estimating to commit-and-punish rather than to plan. Points are a planning tool for the team, not a productivity score for managers. The moment they become a target, they stop being useful.
Estimating time & logging work — honestly
Many teams (especially those reporting to clients or finance) also track time alongside points. Done well, it forecasts and protects the team; done badly, it becomes surveillance that corrupts the data. The honest version:
- Original Estimate — the team's best initial time guess for a task. Set once, don't keep "correcting" it to look accurate.
- Time Logged / Work Logged — actual time spent, recorded as you go (not reconstructed from memory at week's end).
- Remaining — honest time left; this is what feeds the burndown.
Log time to understand flow and improve estimates, never to rank people. Estimate at the task level (hours), size at the story level (points) — they serve different purposes. And tell the truth: a logged "8h" that was really 3h of work and 5h of meetings teaches the team nothing. Data is only useful if it's honest, and it's only honest if it's safe to be honest.
The ceremonies: what each one is for
Scrum's events aren't meetings for their own sake — each has a single job. Run them with that job in mind and they're invaluable; run them on autopilot and they become the meetings everyone resents.
| Event | Its one job | Timebox |
|---|---|---|
| Sprint Planning | Agree what the team will deliver this sprint, and a rough plan for how | ~2h per week of sprint |
| Daily Standup | The team re-syncs and surfaces blockers for the day — not a status report to a manager | ≤ 15 min |
| Backlog Refinement | Clarify, split, and estimate upcoming stories so planning is smooth | ~1h / sprint, ongoing |
| Sprint Review / Demo | Show working software to stakeholders and gather feedback | ~1h per week of sprint |
| Retrospective | The team improves how it works — what to keep, drop, try | ~1–1.5h / sprint |
The classic three questions — what did I do, what will I do, any blockers — are a starting point, not a ritual to recite. Better teams "walk the board" right-to-left (focus on items closest to Done) and talk about the work, not each person. If two people need to go deep, take it offline ("let's park that"). It's a sync, not a meeting to solve everything.
The retrospective is the engine of "continuous improvement" — it's the meeting that improves all the other meetings. Skipping it (the most common "Scrum-but") means the team repeats the same mistakes forever. Keep it safe, blameless, and end with 1–2 concrete action items with an owner, not a long wish-list nobody acts on.
The charts: what they actually tell you
Agile charts are feedback instruments, not report cards. Read them as questions to ask, not verdicts to deliver.
| Chart | What it shows / what to watch |
|---|---|
| Sprint Burndown | Work remaining vs. time left in the sprint. A flat line means work isn't getting to Done; a cliff at the end means status isn't updated in real time. |
| Burnup | Work completed vs. total scope. Its strength: it makes scope creep visible (the top line rising mid-sprint). |
| Velocity chart | Points completed per sprint over time. Use it to forecast and spot trends — never to compare teams or as a target. |
| Cumulative Flow (CFD) | Items in each status over time. Widening bands reveal bottlenecks (e.g., a growing "In Review" column). |
The moment a chart is used to judge individuals, the team optimizes the chart instead of the work — padding estimates, gaming status, hiding problems. Healthy teams use charts to find where the process hurts, fix it together, and move on.
Who does what: the three Scrum roles (and where BA/QA fit)
| Role | Owns |
|---|---|
| Product Owner | The what and why: backlog, priorities, value, acceptance. Maximizes outcome. |
| Scrum Master | The how-we-work: facilitates events, removes blockers, coaches the process. A servant-leader, not a boss. |
| Developers (the Dev Team) | The how: self-organizing, cross-functional, owns building and the Definition of Done. In modern Scrum, "Developers" includes engineers, QA, designers — everyone who builds the increment. |
BA and QA usually sit within the development team: the BA sharpens stories and acceptance criteria with the PO; QA defines and verifies quality. Project Managers, where they exist alongside Scrum, typically handle budget, stakeholders, and dependencies outside the sprint — not the day-to-day team direction.
What's standard, what teams customize, and what actually breaks it
No real team runs textbook Scrum, and that's fine. The skill is knowing which adaptations are healthy and which quietly remove the thing that made it work.
| Healthy customization ✅ | Customization that breaks it ❌ |
|---|---|
| Adding board columns (In Review, QA) to match real flow | Dropping the retro — the team stops improving |
| Mixing Scrum + Kanban ("Scrumban") for flow-heavy work | Standup turned into a status report to a manager |
| Right-sizing sprint length (1–3 weeks) to the team | Using velocity / points to rank or compare people |
| Tracking time when the business genuinely needs it | Changing sprint scope mid-sprint on a whim |
| Lightweight tooling that fits the team | A PO who isn't available to answer questions |
Scrum works in fixed time-boxes (sprints) with committed scope — great for product work with planning rhythm. Kanban is continuous flow with WIP limits and no sprints — great for support, ops, and unpredictable work. Scrumban blends them. Pick the one that matches how your work actually arrives, not the one that's fashionable.
Key takeaways
- Agile is the mindset; Scrum is one framework. Most teams run a customized version — that's fine, as long as everyone shares the same definitions.
- Hierarchy: Epic (weeks) → Story (a slice of user value, one sprint) → Task (unit of work) → Sub-task. Story = value, task = work.
- Stories use "As a… I want… so that…", follow INVEST, and live or die by clear acceptance criteria and a team-wide Definition of Done.
- Story points are relative size, not hours. Estimate together (Planning Poker); never use velocity to rank people.
- Log work honestly to improve estimates and flow — never as surveillance. Tasks in hours, stories in points.
- Each ceremony has one job: plan (planning), sync (daily), clarify (refinement), show (review), improve (retro). Never skip the retro.
- Charts measure the system, not people. Burndown, burnup, velocity, CFD are there to find where the process hurts.
- Customize wisely: match the framework to how your work arrives — and keep the parts (DoD, retro, an available PO) that make it actually work.
You don't need to be a certified Scrum Master to work well in an Agile team — you need a shared, honest understanding of what the words mean and what each ritual is for. When everyone on the team reads the board the same way, estimates for the same reasons, and treats the ceremonies as tools rather than obligations, the process fades into the background and the work flows. That's the real goal of all of this: not "doing Scrum correctly," but building good software together, sustainably — and improving a little every sprint.