Agile terminology used by Agile201

At Agile201 we use only industry-standard terms. Unfortunately, there is no fully standardised Agile terminology, or even sets of terms that are consistently used together. So the following table lists all the main Agile terms, along with the specific terms Agile201 uses.
Backlog GroomingBacklog Refinement
Daily ScrumDaily Stand-Up Meeting
Development teamCore Team
Forecast (of functionality)Iteration Backlog
HuddleDaily Stand-Up Meeting
ScrumDaily Stand-Up Meeting
Scrum BoardTask Board
Scrum MasterIteration Lead
Scrum TeamIteration Team
Show and TellShowcase
Sprint 0Iteration 0
Sprint ReviewShowcase

Agile lexicon

The following list defines most of the standard language of Agile. A number of terms are also explained in more detail on the Agile Disciplines page. Terms that are capitalised have a special meaning, either in Agile as a whole or in Agile201.

Acceptance testing

In small developments, the process of formally checking whether the final deliverable meets the user or customer’s expectations and whether it should be accepted for use. This testing (usually referred to as UAT) is normally performed by users and is performed before the release goes live.

In larger, more complex developments, an additional layer of operational acceptance testing (OAT) may also be applied, to confirm the final deliverable’s compatibility with the operational environment.

See also: Continuous Delivery, Story.

Agile Manifesto

The founding document of the Agile movement, signed in 2001. It defines 4 continua and 12 principles.

See also: Agile Manifesto, Principles.


In traditional organisations, delivery is often delayed or disrupted by conflicts in different teams’, functions’ or departments’ priorities, timescales, transmission mechanisms, etc. Alignment is the process (or the actual mechanisms) for ensuring that these transition are smooth, rapid and risk-free.

See also: Continuous Delivery.


A catalogue of Stories, Features, Epics and other ideas, representing the known workload for a given area. Stories in the backlog are normally at progressively higher levels of maturity as their delivery approaches. In Agile, there are normally three levels of backlog:

  • Product Backlog (ideas, Features, Epics, Stories for a complete area).
  • Release backlog (mature stories, features and epics that have been assigned to a specific Release).
  • Iteration backlog (stories assigned to specific Iterations with the current release).

The backlog is managed through the Agile ‘ceremonies’ of Product PlanningRelease Planning, Iteration Planning and Backlog Refinement.

See also: Story Map.

Backlog Refinement

Also known as backlog ‘grooming’, the process of reviewing the backlog to see whether items can be rationalised or improved (e.g., by adding granularity) and the delivery process further optimised. Refinement is an on-going process, but iterations will normally include an organised refinement meeting.

See also: Refine Backlog (practice).

Batch and Flow

Two contrasting methods of managing work in an Agile environment. Both are designed to limit the volume of ‘work in progress‘ and so prevent bottlenecks, unmanageable complexity, etc.

  • A ‘batch’ approach, such as Scrum, limits work in progress by selecting a subset of the stories in the backlog and commits to delivering them within a definite period (a ‘timebox’). New stories are generally selected at the start of releases and iterations, although backlog refinement may also lead to story priorities being shuffled.
  • A ‘flow’ approach, such as Kanban, limits work in progress by setting an upper limit to how many stories may be worked on at any one time. New stories are selected continuously from the ‘hopper’ as previous stories are delivered.

More concisely, a batch-based system pushes work towards the team, while in a flow-based the team pulls new work as capacity becomes available.

See also: Kanban.

Big Visible Charts

Agile puts great emphasis on communications, collaboration and transparency. Big visible charts (and other prominent displays of activity, status and achievement) facilitate this without requiring more heavy-duty, low efficiency communications tools.

See also: Burn Chart, Information Radiator.


A localised constraint on the rate of delivery that prevents the team from being effectively or fully mobilised. The bottleneck may be the result of unbalanced resourcing (too many testers for the number of developers, for example), the non-availability of a key factor (test environments, expert users, etc.), from a more structural misalignment between teams, systems, capacity, priorities, etc., or from other factors.

See also: Alignment, Batch and Flow, Work in progress.


In software development, branching is the action of taking a copy of the controlled source code – the ‘Mainline‘ – and working on it on a local machine. At various point this branch is merged back into the mainline. Branching is a basic technique in Continuous Integration and Delivery.

See also: Continuous Delivery, Continuous Integration, Mainline.

Breaking the Build

If a developer compiles their code and the build fails, they have ‘broken the build’. Applying the ‘Quality First‘ discipline, both the superficial symptom and the underlying problem are dealt with immediately.

See also: Continuous IntegrationQuality First (discipline).

Burn Chart

A simple chart that compares the rate at which stories (or, more accurately, story points) are completed with the effort remaining. The Burn Chart comes in two basic variants:

  • A Burndown Chart, which is simpler and more intuitive but less able to deal with changes (e.g., in the number of stories).
  • A Burnup Chart, which is more complex but easier to adjust if the scope changes.

More complex versions are also in use. Burn charts can be used at iteration, release and product level.

See also: Big Visible Charts, Cadence, Velocity, Volatility.


Pulse or pace. Agile emphasises a regular cadence, as this promotes overall productivity, sustainable development and team motivation.

See also: Burn charts, Velocity, Volatility.


One of the standard Agile events: Release Planning, Iteration Planning, Backlog Refinement, Showcase, and Retrospective. It is largely in these events that the intensive level of communication, alignment, collaboration and improvement that defines Agile is achieved.

See also: Release Planning (practice), Iteration Planning (practice), Backlog Refinement (practice), Conduct Showcase (practice), Conduct Retrospective (practice).


Agile slang for an individual with an interest in an Agile team’s work but not actively involved.

See also: Pig.

Code Smell

Developer’s develop an intuitive sense of when code is poorly structured and likely to create problems in future. The basis of this is ‘Code Smell’ – an unpleasant impression created by the intuition that code is poorly structured.

See also: Pattern & anti-pattern, Refactoring.


Working together continuously and as equals is a basic feature of Agile organisation and reams. It is based on the assumption that collaboration is more productive, as it brings together much greater and more diverse experience and increases motivation.

See also: Agile organisation (roles), Collocation, Self-Organisation.


Working physically closely together. This facilitates communications and collaboration and removes many of the misalignments, delays and disruptions that undermine most non-Agile methods.

See also: Alignment, Collaboration, Collocation (metrics).


A high-level description of something desirable – a new product, a technology, process, etc. – that is not yet developed enough to be considered an epic, feature or theme. Typically a concept includes a general outcome or type of functionality. “Wouldn’t it be good if we could…” might be a typical concept.

See also: Placeholder.

Continuous Delivery

A rapidly emerging approach to the final release of code, building on experience of Continuous Integration. In Continuous Delivery, the entire process from building the final version of the code, through testing and on to deployment is integrated and automated. This removes obstacles and risks, and accelerated the process. This in turn allows the process to be used very frequently – hence the term ‘continuous’.

See also: Alignment, Continuous Delivery (technique), Continuous Integration.

Continuous Integration

A team-wide discipline for building, integrating and sharing code as it is developed.

See also: Alignment, Branching, Continuous Delivery, Mainline.

Core Team

‘Core Team’ is the name used by many organisations (and Agile201) for the basic Agile team (Product Owner, Iteration lead, Users and Developers) who take responsibility for implementing the Backlog stories and delivering working software.

See also: Extended Team.

Cross-Functional Team

A team that includes all the required functions to complete development. A cross-functional Agile team will normally include a Product Owner (to represent the organisation as a whole), analysts, coders, testers (collectively simply ‘developers’) and expert and authoritative users. On this basis, practically every item of knowledge and decision-making capacity should be present within the team. As a result, many of the obstacles to rapid, flexible progress are eliminated.

See also: Agile organisation.


A broad, intuitive but weakly defined class of stakeholders, including any of:

  • Commercial clients of the team’s organisation who pay for the development they carry out (e.g., purchasers of specialised software development services).
  • Individual purchasers of a commercially sold application (e.g., buyers of office applications) by the team.
  • External (usually commercial) users of the system (e.g., users of an ATM), often referred to as the end-users.
  • Internal stakeholders specifying, prioritising and funding the team’s work.

Customers are typically represented to the team by the Product Owner or by a subject-matter expert. ‘Customer’ should not be confused with ‘User’.

See also: User, Voice of the Customer.

Daily Scrum

See: Daily Stand-Up Meeting.

Daily Stand-Up Meeting

One of the Agile ceremonies, in which the team assembles to explain to each other (in a few sentences only) their progress and the obstacles they face.

See also: Daily Stand-Up Meeting (practice).

Definition of Done

The checks software must pass before the team can release it. This generally consists of much more than simply passing tests, and typically includes a range of governance controls, documentation and other preparations.

See also: Definition of Done (practice).

Domain model

Description of the application domain that defines a shared conceptual and language framework that can be shared by IT and its stakeholders (especially the business that owns the domain). Generally it includes users, entities, data and functions and behaviour.

Elevator pitch

A striking summary that encapsulates what will be special about the final product, without becoming bogged down in detail or being so abstract as to become meaningless.


The principle that optimal designs and solutions arise unplanned and over time (e.g., while users and developers interact over an extended period) rather than by a formal action or at single fixed point (i.e., when ‘the design’ is specified and signed off). Agile advocates on-going and very flexible interactions between the team and the real users of the system, to ensure that this process is allowed to take place.

See also: Incremental, Iterative Development.


A strategy for or approach to managing activity that focuses on continuously observing actual (empirical) outcomes and optimising actions and inputs accordingly.

Engineering standards

A suite of formal criteria (often including metrics and measurements) shared by a specific group (e.g., the Core Team, a whole organisation, a whole industry, etc.) to ensure that released product is a) of sufficient quality, a b) consistent with other products built to the same standards.


A story that is too large or complicated to be confidently estimated or delivered. Agile suggests that epics be sub-divided into more manageable stories.

See also: Epic planning (practice), FeatureEpic management (technique), Story, Stories (practice), Theme.


The process of calculating the effort required to complete a release, story, task, etc.

See also: Estimation techniques (techniques) Planning Game, Planning Poker, Planning Poker (technique).

Extended Team

The Extended team is the group of individuals and functions who regularly collaborate with the Core Team without being members of the Core Team. They are generally specialists and authorities to whom the Core Team frequently need to refer (for decisions, information, etc.), such as DBAs, PMO, architects, and so on.

See also: Core Team.

Extreme Programming (XP)

An early and widely used approach to Agile. Originating in the late 1990s, XP emphasises customer satisfaction, positive responsive to late changes, team empowerment, techniques such as Test-Driven Development and Pair Programming, and values such as simplicity, communication, feedback, respect and courage.

See also: Extreme Programming (organisation), Extreme Programming (Wikipedia).


In systems, an approach that ensures that system failures are identified and reporting as soon as they happen. In Agile generally, a metaphor for discovering errors and omissions quickly, so that they can be fixed fast too, and the knock-on effects of unidentified and ignored problems can be avoided.

See also: Incremental, Iterative Development.


In Agile, a widely used but weakly defined term. Some Agile teams treat it as a synonym of a story. In it is defined as:

A higher level object that supports multiple user stories without being reducible to the sum of its parts. For example, a single integrated user interface that supports the skill levels and functional requirements of multiple user classes.

For an explanation of this definition, see here.

See also: Story, Stories (practice), Managing features.

Fibonacci series

The Fibonacci series is a sequence of numbers that is popular in Agile estimating owing to their link to many statistical distributions and mathematical series. The series begins with 0 and 1 and subsequent members of the series are created by adding together the two previous numbers. So the initial numbers in the series are 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, etc. For Agile estimating, the first two numbers are omitted.

See also: Estimation, Estimate a Story (practice), Estimation techniques (techniques).

Gemba Walk

Direct observation (typically by the Iteration Lead, Product Owner, and perhaps others) of work as it is actually being carried out ‘on the shop floor’. Its purpose is observation, understanding and discussion with practitioners, but not criticism, enforcement (e.g., of policy) or even of direct problem-solving or making changes.

See also: Gemba (Wikipedia).


See: Daily Stand-Up Meeting.


An obstacle to completing a task, story, iteration, etc.

See also: Daily Stand-Up Meeting, Improvement Board, Improvement Board (tool), Conduct Retrospective (practice).

Improvement Board

A simple tool for managing obstacles, impediments and improvement plans.

See also: Daily Stand-Up Meeting, ImpedimentImprovement Board (tool), Conduct Retrospective (practice).


In small units, each of value to the end-user or other stakeholder. A basic model for Agile, as each increment also tests the integrity of the whole and, by delivering it to the end-users, tests its value and the correctness of the overall delivery trajectory.

See also: Iterative Development.

Information Radiator

A large, highly visible display of key information, such as team velocity, burn chart, defect reports, etc. It should be instantly intelligible to the team, visitors and others. It typically shows many items, and may be an electronic display, a hand-drawn chart, or anything in between.

See also: Big Visible Charts.

Inspect and Adapt

A motto that encapsulates the basic improvement cycle within Agile: continuous review (inspection) and continuous improvement (adaptation) of all aspects of the team and the solutions it creates. Although this is continuous discipline, it is also a fundamental part of all the Agile ‘ceremonies’.

See also: Ceremony, Iterative Development.


A short (often 2-4 weeks) burst of development, typically one of several such bursts, that collectively make up a complete release.

See also: Iteration Planning (practice), Release Management (practice).

Iteration Lead

Facilitator and coordinator of an iteration team, and guardian of Agile practices and culture. Not its owner of manager.

See also: Iteration Lead (role).

Iterative Development

Delivery in repeated small steps, leading to the progressive delivery of a larger item. A basic model for Agile, as it permits the overall release process to be more precisely steered and subjected to continuous review and improvement, depending on the user feedback.

See also: Incremental, Inspect and Adapt.


An Agile-like method for managing work, emphasising a continuous flow of incremental changes, and emphasising progressive, evolutionary improvement over time.

See also: Batch and Flow.

Lean software development

An application of Lean manufacturing principles to software development. It emphasises the elimination of waste, redundancy and prematurity, attacking any source of delay, team empowerment, building quality in, continuous improvement, and appreciating the context of work.


In software build terminology, the mainline is the core version of the software under development, from which releases are made.

See also: Branching, Continuous Integration, Continuous Delivery.

Minimum Marketable Features

The least features the product must have for buyers and users to regard it as having value.

See also: Minimum Viable Product.

Minimum Viable Product (MVP)

The least that can be built and shipped to come up with meaningful results. This may be measured in many ways, including value to the user, revenue generated, informative feedback, etc.

See also: Deliver Early, Deliver Often (discipline), Minimum Marketable Features.

Motherhood statement or story

A story or statement no one would disagree with, but which (typically) is too imprecise to act upon. However, it is often an indicator of either a) an area that stakeholders are concerned with or would prioritise, or b) an area that the team is reluctant to discuss or clarify. In either case, the team should perhaps attempt to articulate or operationalise.

Pair Programming

Writing code in pairs, so that while one individual writes the code the other can review it continuously against the work’s wider purpose, the technical context, user needs, good coding and programming practice, and so on.

See also: Pairing (discipline).

Parallel development

The simultaneous development of different parts of a single code base. A risky activity, which continuous integration is designed to ameliorate.

See also: Continuous integration, Mainline.

Pattern and anti-pattern

A pattern is a model of how the product or work should be done; a proven method for solving problems, designing systems, etc.

An anti-pattern is a model of how not to do something; a pattern to avoid.

See also: Software design pattern (Wikipedia).


Agile slang for an individual who is actively involved in an Agile development, as opposed to an uninvolved (but still interested) bystander.

See also: Chicken.


A reminder of a topic that will eventually need to be dealt with in more detail. In the evolution of stories, for example, a placeholder statement may be entered in the backlog to remind the team of a particular issue or opportunity they should eventually consider.

See also: Concept.

Planning Game

A planning technique derived from XP. Rather than preparing a formal plan, the team move progressively through the release and iteration planning cycles via phases of ‘exploration’, ‘commitment’ and ‘steering’ the project.

See also: Estimation, Extreme ProgrammingPlanning Game (Wikipedia), Planning Poker, Prioritisation.

Planning Poker

A widely used estimation technique that uses the team’s collective knowledge and experience to arrive at a shared estimate.

See also: Estimation, Planning Poker (technique), Planning Game, Prioritisation.


Putting stories (and other items) into a preferential order (e.g., to determine the order in which stories will be implemented).

See also: Prioritisation (techniques).


The object of an enduring programme of development and change. Typically something the organisation makes and sells, or a semi-permanent internal entity such as an architecture or function (HR, finance, etc.).

See also: Product Backlog, Product Management (practice), Product Owner (role), Product Vision.

Product Backlog

Catalogue of items relating to a single Product.

See also: Backlog, Product.

Product Plan

The document for defining the overall product strategy. Ideally it should cover the full scope of the Product Vision and Product Backlog, and should set out the scope and schedule of expected releases, and other details.

See also: Product Management (practice), Product Plan (product), Product Planning (practice).

Product Owner

The individual who manages the interface between the team and the stakeholders they work for and typically provides information and decisions about the product area. They are also accountable for maximising delivery of value.

See also: Product Owner (role), Voice of the Customer.

Product Team

An Agile team dedicated to the long-term support of a single product.

See also: Organisation (roles), Product.

Product Vision

The high-level statement of the attributes and goals of a product.

See also: Product Backlog, Product Management (practice), Product Owner (role), Product Vision (product), Voice of the Customer.


See: Release.


See: Recursion


Restructuring poorly designed code without altering its external behaviour.

See also: Refactoring (technique), Technical Debt, Test-Driven Development.


A package of updates, changes and improvements to a product.

See also: Product, Release Planning (practice).

Release Plan

The plan for an individual release, typically identifying the items (stories, etc.) that it will deliver, the timescale, etc..

See also: Product Management, Product VisionRelease Planning (practice).


A review by the team of the most recent iteration, looking for lessons and opportunities to improve.

See also: Conduct Retrospective (practice).

Scrum defines Scrum as: “a framework to support teams in complex product development. Scrum consists of Scrum Teams and their associated roles, events, artifacts, and rules, as defined in the Scrum Guide”.

Scrum Team

See: Team.

Scrum Master

See: Iteration Lead.


A basic principle of Agile organisation: teams decide for themselves how they will carry out their work. However, this principle is always constrained by by the obligation to do this within imposed boundaries and for the sake of achieving imposed goals.

See also: Collaboration.


A spike is a story that is designed to answer technical or functional questions, to clarify an area of uncertainty (such as ‘Will anyone really use this?’). Like a spike in mountaineering, an Agile spike is driven in to the cliff face to make it possible to climb a little higher. Ward Cunningham explains how the term was coined:

I would often ask Kent [Beck], ‘What is the simplest thing we can program that will convince us we are on the right track?

That’s a spike: a localised investigation aimed at deepening the team’s knowledge to the point where they can proceed with confidence.

See also: Create a Spike (practice), Story.


See: Iteration.

Sprint Backlog

See: Backlog.

Sprint Review

See: Retrospective.


An individual (sometimes a function) that has an interest in or influence over a piece of work, but does not participate in the development work itself.

See also: Organisation (people).

Stand-Up Meeting

See: Daily Stand-Up Meeting.


Stories are the basic units of Agile development and delivery. They describe a small, independent behaviour that can be implemented within a single iteration, provides value, and meets the team’s standards for format, acceptance criteria and ‘definition of done’.

See also: Create a Story (practice), Definition of Done (tool), Use Case, User.

Story Map

A tool used to organise a Backlog of stories into different areas (e.g., of product functionality), and so clarify the Backlog and simplify the planning process.

See also: Backlog, Create a Story Map (practice).

Story Points

Units of effort Agile uses to estimate stories and measure team velocity.

See also: Create a Story (practice), Story Points (technique), Velocity.


A discrete piece of activity that contributes to the implementation of a story.

See also: Task Board, Task Board (tool).

Task Board

A simple chart indicating the status of individual tasks – e.g., ‘To do’, ‘In progress’ and ‘Done’.

See also: Burn Chart, Task, Task Board (tool).


In Agile, a self-sufficient, non-hierarchical workgroup of professionals, characterised by self-organisation, persistence, cross-functionality.

See also: Collaboration, Collocation, Cross-Functional Team, Organisation (people), Self-Organisation.

Technical Debt

Losses of efficiency, effectiveness, adaptability, etc., will that disrupt and delay future development.

See also: Refactoring, Technical Debt (practice).

Test Automation

Replacement of manual testing with machine-driven testing.

Test-Driven Development

A development technique based on embedding detailed tests in the source code as the code is written, providing both rapid verification that the developer has not ‘broken’ the code and also a permanent set of regression tests.

See also: Unit Testing, YAGNI.


A group of work items that are united by their common subject-matter, but not necessarily all part of a single story, epic, etc. For example, ‘user interfaces’ or ‘reports’ might be themes, even though the actual interfaces or reports the team works on are connected to different parts of the application, and (unlike an epic) not functionally related to each other at all.

See also: Epic, Feature.


Defined period of time within which development must be completed.

See also: Timeboxing (discipline), Timeboxing (technique).

Unit testing

Testing of complete units of code. In Agile, frequently the internal testing of a complete story.

See also: Test-Driven Development.


The direct user of an application. They may be internal or external to the development organisation. Users should not be confused with Customers.

See also: CustomerStory, User (role).

Use case

A structured (often diagrammatic) statement of a sequence of actions and events that (usually) describes the interaction between a user (‘role’, ‘actor’) and a system to achieve a goal or outcome. Use cases offer a more structured and detailed alternative to stories, if needed.

See also: Story.

User Story

See: Story.

Vanity metric

A metric that serves no purpose (answers no question, guides no task, measures no success factor, etc.), but reassures its bearer or permits them to brag.


The number of story points a team can complete in an iteration. This is usually set by the total story points of all the stories successfully implemented in the previous iteration.

See also: Burn ChartStory Point.

Voice of the Customer (VOC)

An expression of the customer’s experience, preferences , desires, dislikes, etc. The VOC is often replaced by the opinions of the Product Owner, which are not always founded on objective research.

See also: CustomerProduct Owner.


Volatility is a measure of how stable or consistent your velocity is. Low volatility makes it easier to maintain a regular (and generally more productive) cadence. It also indicates how reliably your current velocity figure will predict how much you will actually deliver.

See also: Burn chart, Cadence, Velocity.

Work-in-progress (WIP)

Work that has started (and has therefore begun to incur cost) but has not yet been completed. Excessive WIP creates bottlenecks and risks wasting effort on work that will not be completed. Agile aims to reduce WIP to a level where there is a continuous flow of value-adding work that optimises the team’s working time.


See: Extreme Programming.


Short for ‘You ain’t gonna need it’. The principle that developers should only develop what they’ve been asked for explicitly, and avoid writing code for things that that ‘might’ or even ‘will’ be needed.

See: Test-Driven Development.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Toggle Sliding Bar Area
Want to do more than just build systems?