The problem Agile was built to solve
Before Agile, "waterfall" planning tried to define an entire project's requirements upfront, build for months, then deliver at the end — which worked poorly whenever requirements changed mid-project, which they almost always did. Agile's core idea is to work in short cycles, get real feedback constantly, and adjust direction based on what's actually learned rather than what was guessed at the start.
Sprints: a fixed, short cycle
A sprint is a fixed time box — commonly two weeks — during which a team commits to completing a defined set of work. At the end, there's a working, demoable increment of the product, not just a pile of half-finished pieces. The fixed length is deliberate: it forces regular checkpoints rather than letting "almost done" drift indefinitely.
The standup: fifteen minutes, not a status report
A daily standup is meant to answer three things quickly, for the team's benefit, not a manager's: what did I do yesterday, what am I doing today, and what's blocking me. It's not meant to be a detailed status report or a place to solve problems in depth — those get taken offline by whoever's affected.
Story points: relative, not absolute
Task: "Add password reset flow" → 5 points
Task: "Fix typo in footer" → 1 pointStory points estimate relative effort and complexity, not hours — a 5-point task isn't "5 hours," it's "roughly five times the effort of a 1-point task," accounting for uncertainty and complexity as well as raw time. This is deliberately imprecise; teams calibrate over a few sprints by comparing new tasks to past ones they've already sized.
The backlog and prioritization
The product backlog is an ordered list of everything that could be built, with the highest-priority items at the top, ready to pull into the next sprint. A well-run backlog is continuously groomed — refined, re-prioritized, broken into smaller pieces — rather than left as a stale wishlist nobody revisits.
Retrospectives are where actual improvement happens. At the end of each sprint, the team discusses what went well, what didn't, and picks one or two concrete changes to try next sprint. Skipping this — treating Agile as just standups and sprints with no retrospective — is a common way teams end up "doing Agile" in name without getting the actual benefit of continuous improvement.
Agile isn't one specific process
Scrum, Kanban, and other frameworks are all specific implementations of the same underlying Agile values (individuals over processes, working software over documentation, responding to change over following a rigid plan). The ceremonies above are common to Scrum specifically — the point is always the values behind them, not treating the ceremonies as the goal in themselves.
Comments