Agile Glossary

Common terms used when discussing Agile

Agile methods have gained widespread acceptance in software development organizations for formulation, development, and continuous delivery of new and effective solutions. Learn the unique terminology used in Agile development from the experts at CRi. This Agile glossary provides brief definitions of the central terms and concepts in Agile development and Agile project management.




Acceptance Criteria

Criteria by which a work item (user story) can be judged to have been successfully implemented and tested. A story is ‘done’ when all criteria pass testing; conversely, a story is not ‘done’ if any criteria fail testing. Also referred to as the Conditions of Satisfaction that describe a higher level of conditions that, when met, deliver business value.

Acceptance Testing

The process to validate that a work item (user story) meets the specified acceptance criteria. Ideally, the approach is to automate as much as possible. The result/output of acceptance testing is a report that identifies the status of each acceptance criteria being tested and whether that item passes or fails.

Agile Development

An approach to software development based on principles in the Agile Manifesto. The term “Agile” is an umbrella for several specific methodologies based on iterative development techniques where requirements and deliverables evolve through collaboration between self-organizing, cross-functional teams.

Agile Manifesto

A Manifesto for Agile Software Development is an historical document authored in February of 2001 that defined four key values and twelve principles for lightweight, responsive, adaptable software development.



Also knows as “product backlog,” the backlog is a prioritized list of user stories and defects in order from most valuable to least valuable for a system. Backlogs include both functional and non-functional user stories as well as technical team-generated stories.

Behavior Driven Development (BDD)

Behavior-driven development (BDD) is a technique to document and design an application around the behavior a user expects to experience when interacting with it. By encouraging developers to focus only on the requested behaviors of an app or program, BDD helps to avoid bloat, excessive code, unnecessary features or lack of focus. This methodology combines, augments and refines the practices used in test-driven development (TDD) and acceptance testing driven development (ATDD).

Burndown Chart

Representation of the number of hours remaining for completion of a project; usually represented in chart form with points plotted on an x and y axis that map a downward trend of work left to do until burning down to zero.

Burnup Chart

Representation of the number of stories completed; usually represented in chart form with points plotted on an x and y axis that map an upward trend of work completed until reaching 100%.


Collocation (Collocated Teams)

Collocation refers to development teams located and working in the same location. Collocation is usually applied at the cross-functional team level. Collocation is an important (but not required) concept in Agile development to promote collaboration and osmotic communication.

Conditions of Satisfaction

High-level criteria by which a work item (user story) can be judged to have been successfully implemented and tested to deliver business value. A story is ‘done’ when all conditions pass testing; conversely, a story is not ‘done’ if any conditions fail testing. Conditions of Satisfaction are proved to be met by delivery of working code through Acceptance Testing.

Continuous Integration

Continuous integration, one of the foundational techniques of Agile software development. Infrastructure is configured to support fully automated and reproducible builds, including testing, that runs many times a day. By getting changes into the main line as frequently as possible, preferably daily, and by extending the idea of a nightly build, continuous integration helps reduce integration problems and identify and resolve problems more quickly.

Cross-functional Team

Team comprised of members with all functional skills and specialties necessary to complete a project from start to finish.


Distributed Teams

Development teams that work on the same project but are located across multiple locations or worksites.



A user story which describes a large amount of customer value and needs to be broken down into many smaller user stories.





Inspect and Adapt

An Agile concept where teams evaluate a project by looking at the product, listening to each other’s feedback and ultimately improving the process or changing course.


A time window in which software development activities take place and result in delivery of working software. Traditionally lasting between 2 and 4 weeks, iterations may be as short as 1 week or as long as 3 months. Similar in nature and definition as a “Sprint.”




A conceptual approach to Agile development based on Lean Software Development principles. Kanban has three main components: visual system for managing work, limits work in progress, and work is pulled rather than pushed through the system.



An umbrella term for techniques to maximize customer value while minimizing waste and achieving continuous flow through a sustainable culture of continuous improvement. Lean is a term used in the U.S. for what was originally created as the “Toyota Production System”. Also referred to as Lean Office, Lean Production, Lean Thinking, Lean Enterprise, etc.





Pair Programming

Process in which two developers work together at a single workstation, where one is responsible for typing code and the other for reviewing each line of code as it is typed in.

Planning Poker

A consensus-based technique for estimating; mostly used to estimate effort or relative size of tasks in software development. Planning Poker is useful for building team cohesion and for fostering self-organizing teams.

Product Backlog

A prioritized list of user stories and defects in order from most valuable to least valuable for a system. Backlogs include both functional and non-functional user stories as well as technical team generated stories. Owned by the Product Owner.

Product Owner

A role originating from Scrum but has now been widely adopted independently of Scrum. A product owner manages the product backlog, addresses questions that arise during development and signs off on work results. The product owner guides the team with what should be done and when the final product should be shipped.




The practice of continuously improving the usability, maintainability, and adaptability of code without changing its behavior. One disadvantage is that it takes extra effort and requires changing the code. Refactoring is, at times, used as a method of reducing technical debt.


An increment of potentially shippable product from the development team into routine use by customers. Releases typically happen when one or more sprints has resulted in the product having enough value to outweigh the cost to deploy it. A release balances functionality, cost, and quality requirements against date commitments.


A meeting held at the end of every sprint to reflect on what went well during the sprint and what can be improved upon during the next sprint. Sprint retrospectives are valued as necessary parts of inspecting and adapting and allow development teams to plan for future output.



Agile development project management framework originally developed to guide complex software projects. The framework accommodates complexity by breaking-up a large body of work into several smaller chunks that are worked in small time windows called Sprints. The framework defines three roles; the Scrum Team, Product Owner and Scrum Master. Scrum leaves most development decisions up to the self-organizing Scrum team, where project decisions are reached by team consensus.

Scrum Master

Person trained to facilitate daily Scrum meetings, remove impediments, oversee the team’s progress through the process and track Scrum team updates. The Scrum Master is responsible to enforce the principles and rules of engagement that a Scrum Team has agreed to put in place.


A team, usually found in Scrum, that manages itself through various means of communication and reoccurring structured meetings. Self-organizing teams solve development issues together as a whole and decide the best solution based on input, abilities and experience of the various team members.


Timeboxed investigation of feasibility via a basic implementation experiment or prototype to test out new, unknown, risky or complex technical solutions. The result of a Spike is to inform future implementation decisions.


A Scrum-specific term used to describe an Iteration; although the term is widely used in other Agile approaches.

Sprint Backlog

The plan for a development team that maps out the activities, tasks and labor estimates to implement the User Stories planned for completion in an upcoming sprint.

Sprint Planning

A meeting for Scrum Teams, Scrum Masters and Product Owners where the Product Owner describes priority features to the team. The Scrum Team gets enough of an understanding about the tasks discussed that they are able to choose which ones to move from the product backlog to the sprint backlog.

Sprint Review

In the sprint review, teams go over what stories were completed during the iteration and demonstrate those stories for stakeholders and the product owner.


Any party that has an interest in the product/service produced by an organization’s value stream.

Stakeholder Value

The worth of the stakeholder’s interest in the product/service produced by an organization’s value stream. Sometimes used interchangeably with customer value.


Daily Meetings that are meant to quickly and efficiently resolve obstacles that any team members may be experiencing. A Stand-up meeting is no more than 15 minutes, and focused on answering the questions: “What did you do since we last met? What will do before we meet again? And what obstacles are or may block your ability to meet that commitment?”

Story Points

Relative scale of effort required by a team to implement a user story. A method for estimating the size of an Agile story used as an alternative to estimate the story in hours. Story points compare one story to another to determine a relative size and then assign points denoting that size.



A discrete unit of work. Agile stories are broken down into a collection of tasks that must be performed to complete the story in one sprint. Tasks are typically sized to represent 4 to 8 hours of effort.

Task Board

A physical or electronic board representing the state of tasks in a current sprint, often divided into “to do,” “in progress” and “done.”

Test Driven Development (TDD)

An approach to development which combines “test-first” development practices where you write a test before you write just enough production code to fulfill that test and refactoring.


A collection of Agile stories that have a common affinity. A theme may contain several Epics and many User Stories.


The practice of constraining the amount of time for performing any activity. Examples include iterations, spikes and stand up meetings.


Unit Testing

Tests that exercise small amounts of isolated functionality intended to validate that the written code meets basic acceptance tests.

User Stories

Used with Agile methodologies for specifying requirements and presented as an informal statement of the requirement in natural, simple-to-understand language. User Stories also detail Conditions of Satisfaction (defining “done”) and Acceptance Criteria (defining “done right”).


Value Points

Relative scale of business value expected to be delivered by a User Story or feature.


The velocity of a team is the number of story points associated with stories that are finished over a given period of time(typically an Iteration or Sprint). For instance, if the team completed 8 stories that were each 5 points during a four week sprint, then their velocity is 40 story points every four weeks.



Model of a software development process in which progress flows downwards through phases of conception, initiation, analysis, design, construction, testing and maintenance. Similar phases may be defined as define requirements, design the solution, develop, test, and implement.


XP (Extreme Programming)

“Extreme Programming,” one implementation of the Agile methodology that focuses on producing the simplest coding situation for application requirements and includes practices such as pair programming, incremental design and continuous integration.



Looking for more information?

If you’re interested in our agile services, or looking to have a term defined or expanded on, send us a message.

Agile Services

Advisory Services



Transformation Services

Call Now

☎︎ 402-926-2000