Contents
If you have ever sat in a development planning meeting, you have probably heard: “this task is five story points,” “let’s add it to the backlog,” “we won’t finish it this sprint,” “our velocity dropped,” “we need planning poker.” To a newcomer, it sounds like a separate dialect. Behind the jargon are simple ideas: short work cycles, a transparent task list, relative complexity estimates, and regular feedback from stakeholders.
Key takeaways
Agile is a set of values; Scrum is one way to apply them. The Agile Manifesto (2001) explains why to change how you build software; Scrum adds roles, events, and artifacts — how a team organizes work.
Story points are not hours. They are a relative estimate of volume, complexity, uncertainty, and risk. Two eight-hour tasks can get different points if one is well understood and the other is not.
Velocity is a team metric, not a people metric. It shows how many story points a team typically completes per sprint. Comparing velocity across teams is meaningless — each team uses its own scale.
The backlog is the single source of truth for work. The Product Backlog is everything that might be done; the Sprint Backlog is what the team committed to in the current cycle.
Process serves the product. Daily scrums, reviews, and retrospectives are not bureaucracy — they help you ship value faster and improve how you work.
Where Agile came from
Problems with waterfall
Before Agile spread widely, most projects followed waterfall: requirements → design → development → testing → deployment. Each phase was “closed” with documents, and going back was expensive.
Software reality is different: requirements change, markets react, users only understand the product after early releases. After a year of development, a customer could get exactly what the spec asked for — and realize it is not what they need now.
The Agile Manifesto
In 2001, seventeen practitioners published the Agile Manifesto. Four values (paraphrased):
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
Twelve principles follow: short iterations, frequent delivery, self-organizing teams, regular reflection. Agile does not eliminate planning — it makes planning continuous and adaptive.
What Scrum is
Scrum is the most common Agile framework for product teams. It does not prescribe how to write code, but it defines a minimal scaffold: three roles, five events, three artifacts.
Roles
The Product Owner (PO) owns product value. They build and prioritize the Product Backlog, translate business goals into backlog items, and accept sprint outcomes. The PO is not “the developers’ boss” — they represent user and business interests.
The Scrum Master owns the process: removes impediments, facilitates events, coaches the team on Scrum. This is not a classic project manager or tech lead — more of a service role for the team.
The Development Team is a cross-functional group that creates a product increment. At the process level, Scrum does not split “coders” from “testers” — the team owns the sprint result together.
Sprint — the heart of Scrum
What a sprint is
A sprint is a fixed timebox during which the team delivers a “Done” increment. Typical length: one, two, three, or four weeks — two weeks is most common.
Scope should not change arbitrarily mid-sprint. If urgent work appears, the PO and team deliberately decide what to drop or defer — not “add on top with no trade-off.”
Why sprints matter
Short cycles create a predictable rhythm: plan → work → demo → improve the process. Requirement mistakes surface in weeks, not quarters. Stakeholders see progress regularly, not only at a “big release.”
A typical sprint cycle
- Sprint Planning — what we will do and how.
- Daily Scrum — short sync (usually 15 minutes).
- Execution.
- Sprint Review — show the result.
- Sprint Retrospective — improve how we work.
- Next sprint.
Backlog and user stories
Product Backlog and Sprint Backlog
A backlog is an ordered list of everything the product needs or might need.
The Product Backlog is the master list: features, bugs, tech debt, spikes (research). The PO constantly refines and reorders it.
The Sprint Backlog is a subset of the Product Backlog plus the team’s plan for the current sprint — only what the team committed to this cycle.
Example Product Backlog items:
- Sign in with Google.
- Export report to Excel.
- Speed up catalog page by 30%.
- Fix VAT calculation bug.
User story
A user story describes a user need, not an implementation. Classic template:
As a [role]
I want [action]
so that [outcome / value]
Bad: “Add an export button.”
Good: “As an accountant, I want to export a report to Excel so I can send it to my tax advisor.”
Stories include acceptance criteria — testable conditions for “done from the user’s perspective.” That bridges PO and team at verification time.
Story points and planning poker
What a story point is
A story point is a relative estimate of task difficulty. It is not:
- hours or days;
- money;
- individual developer productivity.
Estimates consider:
- volume of work — steps and parts of the system touched;
- technical complexity — non-standard integrations, legacy code;
- uncertainty — vague requirements, poor API docs;
- risk — external dependencies, data migrations.
Example. “Change button label” — 15 minutes, minimal complexity → 1 SP. “Integrate a new payment gateway” — maybe 8 hours but unknown docs and risks → 13 SP.
Why story points are not time
Two tasks may take the same calendar time but differ in complexity. Task A: familiar CRUD, known stack, no risk. Task B: same code size but unknown third-party API behavior and likely requirement changes. Task B gets more points even if “hours on the calendar” match.
Fibonacci sequence
Teams often use 1, 2, 3, 5, 8, 13, 21, 34. Larger tasks carry more uncertainty — the gap between 1 and 2 is small; between 21 and 34 is a different order of magnitude. High estimates signal: decompose the work.
Planning poker
Planning poker is a team estimation technique:
- Read the user story.
- Each person secretly picks a card with a point value.
- Everyone reveals at once.
- Discuss outliers (especially min and max).
- Re-vote until consensus or a narrow range.
It reduces “authority bias” and surfaces hidden risks — a junior may see a trap a senior missed.
Velocity and work hierarchy
Velocity
Velocity is how many story points the team completed (per Definition of Done) in a sprint. Example: sprints of 30, 35, and 40 SP → average velocity ≈ 35 SP/sprint.
Velocity helps forecast: “with this backlog and velocity, release X takes N sprints.” It is not a KPI to punish the team or compare two teams — their point scales differ.
Epic, feature, story, task
On large products, work is grouped:
| Level | Meaning | Example |
|---|---|---|
| Epic | Large business goal | “Online payments system” |
| Feature | Major capability | “Pay by credit card” |
| User story | User need | “As a customer, I want to pay by card…” |
| Task | Technical step | “Create payments table,” “Checkout API” |
Epics decompose into stories; stories into tasks in the Sprint Backlog. Feature vs epic boundaries vary by company — the hierarchy matters more than Jira label names.
Definition of Ready and Definition of Done
Definition of Ready (DoR)
DoR answers: “Can we start development?” Typical criteria:
- clear description and acceptance criteria;
- dependencies known or resolved;
- no blocking open questions;
- estimated (if the team estimates before the sprint).
DoR reduces tasks stuck “In Progress” because requirements were unclear.
Definition of Done (DoD)
DoD answers: “When is it truly done?” Example for a production-ready team:
- code written and reviewed;
- unit/integration tests added and green;
- QA verified against acceptance criteria;
- docs/API updated;
- deployed to staging (or prod — per team policy).
DoD is a team agreement, not personal “I think it’s done.” Without shared DoD, velocity and “completed SP” lose meaning.
Sprint events: review and retrospective
Sprint review
At sprint end, the team demos a working increment to stakeholders — not slides saying “we almost finished.” Feedback is collected; backlog priorities update. Review is about the product, not the process.
Sprint retrospective
After review, the retrospective: what went well, what blocked us, what to try next sprint. One concrete improvement beats ten vague “communicate better” action items.
Daily scrum
The daily is not a status report to management — it is a plan for the next 24 hours: what I did, what I will do, what blocks me. Three questions are a template, not dogma; the goal is sync and early blocker detection.
Common Agile misconceptions
| Myth | Reality |
|---|---|
| Story points = hours | Points reflect complexity and risk, not calendar time |
| Velocity = developer KPI | Velocity describes the team and its scale |
| Agile = no documentation | You need enough documentation, not mountains of specs |
| Scrum fits everyone | Research, support, and strict compliance often fit Kanban or hybrids better |
| Agile = no planning | Planning happens every sprint and at roadmap level |
How the terms fit together
Typical flow:
- PO builds the Product Backlog from epics and user stories.
- At Sprint Planning, the team selects items into the Sprint Backlog.
- Stories are estimated in story points via planning poker.
- During the sprint, the team works toward Definition of Done.
- Velocity is measured at sprint end.
- Sprint Review shows value; retrospective improves process.
- Repeat.
FAQ
Can you convert story points to hours?
Some teams calibrate locally (“1 SP ≈ half a day”), but that is a local heuristic, not a property of points. Once points become hidden hours for controlling individuals, relative estimation loses its point.
How is Kanban different from Scrum?
Scrum uses fixed sprints and prescribed roles; Kanban is continuous flow with WIP limits and fewer prescribed events. Many teams use Scrumban: sprints plus a Kanban board.
How long should sprint planning take?
Depends on sprint length. From the Scrum Guide: up to 8 hours for a one-month sprint; for two weeks, teams often use 2–4 hours split into “what” and “how.”
Do you need a dedicated Scrum Master on a small team?
Startups often combine roles, but the functions remain: someone must protect team focus and process. Combining PO and SM in one person risks conflicting incentives.
What is a spike?
A spike is a timeboxed investigation (“learn how API X works”). The outcome is usually a decision and decomposition, not production code.
Further reading
Related posts on stuzhuk.page:
- Bulletproof React — frontend structure when the backlog grows
- UX and ROI: data over opinions — linking user stories to business value
- Database optimization strategies — tech debt in the backlog
- SEO, AEO, GEO, and AISO — prioritizing product visibility alongside features
External: Scrum Guide (2020), Agile Manifesto.
Conclusion
Agile is not trendy vocabulary or a cult of stand-ups. It is an attempt to make software delivery predictable, flexible, and transparent: short sprints, a shared backlog, relative estimates, regular feedback.
Remember the chain: Scrum organizes work, Sprint sets the rhythm, Backlog holds plans, User Story describes value, Story Points and Planning Poker help estimate, Velocity helps forecast, DoR/DoD align on readiness. Every tool exists for one reason: a product that helps users and the business.