This collection of common agile terms and their meanings should help you out if you’re not sure what your experienced agile colleagues are saying. It’s based on the syllabus for the BCS Agile Foundation Certificate, and is also great preparation for the examination included in that course.


The Agile Manifesto

Created in 2001 to summarise the approach taken by the creators of agile frameworks, it highlights the need to put the emphasis on:

  • Individuals and interactions over processes and tools.
  • Working software over comprehensive documentation.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.

Twelve supporting principles were created at the same time:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

Agile Delivery Frameworks

Scrum – an agile product delivery framework comprising 3 roles, 5 events, and 3 artefacts, upon which teams build their own process. Work is limited by fixed-length sprints of 30 days or fewer.

Kanban – a methodology for improving any process, not limited to software and with no constraints or timeboxes. Work is limited by a pull-system: new work can only enter when a space is made by completed work leaving the system.

Lean software development – an adaptation of the lean principles developed in manufacturing to make them relevant to software, taking the form of seven principles:

  1. Eliminate waste
  2. Build in quality
  3. Create knowledge
  4. Defer commitment
  5. Deliver fast
  6. Respect people
  7. Optimise the whole


Lean Start-up – a way of bringing a new product to market to validate the hypothesis that it is valuable, while minimising the financial costs.

DSDM Atern – an agile project management framework that seeks to allow projects to be delivered at fixed timescales by varying scope and delivering in a series of iterations.

eXtreme Programming (XP) – An agile framework similar to Scrum with an emphasis on technical excellence and close customer collaboration.

Scaled Agile Framework (SAFe) – a framework for delivering large-scale agile products comprising five or more teams, with patterns to enable programme and portfolio management and co-ordinated planning.

Concepts and ideas

The iron triangle: made up of three variables to be managed while delivering a project:

  • Time
  • Cost
  • Features

Traditional waterfall projects often fix the features to be delivered and vary time and cost. Agile projects allow a choice in what may be varied.

Timeboxes: The maximum about of time permitted for an event, and the fixed amount of time allotted for an iteration or sprint of development. For example:

  • In Scrum, the maximum amount of time for Sprint Planning is 8 hours. It doesn’t have to take that long, but can’t take longer.
  • Iterations or Sprints have fixed timeboxes, which are chosen at the start and are typically kept the same length every time. If the team chooses a 2-week sprint, then more work is added if they finish early, and any incomplete work is put back on the backlog if not done within the 2 weeks.

Cone of uncertainty: The uncertainty in cost, effort, and size of work is large at the beginning, and follows a cone-like profile becoming less uncertain as time progresses.

Waterfall: An example of a defined process where projects are delivered in large stages or batches. All of the analysis is done, followed by all of the design, coding, testing, etc.

Empirical process control: An empirical process is one where it is accepted that the requirements and technology are not fully understood at the start and will need to be adapted based on new information and measurement. The three pillars of an empirical process are:

  • Transparency – we need to be able to see clearly what progress has been made
  • Inspection – we need to look at the product as it evolves and get feedback
  • Adaptation – we need to be able to change the plan and the process in light of new information

Examples of empirical processes

  • PDCA Plan, Do, Check, Act
  • POOGI Process of On-Going Improvement
  • OODA Observe, Orient, Decide, Act
  • BML Build, Measure, Learn
  • DMAIC Define, Measure, Analyse, Improve, Control
  • TAC Thought, Action, Conversation
  • Kaizen – the practice of making continuous, small improvements 

Technical Debt: Work that was deferred to achieve an early release, that now increases effort or cost. Examples include:

  • Cutting quality or testing
  • Not automating test or deployment activities
  • Not refactoring code or keeping up to date with evolving technologies

Schneider culture change model: a way of understanding an organisations predominant culture, or “the way we do things round here to succeed”:

  • Control
  • Competence
  • Cultivation
  • Collaboration

Agile transformation often involves an attempt to move away from a “Control” culture.

Kotter’s 8-step change model can help leaders to plan a transformation, such as from traditional project management to agile delivery. The 8 steps are:

  1. Establish a sense of urgency
  2. Form a powerful guiding coalition
  3. Create a new vision
  4. Communicate the vision
  5. Empower others to act on the vision
  6. Plan for and create short term wins
  7. Consolidate improvement and produce still more change
  8. Institutionalise new approaches


Agile Roles

The Product Owner. Also referred to as:

  • Product Manager
  • The Customer

Defines what is to be delivered, released, and optimises the overall value of the product. Desirable characteristics follow the DARKA model:

  • Desire to be involved in the product
  • Authority to make decisions
  • Responsibility for the outcomes of those decisions
  • Knowledgeable about the product, users, and market
  • Available to the team to clarify requirements and make plans

The Development Team. Also referred to as:

  • The team
  • Agile teams

Responsible for delivering the value defined by the product owner. Desirable qualities:

  • Cross-functional – each member of the team has a specialism, with abilities to carry out secondary skills, with a T-shaped profile
  • Self-organising – the team decides how to turn the requirements into working software, and who should do what on a daily basis
  • Recommended size: 7 ± 2

The Scrum Master. Also referred to as:

  • Agile lead
  • Agile coach

Responsible for the process, facilitates and coaches, resolves impediments. Desirable qualities:

  • Servant leader for the team, guiding without direct authority
  • Enables the other roles to be effective without making decisions on their behalf

The Stakeholders. May be categorised as follows:

  • High-power, high interest – the aim is to keep engaged and to consult regularly
  • High-power, low interest – the aim is to satisfied, while attempting to increase interest
  • High interest, low power – the aim is to keep informed and allow useful ideas to be highlighted
  • Low interest, low power – the aim is to keep aware via general communication

Motivated and empowered people: Whatever the role being carried out, the most effective teams are built on motivated people. Models and theory often used to guide leadership in this area include:

  • Maslow’s hierarchy of needs: Individuals are unlikely to be engaged and created unless their basic needs are met, in this order:
    • Physiological
    • Safety
    • Love/belonging
    • Esteem
    • Self-actualisation
  • McGregor’s Theory X / Theory Y: The way that people are managed has a big effect on motivation, and this can be simplified into two “theories” held by managers:
    • Theory X managers believe employees hate work and have to be forced to do it
    • Theory Y managers believe employees like work and can be trusted to work effectively
  • Dan Pink’s Intrinsic Motivation: External motivation such as bonuses have a neutral or negative effect when used to motivate knowledge work. Intrinsic motivation relies on maximising the following characteristics of the work itself:
    • Autonomy to control your own work and decide how to reach the goals assigned
    • Mastery of skills and specialisms, the opportunity to learn and to apply that knowledge
    • Purpose and a sense of knowing that you’re making a difference
  • Tuckman’s theory of team evolution: A simple model to understand how a new group of people are likely to evolve
    • Forming: A focus on formality and routine, with the avoidance of conflict
    • Storming: Differences come to the surface and conflict arises
    • Norming: Conflicts are mostly resolved and the team becomes productive
    • Performing: People work dynamically with high trust and creativity
  • Five dysfunctions of teams: Patrick Lencioni’s model of team dynamics highlighting five typical anti-patterns, which are often overcome in this order:
    • Absence of Trust
    • Fear of Conflict
    • Lack of Commitment
    • Avoidance of Accountability
    • Inattention to Results


Agile Techniques

User Stories: A simple way of expressing requirements on a product backlog to allow the high-level intent to be understood. Just enough detail to decide how to prioritise, and whether to start analysing further. The most common format is:


As a <Role>

I want <Functionality>

So that <Benefit or value>

Product Backlog Refinement: A catch-all term for the activities that go into adding additional detail and analysis to items on a product backlog. These activities often include:

  • Estimating the effort
  • Adding acceptance criteria
  • Managing dependencies

These activities may be done by individuals, small groups, or by the whole team. They are usually carried out during an iteration/sprint, for work coming up in the future.

Product Backlog Ordering: The product owner has the final say over the content and ordering of the product backlog. Some choose to use the following approaches:

First in, first out (FIFO): Often used for operational teams such as support – items are handled in the order they are received with no assessment of value

Shortest Job First (SJF): To prioritise quick wins without assessing value, the shortest, lowest effort items are put at the top of the queue

Hight Cost of Delay First (HCDF): High value items that would result in a cost of delay if not done are prioritised, especially items with deadlines or time sensitivity

Weighted Shortest Job First (WSJF): A score is calculated combining effort and cost of delay, resulting in small, valuable, time-sensitive items to be done first

INVEST: Characteristics of good quality backlog items. By the time items reach the top of the backlog and are likely to be planned for the next iteration/sprint, it is desirable that they are:

  • Independent – can be done in any order without dependencies
  • Negotiable – developers can offer alternative solutions to deliver the value needed
  • Valuable – it must be clear what benefit is being delivered
  • Estimable – there must be enough information to allow reasonable estimates
  • Small enough – to deliver within a single iteration/sprint
  • Testable – it must be clear what is required and when it can be considered complete

Acceptance Criteria: Specific, tangible tests that clarify what is wanted. Usually added to user stories / backlog items a few days or weeks before the work will be done, to avoid the requirements going stale.

Behaviour Driven Development (BDD) Scenarios: A form of acceptance criteria that allows technical and business people to define how a system should behave in a range of specific scenarios. The format is:

<Scenario name>

Given <A set of preconditions, context, or starting point>

When <An action occurs>

Then <The system should respond in this way>

Technical Spike: Also known as research tasks, these are items in the backlog that provide information on risky or uncertain items that are difficult to estimate. For example, a team may not be able to size the work “Connect to the new system” so they add a technical spike to the backlog: “Spend 2 days experimenting with the new system to product a recommended technical implementation”.

MoSCoW Prioritisation: The practice of planning an agile project with a backlog of features, and nominating each item:

  • Must have
  • Should have
  • Could have
  • Wont have (this time)

Ideal Days Estimation: Teams size backlog items in ideal “productive time” (rather than elapsed time). Often avoided due to a range of undesired consequences:

  • Parkinsons law: The work expands to fill the time available
  • Quality may be put under pressure if the work is more complex than was first thought

Story Point Estimation: Teams size items relative to each other, in arbitrary units not directly tied to duration. The most common scale used is the Fibonacci sequence:

1  2  3  5  8  13  21  34  55  89

Planning Poker: A way of allowing a diverse team of estimators with different specialisms to apply story point estimates to items:

  • Each item is discussed
  • Individuals estimate individually using cards without seeing what their team mates picked (to avoid anchoring bias)
  • Everyone turns over their card simultaneously
  • Differences in opinions are discussed, enhancing the shared knowledge of the team
  • A final number is agreed upon based on the shared information

Top-down planning: The practice of estimating the size of large pieces of work by comparing them as a whole to similar previous projects.

Bottom-up planning: The practice of estimating work by sizing individual items on the backlog.

Velocity: An historical performance metric that shows how much functionality was delivered at the end of previous sprints/iterations. Usually measured in story points, and used by:

  • Product owners to predict release dates for items on the product backlog
  • Development teams to predict what they can deliver in the next sprint/iteration

Agile Testing practices: common techniques include, but are not limited to:

  • Test First Development (TFD) / Test Driven Development (TDD): A technical form of testing usually done by software engineers themselves, that involves writing a failing unit test, then writing just enough code to make it pass
  • Specification by Example: The practice of providing examples of the data or output that would be expected for an upcoming feature.
  • Behaviour Driven Development (BDD): Creating tests based on BDD Scenarios, operating at a functional level and fulfilling a similar job to traditional regression tests.
  • Acceptance Test Driven Development: Similar to TFD/TDD, but rather than operating at the technical / unit test level, it operates at the functional level. A common form is to write a failing automated BDD scenario, and then write enough code to make it pass.

Sprint planning: An event where the whole team get together to make a plan for the next sprint. The product owner brings the product backlog with items at the top in a suitable state to plan. Each item is clarified, before the development team break it down into a detailed plan. The timebox for this event is typically 8 hours for a 4-week sprint.

Daily Scrum: Also known as the daily stand-up or team synchronisation meeting, the purpose is for the team to inspect progress towards their goal, share relevant information, and adapt their plan as necessary. The timebox for this event is typically 15 minutes, and takes place at the same time and place every 24 hours.

Sprint Review: Also known as the show & tell, the purpose is to allow collaboration between the agile team and the business. The work completed is inspected along with the current product backlog and release plan. All parties participate in giving feedback and discussing options with a view to adapting the product backlog and improving the plan based on new information. The timebox for this event is typically 4 hours for a 4-week sprint. 

Sprint Retrospective: the purpose is to allow the agile team to inspect and adapt the process based on their experiences in the last sprint. The whole team identifies what went well, and what didn’t go well, before committing to at least one specific, actionable improvement to take into the next sprint. The timebox for this event is typically 3 hours for a 4-week sprint.

Team Geographies: Most agile teams are arranged by one of the following patterns:

  • Co-located / Face to Face teams all work in the same physical location, allowing easy communication and ad-hoc problem solving
  • Multisite teams are co-located across 2 or more sites
  • Distributed teams are dispersed in a combination of multi-site groups and individuals working from home or alone on-site

Five Centrifugal Forces of Distributed teams:

  1. Communication breakdown
  2. Co-ordination breakdown
  3. Loss of communication richness
  4. Loss of team bonding
  5. Cultural differences

Mitigating factors for distributed teams: steps that can be put into place to address the five centrifugal forces:

  • Video conferencing
  • Knowledge management systems
  • Collaboration platforms
  • Instant messaging
  • Interactive whiteboards

Burn-down charts: used by teams to understand progress towards the work forecast for the sprint/iteration. They track work remaining vs time, often measured in hours or subtasks.


Free Interactive Learning

Visit our schedule

Agile Factsheets

Check out our useful agile factsheets

Agile Factsheets

Financial Times UK's Leading Management Consultants

Sign up for our newsletter

Keep up to date with all the latest business agility news