Agile Glossary: Essential Terminology for Agile Teams

When you start learning about Agile, it feels like arriving in a foreign land. The people speak a strange language, keep time in story points, and their bible is a manifesto.

As you spend more time with the locals, you’ll notice subtle differences between its inhabitants, who speak in multiple, distinct dialects. Some use different terms to express the same concept, while others use the same word to mean different things.

To help you find your way around we’ve put together an Agile terminology overview, categorized in four sections:

We’ve organized terms alphabetically within each section, and you can jump to one by clicking on its name above. We’ve included popular words but also taken you off the beaten track with terms that aren’t well-understood but should be.

As any longtime resident of Agile-land will tell you, agile is a mindset above anything else. If you’re just getting started with Agile methodology, you could skip the ideas in this section and jump straight to the more practical ones further down, and you’d be fine, at least for a while. But to understand why people do things the way they do, you’ll need to understand the fundamentals.

In 2001, 17 developers met to define a better way of developing software. Out of that meeting came the Agile Manifesto. Its principles inspired teams around the world to create new practices for their day-to-day work. Some of the most important ones:

🤷‍♀️ Common confusion

Considering the broad influence it has, the Agile Manifesto is surprisingly concise and not at all prescriptive. If it were a map, it would show Agile’s location but give no directions on how to get there.

Several well-known frameworks like Scrum and Extreme Programming (XP) didn’t emerge from the manifesto. Instead, their creators were already working on these approaches in the ’90s. Their work inspired elements of the Agile Manifesto.

ℹ️ More info

An agile mindset means believing in the principles and values of the Agile Manifesto and viewing the world through that lens. Such a mindset conflicts with traditional project management and organizational approaches, like waterfall and Taylorism (scientific management).

In practice, having an agile mindset means you believe that:

🤷‍♀️ Common confusion

A metaphysical term like mindset easily evokes skepticism, especially in a world of managers who are used to concrete plans, numbers, and structures. But implementing agile processes without having an agile mindset is precisely why some agile implementations fail.

ℹ️ More info

An Agile principle is one of the 12 values defined in the Agile Manifesto. The most famous and influential ones are:

🤷‍♀️ Common confusion

Some Agile frameworks like Scrum define their own values, but those are not Agile principles in the literal sense of the word because they don’t stem from the Agile Manifesto. However, if you want to get really dogmatic, such principles can be considered agile – with a small “a” – in that they follow the spirit of the 12 agile principles from the manifesto.

ℹ️ More info

Cadence in Agile refers to a pace and process of work that is sustainable and repeatable. The idea stems from one of the 12 Agile principles:

The need for a sustainable cadence originates from finding an antidote against “crunch time” – last-minute rushes with lots of overwork that typify traditional software projects. Teams may define their cadence according to how long their Sprint is.

🤷‍♀️ Common confusion

Some teams find that Agile frameworks like Scrum lead to overwork as teams push hard to complete their work at the end of a Sprint. In such cases, the real problem is often that the team or organization follows agile processes but not its values. They might, for example, hold Scrum meetings but the cadence and pace of work is unsustainable, with too much work being bookmarked for each Sprint.

ℹ️ More info

Continuous improvement means looking for ways to improve work processes constantly. Jeff Sutherland, one of the creators of Scrum, sums it up in his book of the same name:

The practice of continuous improvement originates from the Toyota Production System – developed in the 1940s at Toyota in Japan – and Lean management. It is also known as “Kaizen” in Japanese, which literally means “good change.”

A concrete manifestation of this idea is the Sprint Retrospective meeting, which many Agile teams hold at the end of each Sprint or work cycle to reflect on their work together and find ways to remove impediments, reduce waste, and improve the work process.

Aaron Dignan, author of Brave New Work, sums up the need for continuous improvement beautifully:

ℹ️ More info

A team that has all the skills within the group to do its work. Such a composition reduces bottlenecks caused by dependencies on other teams. It also ensures a smooth flow of work since there’s no handover between groups.

For example, traditional companies often have Product, Marketing, and Sales departments. An agile organization with cross-functional teams instead has product, marketing, and sales experts within each group.

Related term: Self-managing team.

The concept of flow originates from research by psychologist Mihaly Csikszentmihalyi, who coined the term in his book of the same name. Flow is a state of mind in which we’re fully immersed in a challenging activity and lose our sense of time and surroundings. People usually enter flow in pursuit of a goal that stretches their abilities.

In Agile, Kanban primarily uses the idea of flow but more akin to its natural meaning of water flowing through a river, as per the definition author Daniel Vacanti gives in his book Actionable Agile Metrics for Predictability:

Many of Kanban’s practices aim to optimize flow. Placing a limit on the number of items a team can simultaneously work on is one example. Another is the Kanban board itself, which helps visualize a team’s workflow to make it easy to spot bottlenecks and unnecessary complexity in the work process.

🤷‍♀️ Common confusion

People might confuse Kanban’s use of flow with Csikszentmihalyi’s original definition. Such confusion happens when people are only familiar with using flow in reference to an individual’s ability to concentrate optimally instead of to work items flowing smoothly through a system, which is how Kanban employs it.

ℹ️ More info

See Continuous improvement

Lean is a working approach that maximizes customer value, empowers teams, reduces waste, and strives for continuous improvement. One key differentiator of Lean from other agile ways of working is the focus on just-in-time delivery. The concept originates from the Toyota Production System and it is to manufacturing what Agile is to software development.

These shared fundamentals are no coincidence. Lean practices inherited from the manufacturing industry have inspired many Agile principles and some of its most popular frameworks, like Scrum.

🤷‍♀️Common confusion

Lean is not an Agile framework, and you don’t have to choose between Lean or Agile management for your organization. When you’re working with one, you’re almost certainly using principles and practices from the other, too.

ℹ️ More info

Self-managed teams are collectives that decide together what they work on next, who works on it, when, and how, without interference from a manager. Some Agile frameworks like Scrum specifically prescribe that teams should be self-managed. The Agile Manifesto doesn’t, but two of its principles allude to it:

🤷‍♀️ Common confusion

The Scrum Guide used to refer to Scrum teams as “self-organizing,” which means they only get to choose how they accomplish their work. In 2020, the Scrum Guide was updated to say “self-managing” instead.

ℹ️ More info

See Cadence.

Technical debt is the price a team pay for building easier shortcut solutions now, over a stronger approach that takes longer to complete. Technical debt is the additional work that would have to be done in the future after choosing an easier solution. Usually, such debt manifests itself through bugs teams need to fix later or an architecture that doesn’t scale.

Technical debt is a significant term in Agile because many frameworks like Scrum and XP specifically aim to eliminate or minimize its accumulation, for example, by making QA testing and bug fixing part of the definition of done for a Sprint or a feature’s acceptance criteria.

Timeboxing is the practice of setting a hard time limit for specific activities. Timeboxing helps team members focus on completing tasks within a specific period of time. It is also often used to divide up portions of Agile meetings, to ensure everything gets discussed.

Timeboxing appears in several Agile frameworks in two ways:

ℹ️ More info

The term “working software” means a piece of software that can be used by the customer or end-user – as opposed to a static demo or visualization.

The term comes from the Agile Manifesto where one of the values is: “Working software over comprehensive documentation.” It suggests that frequently delivering value to external customers is preferable to having detailed documentation for internal stakeholders.

Many Agile concepts, processes, and deliverables stem directly from the idea of valuing working software, for example:

ℹ️ More info

Specific frameworks and models have emerged from the agile philosophy and mindset. Continuous iteration of work processes and the goal of delivering value to customers quickly and frequently is something they all have in common. But each one offers its own flavor of agile and is helpful under specific circumstances.

The above picture highlights the distinction between Agile frameworks, methodologies, and the philosophy itself.

Disciplined Agile Development (DAD) is a comprehensive collection of strategies and practices taken from agile frameworks and other methodologies like Lean and Waterfall. Think of it like an à la carte menu, whereas Scrum is a fixed three-course set menu.

DA gives teams the knowledge and tools to select agile practices and create a personalized approach for their situation. DA is much less prescriptive than most other frameworks. It’s a good option for organizations that find Scaled Agile Framework Enterprise (SAFe) too heavy and other scaled frameworks too light.

ℹ️ More info

DevOps deals with critical technical aspects of software development, including infrastructure (servers+networking), deployment (build+test+upgrade), and monitoring and QA (spotting bugs, security violations, performance issues, etc.).

Some people refer to DevOps as a framework or methodology. In reality, it’s closer to a discipline or skill set, like marketing or design.

DevOps is critical for agile software development because it supports teams in releasing working software to customers quickly and frequently. Doing so is only possible when the technical infrastructure and processes can accommodate that. DevOps – with its focus on infrastructure – enables that.

🤷‍♀️ Common confusion
Some people consider DevOps a framework, closely related to XP and Kanban. But, it’s more similar to a discipline. Adding DevOps to a list of Agile frameworks would be like comparing a framework like Scrum to a discipline like Design.

ℹ️ More info

Kanban uses a central board with columns to visualize a team’s workflow. In its most basic implementation, the board contains at least three columns: “Backlog,” “Work In Progress (WIP),” and “Done.” Cards representing deliverables move through those columns depending on their status. Team members pick a new item from the top of the Backlog column whenever they’ve finished their previous deliverable.

Kanban is more flexible than most other agile frameworks because you can add or reprioritize items at any time. Kanban suits teams that need to respond to incoming requests quickly or have fast-changing product requirements.

🤷‍♀️ Common confusion
Kanban is more than just a board with cards. It’s a framework with its own rules based on concepts like pull systems, queuing theory, and flow. When practising Kanban, for example, team members restrict the number of tasks in the “WIP” or “Doing” columns to avoid overload and highlight bottlenecks.

ℹ️ More info

In LeSS, numerous agile teams work as units to deliver a joint shippable product. For example, you’re building a comprehensive mobile app. In LeSS, each team is responsible for a separate part of the product, but the app gets released in one combined delivery at the end of each Sprint.

LeSS is a lightweight alternative to SAFe. It works well for organizations with many autonomous teams that already use the Scrum process and collaborate on one large product or deliverable. It makes Scrum easier to scale.

🤷‍♀️ Common confusion
Whereas regular Scrum teams use one Product Backlog per team, organizations using LeSS have one Product Backlog and one Product Owner for the entire product across all individual teams.

ℹ️ More info

SAFe is more prescriptive than other frameworks and provides a solution to the challenge of scaling Agile processes. It packages elements from Agile, Lean management, and systems thinking into modules.

(Source: scaledagileframework.com)

It also includes traditional management practices, like a quarterly planning process. SAFe leaves less room for experimentation within teams, which is why some Agile practitioners consider it just partially agile, and others think it’s anti-agile.

🤷‍♀️ Common confusion
SAFe is a huge and heavy framework. It often appeals most to people at the higher levels of an organization – executives and program managers because it offers a sense of control. However, that sense of control often comes at the expense of making teams and the organization truly agile.

ℹ️ More info

Scrum is the most popular Agile framework, used by 66% of Agile teams.

Within Scrum, teams work in cycles called Sprints that create a sustainable cadence of releasing small, valuable increments of work regularly. Scrum also leaves room for reflection and adaptation through Sprint Retrospectives, which help teams practice continuous improvement.

Scrum teams organize their members into three different accountabilities – developers who create the product, a Product Owner who prioritizes the work, and a Scrum Master who helps the team understand and practise Scrum.

Scrum’s lightweight framework gives teams enough instruction to get started quickly but not so much that it becomes overwhelming. It is a great way to get started with Agile, especially for smaller organizations.

🤷‍♀️ Common confusion
The terms Scrum and Agile are used interchangeably even by people who practice Scrum, fueling the confusion. Agile is about the why and what of improving software development, while Scrum is about the how.

ℹ️ More info

Scrumban combines Scrum and Kanban. There’s no “official” or prescriptive guide of what parts of Scrum and Kanban make up Scrumban, so it’s up to teams to pick the elements that serve them best.

Almost all teams adopting Scrumban tend to keep the Kanban board and limit WIP. Most Scrumban practitioners also introduce a work cycle that adopts Sprints and the other Scrum Events to create a rhythm.

Scrumban is an excellent fit for teams with Agile experience that feel Scrum is too rigid or Kanban too loose.

🤷‍♀️ Common confusion
Because there’s no formal guide on what is considered Scrumban and what isn’t, there are different interpretations of what it involves. Some claim a right or wrong way of doing Scrumban. Ignore such proclamations and do the work that matters to finding the elements from both approaches that work for your team and deliver the most value to your customers.

ℹ️ More info

The Spotify model differs from other frameworks by organizing teams into a matrix structure. Teams are called “Squads”, and they can choose their own Agile way of working, like Scrum or Kanban. Related Squads organize in larger groups called “Tribes”. Each Tribe has a Product Owner, Agile Coach, and Technical Leader.

To this structure of Squads and Tribes, the Spotify model adds “Chapters” and “Guilds”. These are groups of people with the same competency – like testers, marketers, or software developers.

The Spotify model is an alternative to SAFe because it’s not overly prescriptive but still provides sufficient guidance on structuring a large number of teams.

🤷‍♀️ Common confusion
The Spotify model has fierce critics because it was designed for a specific organization at a particular moment in time. Spotify itself has abandoned the model. But while copy-pasting the framework is a bad idea, other organizations, such as ING, have found a lot of value in the matrix structure of chapters and guilds.

ℹ️ More info

With Scrum of Scrums, each team keeps their existing Scrum elements – the Product Backlog, meetings, and accountabilities – but representatives of each team meet once per day in the so-called Scrum of Scrums. During this meeting, they discuss upcoming work to create a shared understanding at the group level and manage any dependencies between teams.

Scrum of Scrums suits teams that are outgrowing Scrum and need an extra layer of coordination between them, but not much else. Scrum of Scrums is great for organizations that want to maintain Scrum as far as possible on the individual team level.

🤷‍♀️ Common confusion
Scrum of Scrums differs from LeSS in that each team keeps its own Product Backlog, accountabilities, and meetings. Whereas in LeSS, multiple teams work with one shared Product Backlog and Product Owner.

ℹ️ More info

XP is an Agile framework that improves software development projects through a set of specific values and technical practices. Like Scrum, it emphasizes the inclusion of customers in the entire process, involves working in cycles of one to two weeks with frequent releases and planning sessions, and embraces standup meetings at the start of each day.

One of the essential differentiators of XP is pair programming. Teams with a mix of junior and more senior members, in particular, may find it valuable. XP pre-dates the Agile Manifesto.

🤷‍♀️ Common confusion
The most distinct values and technical practices that make XP different from Scrum are pair programming, test-driven development, and continuous integration.

ℹ️ More info

Day-to-day life and work for Agile teams revolves around specific accountabilities, different types of meetings, and streamlined work processes. Some of these differ per Agile framework or aren’t used at all in a particular model. But this list covers everything you need to know to understand Agile roles, meetings, and processes, whether you use them in your organization or not!

An acceptance test is a process that a stakeholder goes through to validate that a new feature works and behaves as expected before being released into production. Acceptance tests help teams pre-empt or identify any issues, and get feedback on the product from a customer or end-user perspective before it is launched.

🤷‍♀️ Common confusion
Acceptance tests are supposed to be done by the customer or end-user. They’re not internal tests or QA tests for finding bugs. Instead, they determine whether the team has built what the customer expected to receive.

Affinity estimation is a technique teams use to estimate how much effort a user story requires to complete. In affinity estimation, team members first rank user stories or other work items from large to small, or put them in different size buckets. Once that’s done, team members assign more specific estimates, like story points or T-shirt sizes. It’s an efficient approach for running through a large amount of unestimated Product Backlog items quickly.

🤷‍♀️ Common confusion
It’s common to confuse affinity estimation with relative estimation. But affinity estimation is a specific approach for doing relative estimation.

An antipattern is a seemingly obvious but wrong answer to a common problem. It’s an ineffective solution, often with negative consequences. A simple example is Death by Planning, the belief that more planning will lead to less risk and hence a better or more predictable project outcome.

Agile teams may do specific exercises to identify antipatterns or “bad habits” in their work. Agile Coaches or Scrum Masters may also do work with teams to de-bug embedded antipatterns.

The antonym of an antipattern is a design pattern, a straightforward, effective solution to a prevalent problem.

Backlog refinement is the process of managing, prioritizing, and adding detail to items on the Product Backlog using different prioritization and estimation techniques, such as T-shirt sizing, WSJF, or poker estimation. It’s an ongoing process in which the Product Owner and the Developers collaborate.

Backlog refinement helps teams develop a more detailed Product Backlog that includes all the necessary information to make each item sufficiently detailed.

During backlog refinement, many teams choose to add story point estimates and when individual Product Backlog items are too large, they may be broken down into smaller more manageable chunks with an easy-to-follow list of clearly defined tasks.

Backlog refinement gives teams clearer priorities, improved Sprint velocity, and a more realistic idea of how much work to take during each Sprint.

It’s up to your team can decide when to do backlog refinement, how often to hold refinement meetings, and what techniques you use to refine the backlog.

ℹ️ More info

A Ceremony is a fancy word for an Agile meeting:

The term ceremony encapsulates various Agile practices, from the Scrum Events, to practices like poker estimation or weekly cycle meetings from XP, or replenishment meetings in Kanban.

🤷‍♀️ Common confusion
It’s not entirely clear where the use of “ceremony” comes from in agile. Some say the Scrum Guide of 2011 replaced the term with “events”, while others – and our own research – suggest the word ceremony didn’t even appear in the first official Scrum Guide from 2010.

The only mention of “ceremony” is in the book Scrum by one of its creators, Jeff Sutherland. He uses it in reference to the “haka”, a Maori warrior ceremony the New Zealand All Blacks rugby team performs before every match.

To further add to the confusion, people often use “Agile ceremonies” when, in fact, they’re referring to the five Scrum Events, less the Sprint. 🤯

ℹ️ More info

Continuous integration is when developers integrate code into the team’s codebase at least once per day. While this seems like an inconsequential developer practice, it facilitates Agile principles.

When you integrate your code daily, you must break down your work into small chunks and can’t procrastinate. And when your team frequently releases the updated codebase to users, you enable quick feedback loops with customers on working software.

🤷‍♀️ Common confusion
People sometimes confuse continuous integration with continuous delivery. But with continuous delivery, the updated codebase for the entire product also gets released to end-users regularly.

ℹ️ More info

The Daily Scrum is one of the five official Scrum events. It’s a 15-minute meeting held every working day of the Sprint at the same time and place by the Development Team. Most teams stand up during the Daily Scrum to keep it short. That’s why so many refer to it as the Daily Standup meeting.

The Daily Scrum’s purpose is to keep the team focused on the Sprint Goal and reduce the need for other meetings. During the daily get-together, the team can exchange information about their work, adjust their plans, and engage in quick problem-solving to unblock each other

85% of agile teams hold a Daily Standup meeting, and, like in sports, the team should leave the huddle feeling energized and clear on strategy and tactics for the day’s “match”.

🤷‍♀️ Common confusion
Contrary to previous versions of the Scrum Guide, the 2020 edition doesn’t prescribe these three questions to ask during the meeting anymore:

Instead, it’s up to teams to decide how they want to structure their own Daily Scrum or Daily Standup meetings.

ℹ️ More info

A Definition of Done (DoD) specifies the standards every item in the Sprint Backlog must meet for the Increment to be considered done. It applies to all tasks or user stories that together form one Increment.

Here’s an example:

According to the Scrum Guide, “if a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.”

Teams usually set a DoD at the team level, but it’s good practice to apply the same DoD across multiple teams if they work on the same product.

🤷‍♀️ Common confusion
People often confuse Definition of Done and Acceptance Criteria, but DoD applies at the Product Backlog level and Acceptance Criteria applies to individual backlog items.

ℹ️ More info

An iteration is an execution cycle, something you repeatedly do. Often, when used without further context by some Scrum practitioners, an iteration refers to one Sprint.

🤷‍♀️ Common confusion
“Iteration” and “Increment” sometimes get confused. But, in Scrum, an Increment is a deliverable – a piece of working software –, which is the outcome of one iteration.

Pair programming is when two developers work together at one computer to solve problems and share knowledge. The concept originates from the Extreme Programming (XP) framework. Advocates of XP say this practice leads to higher-quality solutions and reduces mistakes because two minds think through problems instead of one.

In the book A World Without Email, long-time Silicon Valley programmer Greg Woodward says:

The reason, according to Woodward, is that together, you find better solutions to problems, which is the essence of programming, before you do the actual coding.

Planning poker is an agile task and project estimation method. Teams come together to estimate how large or small various work items are using a set of poker cards with various values assigned to them.
In planning poker, teams review a selection of user stories or tasks from the Product Backlog. Then each participant individually estimates how much effort that work item will involve by playing cards with different values from a customized deck.

Everyone chooses their card anonymously and then they are all revealed simultaneously. What follows is a discussion of everyone’s estimates so teams can get on the same page about the effort required to complete pieces of work. 58% of Agile teams report that they do some kind of poker estimation.  

ℹ️ More info

Product Owners develop and maintain the vision for the product – what problems it solves and for whom. The Product Owner represents the voice of the customer and the business during the Scrum process. They spend a lot of time with both parties to understand their needs.

The Product Owner is responsible for constantly updating and prioritizing the Product Backlog, and deciding what the team builds next.

The Product Owner also gives stakeholders visibility into what the team is working on – now and in the near future – as stakeholders can refer to the Product Backlog, which is the Product Owner’s responsibility. Keeping the Backlog up to date is also crucial to ensure items are sufficiently detailed and up to date for each Sprint Planning meeting.

🤷‍♀️ Common confusion
The terms Product Owner and Product Manager sometimes get mixed up because you might have both in large organizations. When that’s the case, the Product Owner role reports to a Product Manager (PM). The PM then usually manages the vision, customer, and business needs. The PO focuses only on the Product Backlog and working with the development team to bring the product vision into reality.

ℹ️ More info

Quality assurance (QA) is the process of preventing mistakes and defects in the products or services you deliver. In a non-agile environment, such prevention is done toward the end of a production process by a dedicated QA team.

On an agile team, QA is a continuous process and is the responsibility of everyone or at least one team member. This approach ensures teams take ownership of the quality of their work instead of handing it off to another department, which often leads to sloppy work. Continuous QA also helps teams avoid building up technical debt.

Relative estimation is a technique for estimating story points. Relative estimation involves estimating a work item’s size by comparing it to another one and then assigning it a value, such as story points or T-shirt sizes.

It goes something like this: “If that task is a size 2, then this one surely must be a 4, as it’s twice as hard.” Relative estimation is much easier and faster than other techniques when a team needs to make estimates based on incomplete information or unpredictable dependencies on other tasks and team members.

🤷‍♀️ Common confusion
Time-based estimation comes naturally to most people. We constantly estimate absolute values – how much something might cost, weigh, or how long it takes to get from A to B.

Because of this habit, team members might give a “relative” estimation by doing a mental time calculation first, instead of genuinely considering a task’s complexity by comparing it to another item on a non-time-based scale.

ℹ️ More info

Each Scrum team includes one Scrum Master. A Scrum Master helps the team practice Scrum by guiding them on how to work together more effectively and continuously improve their work processes. The Scrum Master is the expert on Scrum and acts as a coach who teaches, facilitates, and protects the Scrum process.

The Scrum Master protects the team by helping to resolve issues and remove impediments outside of their control. Scrum Masters also train and coach the broader organization in its Scrum adoption to help teams become self-managed.

🤷‍♀️ Common confusion
Some Scrum Masters don’t sufficiently empower the team through training and coaching to take over the Scrum process. Instead, they make the process dependent on themselves, usually by taking—and keeping—control of meeting facilitation and other team rituals.

ℹ️ More info

See Ceremonies.

Scrum teams organize their members into three different roles: Developers, Product Owner, and Scrum Master. The group is self-managed and cross-functional, so they have all the skills to accomplish their work. Typically, a Scrum team consists of three to nine people without any sub-teams or hierarchies.

🤷‍♀️ Common confusion
The latest edition of the Scrum Guide refers to Scrum team roles and responsibilities as “accountabilities.”

ℹ️ More info

Sprints are two- to four-week cycles of work during which Agile teams complete items on the Sprint Backlog to create a product Increment and get stakeholder feedback. Each Sprint contains several events – often called “ceremonies” – that eliminate the need for other meetings by adding rhythm and structure to the work process.

ℹ️ More info

See Sprint Review.

During Sprint Planning, Agile teams commit to the tasks they will complete in the upcoming Sprint. They do so by moving items one at a time from the Product Backlog to the Sprint Backlog.

As the team selects tasks for the Sprint, they clarify what each item means and who will work on it. Sprint Planning finishes when the team feels the selected work roughly matches what they can achieve in the course of one Sprint.

The Sprint Planning meeting occurs at the start of the Sprint. It can last anywhere from one to two hours for a two-week Sprint.

🤷‍♀️ Common confusion
Sprint Planning is not the same as a task/user story estimation meeting. While teams can decide to do some task estimation during Sprint Planning, it usually happens continuously – through Backlog refinement. Teams can also opt to hold a separate task estimation meeting as part of a Backlog Refinement meeting. Many teams opt to do this after their Sprint Retrospective and before their Sprint Planning meeting.

ℹ️ More info

Sprint Retrospectives are meetings where Agile teams congregate to review their work together and identify process improvements. Sprint Retrospectives are held at the end of every Sprint. During the Sprint Retrospective, working relationships, interactions, processes, tools—anything is up for review and discussion.

The Sprint Retrospective helps teams build a habit of continuous improvement.

All team members first suggest topics for discussion, usually by writing their thoughts down on reflection cards. They then group these into common themes and the whole team votes on which ones they want to discuss.

Teams may adapt the Sprint Retrospective process to run pre-mortem or post-mortem meetings.

🤷‍♀️ Common confusion
Like the Sprint Review, the Sprint Retrospective takes place at the end of the Sprint. But its focus is on process improvements, whereas Sprint Reviews focus on the product.

ℹ️ More info

The Sprint Review showcases what the Scrum team accomplished during the Sprint. Sprint Reviews take place at the end of the Sprint, before the Sprint Retrospective.

During a Sprint Review, the team collects feedback on their work from stakeholders. During this meeting, you’ll determine if you met the Sprint Goal and discuss how to improve the product further in future Sprints.

The work showcased during the Sprint Review should be a piece of working software. This is why the Sprint Review is sometimes referred to as the Sprint Demo.

Sprint Reviews allow stakeholders to give feedback early and often instead of rarely and late.

🤷‍♀️ Common confusion
Some teams reduce the Sprint Review to just a demo of the work they did. While showcasing working software is the heart of the meeting, a proper Sprint Review leaves room for discussion and time to look ahead with stakeholders.

ℹ️ More info

A stakeholder is anyone outside the Agile team that is interested in – and has some influence on – the end product. Customers are the most important stakeholders, but executives, investors, and sales teams are other examples.

🤷‍♀️ Common confusion
The Product Owner (PO) is not a stakeholder but a member of the Agile team, even though the PO channels the perspectives of stakeholders into the product vision.

Story mapping is the process of arranging user stories in the order the user is most likely to experience them – essentially following the user journey.

Say you’re mapping a signup and login experience for a new customer. You’d then group all stories related to user registration first – usually on the left of a board – then those related to a confirmation email they need to click to the right of that, and so on. Story mapping allows Agile teams to break the whole customer or user journey down visually.

Teams can do story mapping digitally or by organizing physical cards on a wall, whiteboard, or on the floor.

ℹ️ More info

Story splitting is the process of turning one large user story into multiple smaller stories. This practice is helpful for several reasons:

Story splitting is usually part of the Backlog Refinement process. Teams may also recognize that a story is too large during an exercise like planning poker, affinity estimation, or relative estimation.

🤷‍♀️ Common confusion
While story splitting is a simple concept, even experienced teams often write stories that they could actually break down into smaller ones. Several methods exist to facilitate the practice, such as the Hamburger method and even the Story Splitting Flowchart.

ℹ️ More info

Agile practitioners refer to their work’s concrete inputs and outputs as artifacts. And, because Agile is different from other approaches to work, collaboration, and management, agile teams measure their artifacts and performance through a series of unusual metrics.

Acceptance criteria specify how to verify the completion of a task or user story. Here’s an example from our Product Backlog:

Acceptance criteria are usually documented within each backlog item and often look like a list of criteria that the product needs to fulfil before that task can be considered complete.

🤷‍♀️ Common confusion
Because Acceptance criteria and Definition of Done (DoD) both specify when something is completed and under what conditions, people often use the two interchangeably. But Acceptance criteria apply at the task and story level. In contrast, DoD applies to an entire iteration – so all the features completed during one Sprint.

ℹ️ More info

A Backlog is an ordered list of work maintained by an Agile team. There are two types of Backlogs. The Product Backlog, which is the list of all potential work to be done. And the Sprint Backlog, which is all the tasks earmarked for completion in the current Sprint. The Product Backlog is managed by the Product Owner, while the Sprint Backlog is managed by the team’s Developers and Scrum Master.

If a product roadmap tells teams where the product aspires to go, the Backlog is a prioritized list of all the work needed to get there.

The Backlog helps the team understand what’s important and creates transparency over what work is up next. The Backlog charts out and prioritizes all the individual efforts needed to reach various goals and milestones. It’s the responsibility of the Product Owner to ensure the Product Backlog fulfils this purpose.

🤷‍♀️ Common confusion
There are two types of backlogs: the Product Backlog and the Sprint Backlog. The Product Backlog contains all ideas you could possibly work on for your product. The Sprint Backlog only holds items you have selected from the Product Backlog to work on during a Sprint. People often confuse the Product Backlog and the Sprint Backlog because they use the word “backlog” for both.

It’s also easy to mix up the Product Backlog with the Product Roadmap. The Product Roadmap tells teams on a high level what they need to build and why. The Product Backlog shows how to achieve the goals of the product roadmap.

ℹ️ More info

A Burndown chart shows how many story points a team has completed and how many remain and is usually plotted over the course of a Sprint (“Sprint Burndown chart”). Usually, the chart also has an “ideal burndown” line that shows the progress a team aspires to make to complete by the end of the Sprint or other reporting period.

Teams may also use these charts to display benchmarked data from prior Sprints. The same charts can be used at different scales to show progress towards completing an Epic. In this case, it’s called an Epic Burndown chart.

🤷‍♀️ Common confusion
A Burndown chart only shows how many story points the team completed and how many remain. For example, it doesn’t provide context on whether the most critical items got done or why new items got added to the Backlog. A Burndown chart by itself is therefore not sufficient to determine whether a team is performing well or not. However, it can serve as a signalling tool for problems or phenomena that then need further investigation.

A Burnup chart goes in the opposite direction of the Burndown chart: Upward. It has a line for the number of story points you’ve completed and one for those remaining.

A Burnup Chart better visualizes scope changes compared to a Burndown chart. Say a new item of 20 story points gets added during the period you measure with your chart. As with the blue line in the above example, you would see this increase as a bump in a Burnup chart.

In a Burndown chart, such a change gets included in the line representing the remaining story points. Imagine you completed 30 story points on the same day the 20 points got added. Your Burndown chart would only go down by 10 points on that day (30-20), which makes your team seem less productive than it was.

An epic is a large user story that is broken down into multiple smaller user stories. An epic might be a whole feature in your product, whereas the user stories within that epic break down the goal of the epic into smaller tasks.

Teams use epics in the Product Backlog to keep track of larger, often still high-level ideas. When teams are ready to go into more detail, they split them into smaller user stories that fit into one iteration.

Epics can span several Sprints and expand and change throughout them based on user feedback and other insights the team gathers.

🤷‍♀️ Common confusion
There’s no set format for epics, so you need to define your own. Therefore, different teams might have completely different approaches and layouts for their epics.

ℹ️ More info

An estimate in agile is the development team’s approximation of how much work a user story or task might take to complete. In contrast, estimates in non-agile work environments often come from people who are not doing the actual work – like a manager – but are binding nevertheless.

Agile has various unique estimation methods and measurements to get to more accurate estimates faster than traditional planning methods. Some of the most popular include: planning poker, relative estimation, and affinity estimation.

🤷‍♀️ Common confusion
Even in Agile work environments, estimates sometimes get treated as commitments or deadlines. And some in the agile community see all estimation as a form of waste since it doesn’t create any customer value. This view has sparked the #NoEstimates movement, which calls for estimation to be abandoned altogether.

ℹ️ More info

The Fibonacci sequence is a series of numbers. They grow exponentially because each number is the sum of the previous two numbers: 0, 1, 2, 3, 5, 8, 13, 21, and so on.

Agile teams often use the Fibonacci sequence to estimate the “size” of tasks and user stories for their upcoming Sprint. The point of Fibonacci is to force your hand when estimating larger, complex tasks instead of wasting time nitpicking over minor differences.

Say your team needs to estimate the effort required for a large task in the Product Backlog, such as adding a new feature to your app. Let’s say you estimated your stories on a steady scale of 1-50. When you discuss your backlog item with the team, one picks 31, another 36, and a third 38. When the gap between each estimate is a single integer, it’s hard to estimate with conviction. It feels like estimates have to be very precise.

With Fibonacci numbers, this wouldn’t happen because the sequence forces you to choose between numbers with a wider distance between them. In this example, everyone would have likely picked number 34 in the Fibonacci sequence, as the alternatives would be 21 or 55.

🤷‍♀️ Common confusion
Fibonacci often gets conflated with story points. While the two are closely related – teams usually estimate work items with story points that follow the Fibonacci scale – you can use one without the other.

ℹ️ More info

An impediment is something that blocks or slows down an agile team’s progress. It can be an unnecessary meeting, a technical problem, or a failure to empower a team to make decisions. It’s literally any obstacle to the team’s work.

Since agile is borderline obsessive about reducing waste, removing impediments is an essential focus for agile teams. Eliminating obstacles is one of the primary responsibilities of a Scrum Master and a common objective for retrospective meetings.

An increment is a small piece of working product a customer can use. The focus of most Agile methodologies is to create small increments of working software every single Sprint.

The deliverable – usually a software release or product update – that results from completing all the items in the Sprint Backlog is called an increment. Many teams also refer to this outcome as the “Sprint Goal.”

ℹ️ More info

A Kanban board is a dynamic board with columns to visualize the state of a team’s work. In its most basic implementation, the board contains at least three columns – “Backlog” “Work In Progress (WIP)” and “Done”. Individual task cards move through those columns depending on their status. Some teams also add a “Stuck” column to flag items that need unblocking.

The main requirement for an effective Kanban board is to have one column for every step in a team’s workflow. With such a setup, the board helps to highlight bottlenecks and encourages simplification of the work process. It also encourages transparency as everyone is able to see what is being worked on by the team and where team members may be stuck.

🤷‍♀️ Common confusion
The Kanban board is not exclusive to the Kanban methodology. Several other agile frameworks also often use a Kanban board to reflect the status of work items, for example, Scrum and Scrumban.

ℹ️ More info

See Backlog.

A PBI is a single work item in your Product Backlog.

Examples of Product Backlog items include:

ℹ️ More info

A release plan is an overview of the features that are planned to be included in one or more upcoming releases. It may include feedback from previous iterations and timelines for future releases.

🤷‍♀️ Common confusion
Some Agile practitioners consider a release plan too rigid and a form of waste, claiming that a Product Backlog combined with regular Sprint Planning gives the development team enough direction while allowing responsiveness to changing customer needs.

See Kanban board, as there’s essentially no difference between a Scrum board and a Kanban board – except for the confusion outlined below.

🤷‍♀️ Common confusion
The Scrum and Kanban frameworks each make different uses of the board and apply their own rules. Kanban, for example, typically sets a limit on the number of work items that can be in progress simultaneously. Scrum uses a new board for each Sprint, whereas in Kanban, work keeps flowing, and there are no predetermined cycles as in Scrum.

ℹ️ More info

The Sprint Backlog contains items the team has selected from the Product Backlog during Sprint Planning to work on during the current Sprint. While you can continuously expand and refine the Product Backlog, you shouldn’t add items to the Sprint Backlog once you start a Sprint.

The Sprint Backlog typically consists of user stories broken down into tasks with estimates, either in story points or time.

🤷‍♀️ Common confusion
In Agile, Developers – not Product Owners, Scrum Masters, or other managers – are responsible for deciding which items go into the Sprint Backlog. In other words: The team decides what work and how much of it they will do in the next Sprint.

See Increment.

Story points measure the estimated size of a piece of work, where size is the sum of multiple factors that could impact completion:

Teams may use story points during their backlog refinement or agile estimation meetings to give a clearer idea of how much work they can expect to achieve in each Sprint.

🤷‍♀️ Common confusion
It’s tempting to peg story points to time – “one story point = one day,” but that defies their purpose. As soon as you do that, story points reflect an absolute measurement of time, not a relative size based on a combination of factors.

Story points also often get conflated with Fibonacci estimation. But while the two are closely related – teams usually estimate work items with story points that follow the Fibonacci scale – you can use one without the other.

ℹ️ More info

See Kanban Board.

As the name implies, this agile estimation technique uses T-shirt sizes: Extra Small, Small, Medium, Large, Extra Large or S, M, L, XL. It’s a form of relative estimation in which teams determine a story or task’s size by comparing it to other items, rather than by assigning an absolute value like time.

Initially, you can expect extended discussions as your agile team finds the right “fit” for each task. Sizing becomes easier once you have a baseline on a few items that you can use as reference points.

ℹ️ More info

A user story is a short description of a feature written from the intended user’s perspective, often in this format:

User stories serve as discussion starters for the entire team to figure out the most suitable and efficient solution to users’ needs. They also help the development team empathise better with the user and focus their efforts towards delivering customer value.

While the Product Owner’s responsibility is to ensure the Product Backlog contains good user stories, any team member can and should write them.

🤷‍♀️ Common confusion
User stories sometimes get written as requirements or specifications when people add too many instructions or technical details. Following the mad libs above helps to ensure user stories are clear and concise.

ℹ️ More info

Velocity is the number of estimated story points a team completes during a period, usually measured per Sprint. Or, as Leon Tranter puts it in his Ultimate Guide to Agile Metrics, velocity “is simply how much ‘stuff’ has been moved from one side of a board to the other.”

As the tone of Tranter’s definition suggests, velocity is a controversial metric. In theory, it can help the team forecast how much work they are able to complete in one Sprint and signal issues or areas for improvement. In practice, using and measuring velocity gets tricky when others outside of the team use the number to:

When any of these things happen, decisions based on these numbers will be wrong, or the team might manipulate the metric. Since the team sets the value of story points and estimates stories and tasks during Sprint Planning, it’s not hard for them to artificially manipulate this number.

🤷‍♀️ Common confusion
A higher velocity is not necessarily better. It depends on the objectives you set as a team. Say you make improvements to your working process to complete more story points per Sprint. In that case, you indeed want to see an increasing velocity. But you could also decide to take on less work per Sprint to boost the quality of your deliverables. That would reduce your velocity, but the decrease would be positive, in line with your objective.

ℹ️ More info

Work In Progress (WIP) reflects the total number of items a team is currently working on, usually represented by one or more Kanban board columns.

WIP is a critical metric for keeping teams focused and ensuring a continuous flow of work. A high WIP number often signals that a team is overcommitted and has its attention divided across multiple tasks. On the other hand, a low WIP number signals tasks flow through the system quickly, and a team is getting lots of work done, without too much context-switching.

Kanban sets a WIP limit, meaning a maximum number of items that can simultaneously be in the WIP column. If an urgent item needs to enter, but the WIP limit has been reached, another task has to exit the column first. This can either happen by finishing the task first or moving it back to the Backlog.

🤷‍♀️ Common confusion
WIP alone doesn’t give a complete picture of a team’s performance and the health of its processes. Say, for example, teams move items to “Done” too quickly, then bugs are identified. A team member will still need to deal with those bugs and they may not be reflected in the columns.

In that case, WIP stays low, but the team’s actual speed does, too. That’s why you always need to look at WIP in combination with other metrics like velocity and, ideally, one that reflects customer satisfaction like NPS.

You also might need to define when an item moves into WIP: when you start actual work on a task or when you commit to working on it? There’s no wrong answer, but it’s essential to specify such parameters for your WIP. 

86% of software teams in 2021 indicate they’ve adopted Agile, up from 37% just one year earlier 🤯.

You’ll likely have visited Agile country at least once, or will do so soon.

We hope the above guide is helpful on your journey.

One last piece of advice: Remember that nothing is set in stone here. The spirit of this place is to strive for continuous improvement. Any rule can be broken, adjusted, removed, or replaced—despite what some grumpy old local or the inevitable huckster might tell you.

If you found this resource useful, bookmark it for future reference, or share it with your team!