The Agile Glossary

Clear, honest definitions
of Agile terms.

No jargon, no hand-waving. Written by practitioners, for leaders.

Jump to section
A
Agile
A mindset and approach to delivery that values responsiveness to change, collaboration, and regular feedback over fixed plans and command-and-control. Agile is not about sprints or standups. Those are tools. It's about how you think, decide, and learn together.
Why it matters: Agile isn't a checkbox. If your teams run ceremonies but don't respond to change or collaborate, you're just going slower with more meetings.
Acceptance Criteria
The specific, testable conditions that define when a user story is complete and ready for release. They answer the question: "How do we know this work is done?"
Why it matters: Clear acceptance criteria prevent ambiguity and the endless "but is it really finished?" conversations. They're the difference between done and actually done.
B
Backlog
The prioritised list of work (features, bugs, improvements) waiting to be done. It isn't a dumping ground for every idea anyone has ever had. It's your intentional queue of what matters most.
Why it matters: A well-maintained backlog is your competitive advantage. It focuses effort and prevents teams from chasing every shiny distraction.
Burndown Chart
A visual graph showing the amount of work remaining in a sprint over time. The line should trend downward as the team completes tasks. If it's flat or spiking up, you have a problem.
Why it matters: A burndown is a leading indicator, not a report card. It tells you on day two if you're tracking to finish, so you can adjust before day nine.
C
Ceremony
A regular meeting or ritual in Agile (standups, planning, retrospectives, reviews). Well-designed ceremonies create rhythm and a space for collaboration. Poorly run ceremonies are just noise.
Why it matters: The best teams protect their ceremonies fiercely. The worst teams treat them as optional and wonder why nothing improves.
Continuous Improvement
The practice of making small, regular adjustments to processes and ways of working based on what you learn. Forget big transformation events. This is about incremental change, every week.
Why it matters: Small improvements, done consistently, compound into massive gains. One small fix every sprint beats zero fixes and one massive "transformation" every three years.
D
Daily Standup
A 15-minute meeting where the team syncs on progress, blockers, and what's next. It isn't a status report for a manager. The team talks, the team unblocks itself.
Why it matters: A good standup surfaces problems on day one, not day eight. A bad standup is just people listening to each other talk for 30 minutes while checking email.
Definition of Done
The team's shared agreement on what "complete" means. It might include code review, testing, documentation, and deployment readiness. Whatever your team needs to say "this is genuinely ready."
Why it matters: Without a Definition of Done, "done" is whatever the person asking thinks it means. That's chaos.
E
Epic
A large, multi-sprint piece of work that's too big to fit in one sprint. It's broken down into smaller user stories. Think of it as a strategic goal that takes weeks or months to deliver.
Why it matters: Epics give you a narrative arc. They show your teams (and stakeholders) how short-term work adds up to something meaningful.
Estimation
The process of predicting how much effort a piece of work will take. Most teams use story points (relative sizing) or time-based estimates. The goal isn't precision. It's a shared understanding of effort and risk.
Why it matters: Estimation is about building shared language, not predicting the future. The conversation matters more than the number.
F
Feature
A complete, deliverable piece of product functionality that provides value to users. Features are made up of user stories and are what actually get shipped to customers.
Why it matters: Features are what matter to your bottom line. Stories, tasks, and ceremonies are just the machinery that builds them.
I
Iteration
A fixed time-box (usually a sprint) where the team completes a defined chunk of work, reflects, and adjusts. It's the heartbeat of Agile: regular, predictable cycles of build, learn, improve.
Why it matters: Iterations turn long projects into short cycles. That means you get feedback, course-correct, and win faster.
Increment
The potentially shippable product that results from one sprint. It isn't a complete release. It's a slice of value, ready to go live and provide real user benefit.
Why it matters: If you can't ship your increment, your sprint isn't really done. This is how Agile turns projects into continuous delivery.
K
Kanban
A visual workflow management approach where work moves through columns (To Do → In Progress → Done) with explicit limits on how much can be in progress at once. It's Agile without fixed sprints, and work pulls through continuously.
Why it matters: Kanban shows bottlenecks instantly. When a column is blocked, everyone sees it. No waiting for the sprint review to say "we got stuck."
P
Product Owner
The single person accountable for the product vision, backlog prioritisation, and saying "yes" or "no" to features. They sit between stakeholders and the team, translating business needs into work.
Why it matters: A strong Product Owner is the force multiplier. Without one, the team gets pulled in five directions at once.
Product Backlog
The authoritative, prioritised list of everything that could be built: features, improvements, bugs, research. It's owned by the Product Owner and continuously refined.
Why it matters: Your backlog is your strategy made visible. Show me your backlog and I'll tell you what you actually believe matters, not what you say matters.
Planning Poker
A team estimation technique where everyone privately chooses a number, then reveals simultaneously. It prevents anchoring (one person's number influencing everyone else) and sparks healthy discussion.
Why it matters: The conversation during Planning Poker is where risks get surfaced and the team builds shared understanding. The number is just the artifact.
R
Retrospective
A regular meeting where the team reflects on what went well, what didn't, and what to change next sprint. It's a formal space to say what needs to change.
Why it matters: The one ceremony that actually drives improvement, if done right. Teams that run good retros get noticeably better every sprint. Teams that skip them get stuck.
Release Planning
The process of working out when and how to ship a set of features to users. It includes understanding dependencies, estimating effort, and planning the rollout.
Why it matters: Release planning is where you stop being theoretical and start being real. It's where "we'll be done in Q3" either holds up or falls apart.
S
Sprint
A fixed time-box (usually two weeks) where the team commits to finishing a defined set of work. The sprint starts with planning, ends with review and retrospective, and runs at the same pace every cycle.
Why it matters: Short cycles mean early warnings, not late surprises. If you're tracking to miss a sprint commitment, you know on day three, not day nine.
Scrum
A specific, structured framework for Agile delivery. It prescribes sprints, specific roles (Product Owner, Scrum Master, team), and ceremonies (planning, standup, review, retrospective). It's one way to be Agile, not the only way.
Why it matters: Scrum is a great starting point for structure, but it's not gospel. The best teams use Scrum as a foundation and adapt it to what actually works for them.
Scrum Master
The person who facilitates the team's Scrum process, removes blockers, and protects the team from interruptions. They're a coach and servant leader, not a project manager or tech lead.
Why it matters: A great Scrum Master makes the team faster, more autonomous, and more protective of their time. A bad one is a time-sink with a fancy title.
Stakeholder
Anyone who has an interest in or is affected by the product: executives, customers, support teams, other teams. Stakeholders care about outcomes; the delivery team cares about delivery. Both matter.
Why it matters: If stakeholders aren't aligned, the team will bounce between competing priorities. The Product Owner's job is to keep stakeholders synced.
Story Points
A relative sizing scale (often Fibonacci: 1, 2, 3, 5, 8, 13) used to estimate user stories. A story with 5 points is roughly five times more complex than a 1-point story. Story points measure relative effort, not hours.
Why it matters: Story points let teams forecast without pretending they can predict the future. They're a shared language for "how hard is this really?"
Sprint Review
A ceremony at the end of the sprint where the team shows completed work to stakeholders and gathers feedback. It isn't a status report. It's a chance to inspect the increment and get real reactions.
Why it matters: Sprint reviews are your reality check. Early feedback beats discovering six weeks in that you built the wrong thing.
T
Time-boxing
Setting a fixed, maximum time for a meeting or activity. When the time is up, you stop, done or not. It forces prioritisation and prevents endless discussions.
Why it matters: Time-boxing is how Agile teams stay fast. Without it, your standup becomes a problem-solving session and your day disappears.
U
User Story
A short, user-focused description of a feature from the perspective of the person using it. Format: "As a [user type], I want [capability], so that [benefit]." It's a placeholder for a conversation, not a detailed spec.
Why it matters: User stories keep the team focused on delivering value to actual humans, not just ticking boxes on a feature list.
V
Velocity
The number of story points the team completes, on average, per sprint. It's a measure of delivery rate. Track it to forecast future capacity, not to judge team performance.
Why it matters: Velocity tells leaders what the team can realistically deliver, so you stop asking "when will it be ready?" without data. It's a forecasting tool, not a performance metric.
Got a term you'd like us to explain?

Or a definition you disagree with? Get in touch. We'd love to hear from you.

Understanding Agile

The glossary helps you understand Agile.
We help you make it work.

Move from stuck to thriving. 90 minutes a week. Shaped around your reality.

Book a conversation