Imagine a team spends a whole year building a piece of software behind closed doors. They write a 400-page specification up front, agree every detail, and disappear to code it. Twelve months later they proudly unveil the finished product — and the customer's business has moved on, three of the "essential" features are now useless, a competitor shipped the good idea eight months ago, and a feature nobody thought to ask for turns out to be the only one people actually want. Nobody was lazy. The plan was simply too big and too rigid to survive contact with reality.
This "build it all, then reveal it" style is the old waterfall way, and its failures gave rise to Agile: a different mindset for building software in small, quick steps, showing working software to customers often, and changing course as you learn. Instead of one enormous bet placed a year in advance, you place a dozen tiny bets and adjust after each one. Scrum is the most popular concrete recipe for working this way — the one you are most likely to meet in your first job. This page is about both: the Agile mindset, and the Scrum machinery that puts it into practice.
In 2001 a group of software developers, tired of heavyweight process, met and wrote the Agile Manifesto — four short value statements. Each has the same shape: it names two good things, and says that while both have value, the team leans towards the one on the left. It never says the right-hand item is worthless; it says when they pull against each other, prefer the left.
The engine that makes all four possible is iteration: instead of one long march, you work in short repeating cycles, and at the end of every cycle you have working software to show, feedback to absorb, and a chance to change direction. Everything else in Scrum is just a disciplined way of running those cycles.
No — and mixing them up is common. Agile is a mindset: the four values above and a set of principles. It doesn't tell you exactly what meetings to hold or what roles to create. Scrum is one specific framework that implements the Agile mindset with concrete rules — sprints, roles, and ceremonies. Kanban, Extreme Programming (XP) and others are alternative Agile frameworks. So every Scrum team is Agile, but not every Agile team uses Scrum. Think of Agile as the philosophy and Scrum as one popular playbook that follows it.
The heartbeat of Scrum is the sprint: a fixed, short block of time — most often two weeks — in which the team turns a chosen slice of work into a finished, potentially shippable increment of the product. The length is a timebox: it does not stretch. If the team planned more than fits, the work spills to the next sprint — the deadline never moves. This fixed rhythm is what makes a team predictable: every fortnight, like clockwork, there is something real to look at.
Where does the work come from? Two lists, and the difference between them matters:
A neat way to picture it: the product backlog is the whole shopping list for the year; the sprint backlog is the handful of items you actually put in the basket on this trip.
Scrum defines exactly three roles, and keeping them distinct is half the point. One person decides what is most valuable, one protects how the team works, and the team itself decides how much it can build.
Notice the two "end of sprint" ceremonies look inward and outward. The review asks "is the product right?" (facing the customer); the retrospective asks "is our teamwork right?" (facing ourselves). Doing both, every sprint, is how an Agile team improves the product and the way it builds it, continuously.
A stubborn misconception is that the daily stand-up is a status report to the boss — everyone lines up and justifies their day to the Scrum Master or manager. That is not what it is for. The stand-up is a short peer-to-peer sync so the team can coordinate itself: what did I finish, what am I doing next, and — most importantly — what is blocking me? The Scrum Master listens for blockers to clear, but the meeting belongs to the developers, not to a manager collecting excuses. Turn it into a status parade and people start reporting to the loudest person in the room instead of talking to each other, and its whole value evaporates. Related myth: Agile means no plan and no deadlines. In fact Scrum is full of plans and deadlines — every sprint is a hard timebox, planning happens continuously, and the backlog is a living plan. What Agile drops is the fantasy that one big plan made up front will survive a year unchanged. It plans little and often, not never.
How does a team know how much fits in a sprint? Estimating in hours is famously unreliable — people are terrible at it. So Agile teams estimate the relative size of a piece of work in abstract story points: a small, well-understood task might be 1 or 2 points; a big, fuzzy, risky one 8 or 13. A story is not "half a day", it is "about twice as big as that other story". Teams often use a rough Fibonacci-like scale (1, 2, 3, 5, 8, 13) because the gaps grow as the work gets bigger and vaguer — you can't meaningfully tell a 21 from a 22.
Over a few sprints a team measures its velocity: the number of story points it actually completes per sprint. If the last three sprints delivered 22, 26 and 24 points, roughly 24 points is a sensible amount to commit to next time. Velocity turns the abstract points into a real planning tool — not a target to be gamed, but a measured capacity that makes the team predictable.
Within a sprint, how do you tell at a glance whether you are on track? The classic tool is the burndown chart. The x-axis is the day of the sprint (here a 10-working-day, two-week sprint); the y-axis is the story points still remaining. Two lines are drawn:
Reading it is instant: when the actual line is above the ideal, there is more work left than planned — the team is behind. When it dips below, they are ahead. If it flattens out, nothing is getting finished (work half-done doesn't burn down). The goal is simply to reach zero by the end.
Let's make that chart concrete. A team commits to a sprint backlog of six stories, totalling 40 story points:
The ideal line falls by
Plot those remaining totals day by day and you get exactly the jagged actual line above: flat spots where nothing finished, and a big cliff on the last day when the 13-point story closed. The team was behind the ideal line for most of the sprint — a signal the Scrum Master would have spotted on day 4 and used to ask "what's blocking login, and is search too big to finish in time?"
Not necessarily! A burndown only moves when a whole story is finished. If the team spends three days deep inside one big, half-built feature, real progress is happening but the chart shows a flat line, because nothing has crossed the "done" finish line yet. This is actually a useful warning: a long flat stretch is a hint that stories are too big and should be sliced into smaller pieces that can each be finished — and burned down — in a day or two. Small stories make a smooth, honest burndown; giant ones make a cliff at the end and a lot of nail-biting.
Agile and Scrum are the default way modern software teams work, and you will almost certainly join one. Strip away the jargon and the whole thing is simple: build in small steps, show working software often, and change course as you learn. Scrum wires that up with a fixed rhythm (the sprint), a prioritised plan that is allowed to change (the backlogs), three clear roles, a handful of ceremonies that face both the customer and the team, and a burndown chart that makes progress impossible to hide. It is not the absence of planning — it is planning little, often, and honestly, so that reality gets a vote every two weeks instead of once a year.