If you join almost any modern company, you’ll be swept into a world of standups, sprints, backlogs, and retros within a week — usually with no explanation. People will ask “what’s your sprint capacity?” and expect an answer. Here’s the map of how Agile teams actually work, so you can follow along from day one.
Agile: the mindset
Agile is a philosophy for getting work done. Instead of planning an entire project in detail up front and delivering it all at the end (the old “waterfall” approach), Agile teams work in small increments, deliver frequently, get feedback, and adjust as they go.
The core bet is that you can’t plan everything perfectly in advance, so it’s better to build a little, learn, and adapt — repeatedly. Agile values working results over exhaustive documentation, and responding to change over rigidly following a plan.
Agile itself is just principles. To do Agile, teams adopt a framework — and the most common one by far is Scrum.
Scrum: the framework
Scrum is a specific way of organizing Agile work. It defines roles, a rhythm, and a set of recurring meetings (called “ceremonies”). The whole thing revolves around the sprint.
Sprints
A sprint is a fixed, short period of work — usually one to four weeks (two is most common). The team commits to completing a specific set of work within that window, and at the end they should have something done and potentially shippable. Then the next sprint begins. Work moves in a steady drumbeat of these cycles.
The backlog
The backlog is the master to-do list — every feature, task, fix, and idea, prioritized. The product backlog is everything that might get done; the sprint backlog is the subset the team has pulled in for the current sprint. Work flows from backlog → sprint → done.
The ceremonies
Scrum runs on a handful of recurring meetings:
- Sprint planning — at the start of a sprint, the team decides what to take on from the backlog.
- Daily standup (or “daily scrum”) — a short (≈15 min) daily check-in where each person covers what they did yesterday, what they’re doing today, and any blockers. It’s called a standup because it’s meant to be quick enough to do standing up.
- Sprint review — at the end, the team demos what they completed to stakeholders.
- Retrospective (“retro”) — the team reflects on how the sprint went and what to improve next time. The review is about the product; the retro is about the process.
The roles
Scrum defines three: the Product Owner (decides priorities and owns the backlog — represents the business/customer), the Scrum Master (facilitates the process, removes blockers, keeps the team unblocked — not a traditional boss), and the Development Team (the people doing the work).
How it all fits together
Items live in the backlog → the team pulls some into a sprint during planning → they work through it with daily standups → at the end they review what’s done and run a retro → repeat.
That loop, over and over, is Scrum in a sentence.
A few related terms you’ll hear
- Story / user story — a unit of work written from the user’s perspective (“As a user, I want to reset my password”).
- Story points — a rough estimate of effort/complexity for a task, used instead of hours.
- Velocity — how many points a team typically completes per sprint; used to forecast.
- Kanban — an alternative Agile approach using a continuous board of columns (To Do → In Progress → Done) instead of fixed sprints.
- Blocker — anything stopping you from making progress; standups exist largely to surface these.
How to use the vocabulary
- “Let’s add that to the backlog and prioritize it next sprint.” (not now, but tracked)
- “I’m blocked on the API access — flagging it at standup.” (surfacing an obstacle)
- “We’ll demo it at sprint review on Friday.” (showing finished work)
- “Good point for the retro — our estimates keep running over.” (improving the process)
Once the sprint rhythm clicks, the jargon stops sounding like a foreign language and starts sounding like, well, just how work gets done.