A

Acceptance Criteria

Specific conditions or requirements that must be met for a user story or feature to be considered complete and accepted by stakeholders.

Agile Board

A way to visualise the work being done by the agile team. Often used in Kanban systems to see the work in progress at each stage of the system. This is an example of an Information Radiator.

Agile Coach

The person who helps the team, department or organisation understand the values, principles, practices and mindset of agile approaches. In an agile team, the agile lead (the scrum master for scrum teams) is accountable for coaching that team.

Agile Coaching

The process of helping teams, departments and organisations better understand agile values, principles and mindset, as well as the specific practices of agile methods.

Agile Manifesto

The manifesto for agile software development was 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 Practice

Refers to the application of agile principles and methodologies, such as Scrum or Kanban, in managing and delivering projects, emphasizing iterative development, collaboration, and adaptability.

Anti-pattern

A common solution or approach to a problem that appears to be helpful, but ultimately leads to negative consequences or poor outcomes, often contrary to established best practices.

Automated Testing

Automated tests are scripted tests that run automatically. These are often included in a continuous deployment pipeline where they run every time code is committed and, if the tests fail, prevents the deployment of faulty code. Often built into a comprehensive regression test suite to ensure new changes do not cause defects in established code.

B

Backlog Refinement

The activity of adding additional detail and analysis to items on a product backlog. This often includes:

• 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.

Backlogs

An ordered list of items to be completed. Backlogs should be visible so that they can be inspected and adapted. In Scrum there are two backlogs, one representing future work (Product Backlog) and current work (Sprint Backlog).

Behaviour Driven Development (BDD)

A form of acceptance criteria that allows technical and business people to define how a system should behave in a range of specific scenarios. Tests are based on scenarios, operating at a functional level and fulfilling a similar job to traditional regression tests.The format for each scenario is:<Scenario name>Given <A set of preconditions, context, or starting point>When <An action occurs>Then <The system should respond in this way>

Big Bang Delivery

A software development approach where a complete system or a significant portion of it is deployed and delivered all at once, typically without incremental or iterative releases.

Big Room Planning

A collaborative planning technique used in Scaled agile methodologies where multiple teams, stakeholders, and product owners come together in a single physical or virtual room to coordinate and align their work for upcoming iterations or releases.

C

Cadence

The rhythm of events in an agile team, typified by event taking place at regular, predictable intervals. For example, Sprint Planning taking place every two weeks on a Wednesday morning.

Component Team

A specialized team within a larger development effort that focuses on developing and maintaining specific components or modules of a software system, often working closely with other teams to integrate their components into the overall solution.

Context diagram

A visual representation that illustrates the boundaries and interactions between a system and its external entities.

Continuous Deployment (CD)

An automated process where completed code is automatically tested and deployed to the various technical environment such as testing, staging or production. Usually combined with Continuous Integration and Automated Testing, which must be passed before the deployment takes place.

Continuous Integration (CI)

An automated process where completed checked in code is picked up by an integration build machine and the results fed back to the development team. Often used in conjunction with Automated Testing.

D

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.

Daily Stand-up Meetings

See Daily Scrum

Definition of Done (Done)

I list of criteria that must be achieved by the agile team to consider an item completed or ‘Done’. The definition of done is not item specific, must be able to be completed by the agile team itself, and needs to be specific enough so that it is clear whether it is achieved or not.

Definition of Ready

A set of criteria or conditions that a user story or product backlog item must meet before it can be considered ready for development.

Development Team

A Scrum role. 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: 3 - 9

DevOps

DevOps is an amalgamation of tools, techniques and process to align Development and Operations activities, using lean principles.

E

Emergent Design

Allowing the technical design to emerge during the development process so information learned can be applied to the design. This is the alternative to a traditional Big Design Up Front (BDUF) model.

Empathy map

A visual tool used to understand and empathize with users or customers by capturing their thoughts, feelings, behaviours, and needs in a structured manner.

Empiricism

A principle of empirical process control in agile methodologies, emphasizing that knowledge and decisions should be based on observations, experimentation, and evidence rather than assumptions or speculation.

Estimation

The process of forecasting the size of different items of work on a backlog. Agile teams often use relative sizing and story points.

Essence

An Open Standard for software engineering that provides a common language and set of practices to describe and assess the essence of software development.

Extreme Programming (XP)

An agile framework similar to Scrum with an emphasis on technical excellence and close customer collaboration.

F

Feature

A distinct capability or functionality provided by a software system or product that delivers value to users or stakeholders.

Feature Team

A cross-functional team composed of members with different skills and expertise working together to deliver end-to-end features or user stories.

Functional Requirement

A specific statement that describes the desired behaviour or functionality of a software system or product.

G

Generalising Specialist

A member of an agile team who is highly skilled in at least one area but has enough capability in other areas and can assist the team if that is a key task to meet the team’s goals. For example, a specialist front-end developer who can also write some automated testing scripts or do some database work. Also known as a ‘T-Shaped Professional’.

H

History of Agile

1948: The Toyota Way was codified, taking inspiration from a U.S. Grocery store, marking the beginning of the Lean movement in manufacturing1995: Scrum was presented publicly for the first time, at the OOPLA conference2001: A group of thought leaders created the Manifesto for Agile Software Development

I

Increment

A potentially releasable piece of work. In Scrum, this is one of the artifacts and represents the output of the latest sprint combined with all previous Increments.

Information Radiators

A physical (or electronic) display of information that is designed to allow interested parties access to that information without the need for team member to specifically relay it. Examples include Agile Boards, digital displays showing service availability or the state of the latest software builds.

Iteration

A timeboxed and repetitive development cycle in Agile methodologies, where a subset of features or user stories is implemented, tested, and reviewed within a fixed time period. In Scrum this is a Sprint

Iteration Planning

See Sprint Planning

Iteration Review

See Sprint Review

INVEST

A nmemonic to help set standards for the quality of analysis for product backlog items. By the time a backlog item reaches the point where it may be discussed at Sprint Planning, it should have the following characteristics:

• Independent - the item should not rely on future work to be worth building

• Negotiable - developers should be able to propose alternative solutions to deliver the capability needed

• Valuable - the value that an item brings should be defined and understood by all

• Estimatable - it should be possible to forecast the amount of effort needed

• Sized appropriately - small enough for several items to be completed in one sprint by one team

• Testable - it should be clear to all when an item has met the requirements

K

Kaizen

A Japanese term referring to continuous improvement in processes, products, and services by making small incremental changes over time.

Kanban

A method managing the flow of valuable work. The principles of Kanban manage and improve work across systems. It is not limited to software and has 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.

L

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 Seven Wastes

The seven wastes of lean software development are:

1. Inventory. Partially done work that cannot be used by the customer. Including things that are complete but not able to be used. (such as awaiting security or legal sign-off)

2. Overproduction. Features or documentation that are not needed or do more than the customer requires (including delivering things that may be required later but not now)

3. Extra processing. Re-learning things that are already known. (I.E. Through not sharing information or components)

4. Transportation. Handoffs between teams. (EG has separate development and test teams)

5. Waiting. Delays of any kind

6. Motion. Context switching. (EG by working on multiple things at once or being called away for support tasks frequently)

7. Defects. 

M

Mean Time to Restore

One of the possible value measures. A metric that measures the mean (average) time to recover after an incident.

Minimum Marketable Product (MMP)

The smallest set of features or functionalities that can be released to the market and provide value to customers.

Minimum Viable Product (MVP)

A version of a product that includes enough core features and functionalities required to run as an experiment and gain valuable feedback

Mob Programming

When many people crowd round a single computer to work out a tricky problem. It is good for preventing blockers that would otherwise take time to resolve. Sometimes referred to as ‘swarming’.

MoSCoW

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

• Must have

• Should have

• Could have

• Won’t have (this time)

N

Non-functional Requirement

A specification that describes the characteristics, qualities, or constraints of a software system, such as performance, security, reliability, or usability.

P

Pair Programming

Two team members working on the same computer to build a feature. One person ‘drives’ and the other person navigates, collaborating and watching out for errors.

PDCA Loop

Plan, Do, Check, Act is an iterative, four-stage method to repeatedly improve a product, service or process.

Persona

A fictional character or archetype that represents a specific user or customer segment, created to understand their goals, behaviours, needs, and motivations in the context of product design and development.

Planning Poker TM[1]

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 teammates 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

Product Backlog

An ordered list of items to be done to enhance or maintain a product. Items at the top of the list, which are likely to be worked on first, have had the necessary analysis for them to be worked on by the team. Items lower on the list will have had less analysis.

Product Owner

A Scrum role. 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

Program Increment

A timeboxed period in SAFe (Scaled Agile Framework) where multiple Agile Release Trains (ARTs) work together to deliver a set of features and incrementally build a larger solution.

Psychological Safety

A shared belief held by members of a team that the team is safe for interpersonal risk taking. It allow team members to be vulnerable in front of each other, for example by asking questions where they may otherwise be perceived as ignorant for not knowing the answer. A key ingredient for high performing teams.

R

Refactoring

The process of optimising and cleaning up code without changing the functionality. A key element in Test Drive Development (TDD). Refactoring helps reduce technical debt.

Relative sizing

A process where items are estimated in compared to each other rather than given absolute values. Story Points are often used when conducting relative sizing. Alternative options include ‘T-Shirt Sizing’, where items are grouped into Small, Medium, Large, etc.

Release Planning

The process of forecasting when a set of features will be delivered or, for a fixed date, which feature will be completed by the required date.

Retrospectives

A meeting to look back and identify possible improvement to how the team performs with regard to quality, tools, process and collaboration. For Scrum, see Sprint Retrospectives.

Requirement

A formal statement that specifies what a software system or product should do or how it should behave, typically derived from user needs or business objectives.

Roadmap

A strategic plan or visual representation that outlines the high-level goals, features, and timeline for the development and release of a product or software system.

S

Scrum

An agile product delivery framework comprising 3 roles, 5 events, and 3 artefacts and 5 values based on empirical process control. Work is limited by fixed-length sprints of 30 days or fewer.

Scrum Master

A Scrum role. 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

Scrum-of-Scrums

An event where representatives from different Scrum teams meet to collaborate and coordinate the integration of work across their respective teams.

Scrum Team Member

The scrum master, product owner or a member of the scrum development team. These are the people who plan and do the work in the team.

Scrum Three Pillars

Scrum is built on empirical process control on the basis that complex work is best managed through a process implementing:

• Transparency over the plan and progress made so far

• Inspection of the plan and the process based on the most up to date information

• Adaptation of the plan and process with a goal of maximising the value delivered

Scrum implements transparency through the artefacts, and all events enable inspection and adaption of specific parts of the process and the plan.

Servant Leader

A servant leader is someone who supports the team and leads them without direct authority. Success of a servant leader is measured by the growth of the team and individuals within it.

Shu Ha Ri

A concept originating from martial arts that represents the stages of learning and mastery, It represents the evolution from initially following prescribed practices (Shu), to adapting and customizing them (Ha), and finally, reaching a state of self-directed mastery and innovation (Ri).

Spike

A time-boxed task or experiment undertaken by a development team to gather information, explore a problem, or assess the feasibility of a solution before committing to a full implementation. There are different types such as Architectural and Risk Spikes.

Sprint

A fixed period of not more than 30 calendar days during which an agile team deliver an increment of work. A Sprint is one of the five events in Scrum.

Sprint Backlog

The list of tasks to be completed in a single Sprint/iteration. The team decide how many items to look to completed during the sprint and break the work down into tasks, which go onto the sprint backlog.

Sprint Planning

A Scrum 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.

Sprint Retrospective

Also known as the iteration 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.

Sprint Review

Also known as the iteration review or 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. 

Squads

Squads are small cross-functional teams typically fewer than 8 that have a single focus or mission. They typically have an agile coach to guide them and a product owner to provide product direction. Unlike scrum teams, squads can use any agile framework they choose.

Stakeholder

Any individual, group, or organization that has an interest or involvement in a project, product, or system and can influence its outcome or be affected by its results.

Story Points

Teams size items relative to each other, in arbitrary units not directly tied to duration. The most common scale used is the adjusted Fibonacci sequence:1, 2, 3, 5, 8, 13, 20, 40, 100

Sustainable Pace

Working at a pace that can be sustained over the long term. Practices include working to a standard 8 hour day and under planning so that there is minimal reliance on overtime or similar. This generally results in less burnout, fewer defects and fewer project delays.

T

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, then refactoring to improve the code.

Time-box/Time-boxing

Based on temporal motivational theory, a timebox is the maximum amount of time permitted for an activity, creating a sense of pressure to complete the work. It is 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.

Two-Factor Authentication

A security measure that requires users to provide two forms of authentication (such as a password and a unique code from a mobile app) to verify their identity and access a system or service.

T-Shaped Professional

See Generalising Specialist.

U

Use Case

A description of interactions between actors (users or systems) and a system to achieve a specific goal or result, often represented as a narrative or a diagram.

Use Case Diagram

A visual representation that illustrates the relationships between actors, use cases, and the interactions within a system or product.

User Role

A defined set of permissions, privileges, or responsibilities assigned to a user within a system or application, determining their access and functional capabilities.

User Story

A simple but incomplete way of expressing requirements on a product backlog to allow the high-level intent to be understood and to foster a conversation between developer and customer. They contain just enough detail to decide how to prioritise, and whether to start analysing further. The most common format is:<Title>As a <Role>I want <Functionality>So that <Benefit or value>

User Story Mapping

A technique used in Agile product development to visually organize and prioritize user stories, creating a coherent representation of the product backlog and user flow.

UX Design

User Experience Design focuses on enhancing user satisfaction by improving the usability, accessibility, and overall interaction between users and a product or system.

V

Velocity

A 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

V-Model

A type of Software Development Life Cycle (SDLC) model where the process starts with Requirement Analysis then does through System Design, Architecture Design, Module Design, Coding, Unit Testing, Integration testing, System testing and Acceptance testing. Depicted in a ‘V’ shape with ‘Coding’ at the base. The idea is that the analysis gets increasingly detailed, then it is coded, the testing starts very granular and completes with the acceptance tests. A tradition, non-agile model.

Volatile, Uncertain, Complex and Ambiguous (VUCA)

Agile approaches are likely to achieve better results than traditional approaches for work that displays VUCA characteristics.

• Volatility - Things are likely to change rapidly without warning

• Uncertainty - There is a lack of information available

• Complexity - There are many interconnected variables and decisions to manage

• Ambiguity - Available information is difficult to interpret

W

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. A high risk approach in a VUCA environment.

Wideband Delphi

A consensus-based estimation technique that involves a group of experts independently providing estimates for tasks or project components, followed by group discussion and iteration to converge on a final estimate.

Working Solution

A software product or system that is functional, meets the specified requirements, and provides value to users or stakeholders.

[1] ‘Planning Poker’ is a trademark of Mountain Goat Software