Agile Glossary and Terminology: 100+ Essential Terms

Whether you’re just beginning your Agile journey or looking to deepen your knowledge, understanding the vocabulary of Agile methodologies is essential for effective implementation. This comprehensive glossary covers key Agile terms, practices, and concepts that development teams use daily.

From the fundamental principles of the Agile Manifesto to specialized terminology used in Scrum, Kanban, and other frameworks, this guide will help you navigate the language of modern software development. We’ve organized these terms into logical categories and provided clear explanations with practical examples from real-world projects.

Key Takeaways

• Learn essential Agile terminology organized by methodology and application

• Understand key roles, artifacts, and events in various Agile frameworks

• Discover how Agile concepts translate to practical implementation

• See how TechTIQ Solutions applies these terms in real-world projects

• Gain clarity on often confused or misused Agile terms

Key Agile Definitions

Before diving into the full glossary, here are the 10 most important Agile terms you should know:

1. Agile: A set of values and principles emphasizing iterative delivery, team collaboration, customer feedback, and ability to respond to change.

2. Sprint: A time-boxed period (typically 2-4 weeks) during which a specific set of work is completed and made ready for review.

3. User Story: A short description of a feature told from the perspective of the end user, following the format “As a [user], I want [feature] so that [benefit].”

4. Product Backlog: An ordered list of everything that might be needed in the product, serving as the single source of requirements.

5. Scrum: A framework within which people can address complex problems while productively delivering products of the highest possible value.

6. Kanban: A visual method for managing work with an emphasis on just-in-time delivery and not overloading team members.

7. Velocity: A measure of the amount of work a team can tackle during a single Sprint, used for planning and forecasting.

8. Retrospective: A meeting where the team reflects on their process and identifies improvements for future work.

9. Definition of Done: A shared understanding of what it means for work to be complete, ensuring transparency and quality.

10. Minimum Viable Product (MVP): A version of a product with just enough features to satisfy early customers and provide feedback for future development.

Fundamental Agile Concepts

Agile

A set of values and principles for software development that emphasizes iterative delivery, team collaboration, customer feedback, and ability to respond to change. Based on the Agile Manifesto created in 2001.

Agile Manifesto

The foundational document of Agile created in 2001 by 17 software developers. It outlines four values and twelve principles that guide Agile methodologies.

Iterative Development

The practice of building software in small, consumable increments rather than trying to deliver everything at once. Each iteration delivers a working piece of software.

Incremental Development

Development of a product through successive additions of functional capabilities. Each increment builds on previous functionality.

Self-organizing Team

A team that manages its own work, shifting the balance of responsibility from managers to the team members. The team determines how best to accomplish their work.

Cross-functional Team

A team composed of members with all the skills necessary to deliver the product, including development, testing, business analysis, and design skills.

Value-driven Delivery

The practice of prioritizing work that delivers the most customer value first, ensuring that the most important features are developed early in the project.

Technical Debt

The implied cost of future rework caused by choosing an easy solution now instead of a better approach that would take longer. Agile teams try to minimize technical debt through practices like refactoring.

Scrum Terminology

Scrum

A framework within which people can address complex problems while productively and creatively delivering products of the highest possible value. It consists of roles, events, and artifacts.

Sprint

A time-boxed period (typically 2-4 weeks) during which a specific set of work is completed and made ready for review. All Scrum projects consist of successive sprints.

Sprint Planning

An event that defines what can be delivered in the upcoming sprint and how that work will be achieved. The entire Scrum team participates in this meeting.

Daily Scrum (Daily Standup)

A 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. Typically conducted standing up to keep the meeting short.

Sprint Review

A meeting held at the end of each Sprint to inspect the increment and adapt the Product Backlog if needed. Stakeholders collaborate with the Scrum Team to review what was accomplished.

Sprint Retrospective

A meeting where the team reflects on the past Sprint and identifies improvements for the next Sprint. It focuses on processes, relationships, and tools.

Scrum Master

The person responsible for ensuring Scrum is understood and enacted. They serve the Development Team, the Product Owner, and the organization.

Product Owner

The person responsible for maximizing the value of the product and the work of the Development Team. They manage the Product Backlog and ensure it is visible and understood.

Development Team

The group of professionals who do the work of delivering a potentially releasable increment of “Done” product at the end of each Sprint. They are self-organizing and cross-functional.

Product Backlog

An ordered list of everything that is known to be needed in the product. It’s the single source of requirements for any changes to be made to the product.

Sprint Backlog

The set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.

Increment

The sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the increment must be “Done.”

Definition of Done (DoD)

A shared understanding of what it means for work to be complete, ensuring transparency and quality. When a Product Backlog item meets the Definition of Done, an Increment is born.

Sprint Goal

A short, concise statement of what the team plans to achieve during the Sprint. It provides guidance to the Development Team on why it is building the Increment.

Velocity

A measure of the amount of work a Development Team can tackle during a single Sprint. It’s calculated by totaling the story points for all fully completed user stories at the end of the Sprint.

Burndown Chart

A graphical representation of work left to do versus time. It shows the rate at which story points are completed and helps predict when all work will be done.

Burnup Chart

Similar to a burndown chart, but it shows the amount of completed work versus the total amount of work planned. It’s useful when the scope changes during the project.

Scrum vs. Kanban: When to Use Each Method

Kanban Terminology

Kanban

A method for managing knowledge work with an emphasis on just-in-time delivery while not overloading team members. Work items are visualized to give participants a view of progress and process.

Kanban Board

A visual management tool used to represent work items through a workflow. Typically consists of columns representing different stages of work (e.g., To Do, In Progress, Done).

Work In Progress (WIP) Limits

Constraints applied to how many items can be in each workflow state at any time. WIP limits help identify bottlenecks and maintain flow.

Swimlane

A horizontal categorization on a Kanban board that allows teams to organize work items by type, priority, or team.

Lead Time

The total time from when a task enters the workflow until it is delivered. It includes both working and waiting time.

Cycle Time

The amount of time a work item spends in the active workflow states (excludes backlog or completed states). It represents the time actually spent working on an item.

Flow

The movement of work items through the process at a steady and predictable rate. Optimizing flow is a key goal of Kanban.

Pull System

A principle where team members pull new work only when they have capacity, rather than having work pushed onto them regardless of their capacity.

Class of Service

A categorization of work items based on urgency and impact, which helps determine how they should be treated as they move through the workflow.

Extreme Programming (XP) Terminology

Extreme Programming (XP)

An Agile framework that emphasizes technical excellence and customer satisfaction through practices like pair programming, test-driven development, and continuous integration.

Pair Programming

A practice where two programmers work together at one workstation. One, the driver, writes code while the other, the navigator, reviews each line as it’s typed.

Test-Driven Development (TDD)

A development process where tests are written before the code, which is then developed to pass those tests. The cycle is: write a test, run it to see it fail, write code to make it pass, refactor.

Continuous Integration (CI)

The practice of merging all developer working copies to a shared mainline several times a day, with automated tests verifying each integration.

Refactoring

The process of restructuring existing code without changing its external behavior. Its purpose is to improve non-functional attributes like readability, complexity, and maintainability.

Collective Code Ownership

A practice where any developer can change any code to add functionality, fix bugs, or improve design. It reduces bottlenecks and encourages knowledge sharing.

Sustainable Pace

The principle that teams should work at a pace that can be sustained indefinitely, avoiding burnout and maintaining consistent productivity.

Simple Design

A principle advocating for the simplest design that achieves the current requirements, rather than building for potential future needs (YAGNI – You Aren’t Gonna Need It).

Lean Software Development Terminology

Lean Software Development

An adaptation of lean manufacturing principles to the software development domain, emphasizing elimination of waste, continuous improvement, and respect for people.

Value Stream Mapping

A lean technique used to analyze the flow of materials and information required to bring a product to a customer. In software, it helps identify and eliminate waste in the development process.

Waste

Any activity that doesn’t add value to the customer. In software development, examples include unnecessary features, waiting, and defects.

Amplify Learning

A lean principle encouraging practices that increase knowledge creation and sharing, such as short feedback cycles and set-based development.

Defer Commitment

Making decisions at the last responsible moment, when the most information is available, rather than prematurely committing to a specific approach.

Deliver Fast

Focusing on short delivery cycles to provide value quickly and get feedback for improvement.

Respect People

Recognizing that people are the most important resource in software development and creating an environment where they can do their best work.

Optimize the Whole

Taking a system-wide view of performance rather than optimizing individual parts, which can lead to suboptimization of the entire system.

User Story and Requirements Terminology

User Story

A short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

Acceptance Criteria

Conditions that a product must satisfy to be accepted by a user, customer, or other stakeholders. They are part of a user story and define when a story is complete.

INVEST Criteria

A set of characteristics of good user stories: Independent, Negotiable, Valuable, Estimable, Small, and Testable.

Epic

A large user story that is too big to be completed in a single iteration and needs to be broken down into smaller stories.

Theme

A collection of related user stories that together fulfill a larger business objective.

Feature

A service that the system provides to fulfill one or more stakeholder needs. Features are often composed of multiple user stories.

Story Mapping

A technique for arranging user stories to create a more holistic view of how they fit into the user experience. Stories are organized into a narrative flow along a timeline.

Three Cs

The three components of a user story: Card (written description), Conversation (discussion about details), and Confirmation (acceptance criteria).

Story Points

A unit of measure for expressing an estimate of the overall effort that will be required to implement a product backlog item.

Planning Poker

A consensus-based estimation technique where team members make estimates by playing numbered cards face-down, then revealing them simultaneously.

MoSCoW Method

A prioritization technique where requirements are categorized as Must have, Should have, Could have, or Won’t have (this time).

Agile Estimation and Planning Terminology

Release Planning

The process of creating a high-level plan for multiple iterations ahead, determining what functionality can be delivered by what date.

Iteration Planning

The process of selecting and estimating the user stories to be completed in the upcoming iteration, and breaking them down into tasks.

Relative Estimation

Estimating tasks or user stories by comparing them to others rather than assigning absolute values. This is typically done using story points or t-shirt sizes.

Affinity Estimating

A technique where team members group items of similar size together, creating “buckets” of complexity or effort.

T-shirt Sizing

An estimation technique where items are classified into t-shirt sizes (XS, S, M, L, XL) based on their relative complexity or effort.

Capacity

The amount of work a team can handle in a given iteration, typically measured in story points or ideal days.

Velocity

The amount of work a team completes in an iteration, typically measured in story points. It’s used for forecasting and planning future iterations.

Rolling Wave Planning

A planning approach where near-term work is planned in detail, while future work is planned at a higher level, with details added as the work gets closer.

Ideal Days/Hours

A measure of effort that represents how long a task would take if there were no interruptions or distractions.

Task

A specific piece of work that needs to be done as part of delivering a user story. Tasks are typically estimated in hours and assigned to team members.

Agile Metrics and Measurements

Burndown Chart

A graphical representation of work remaining over time, used to track progress within a sprint or release.

Burnup Chart

A graphical representation of completed work over time, showing both the total scope and completed work.

Cumulative Flow Diagram

A chart showing the number of work items in each state over time, used to visualize flow and identify bottlenecks.

Control Chart

A graph that shows the cycle time of completed items over time, helping teams identify variability and stability in their delivery process.

Lead Time

The time elapsed from when a request is made until it is fulfilled, including both active work time and wait time.

Cycle Time

The time elapsed from when work begins on a request until it is completed, excluding wait time before work begins.

Throughput

The number of work items completed per unit of time, typically measured per day or per iteration.

Flow Efficiency

The ratio of value-adding time to total lead time, indicating how much time is spent actively working on an item versus waiting.

Escaped Defects

Defects that were not caught during development and testing but were discovered after delivery to customers.

Technical Debt Ratio

A measure of the effort required to fix problems relative to the effort required to develop the system.

Trending Agile Terms in 2025

Based on current industry trends, these Agile terms are gaining significant traction:

1. Value Stream Management: The evolution of value stream mapping into a comprehensive approach to managing and optimizing the flow of value through the entire software delivery lifecycle.

2. Agile Product Operations: A framework that applies Agile principles to product management and operations, emphasizing continuous discovery and delivery.

   
   

3. Remote Agile Ceremonies: Specialized techniques and tools for conducting effective Agile events with distributed teams.

4. Flow Metrics: Measurements focused on the smooth and efficient delivery of value, rather than just team activity or output.

5. Agile Governance: Approaches to providing oversight and compliance in Agile environments without compromising agility.

Scaling Agile Terminology

Scaled Agile Framework (SAFe)

A set of organization and workflow patterns intended to guide enterprises in scaling lean and agile practices across the organization.

Large-Scale Scrum (LeSS)

A framework for scaling Scrum to multiple teams working together on a single product, maintaining the principles of Scrum while addressing the challenges of large-scale development.

Nexus

A framework developed by Scrum.org for scaling Scrum to multiple teams working on a single product, with an emphasis on integration challenges.

Disciplined Agile (DA)

A process decision framework that provides guidance for teams to make better choices about their ways of working (WoW) in context.

Agile Release Train (ART)

A long-lived team of Agile teams, typically consisting of 50-125 individuals, that plan, commit, and execute together. Used in SAFe.

Program Increment (PI)

A timebox in SAFe where Agile Release Trains deliver incremental value in the form of working, tested software and systems.

Scrum of Scrums

A technique for scaling Scrum to multiple teams by having representatives from each team meet regularly to coordinate and address cross-team dependencies.

Communities of Practice

Groups of people who share a concern or passion for something they do and learn how to do it better as they interact regularly.

Value Stream

The series of steps an organization uses to create and deliver products or services to customers.

Feature Team

A long-lived, cross-functional team that completes end-to-end work by delivering customer features.

DevOps and Continuous Delivery Terminology

DevOps

A set of practices that combines software development (Dev) and IT operations (Ops) to shorten the development lifecycle while delivering features, fixes, and updates frequently and reliably.

Continuous Integration (CI)

The practice of automating the integration of code changes from multiple contributors into a single software project.

Continuous Delivery (CD)

The ability to get changes of all types—including new features, configuration changes, bug fixes, and experiments—into production safely and quickly in a sustainable way.

Continuous Deployment

The practice of automatically deploying every change that passes all stages of the production pipeline to customers.

Deployment Pipeline

An automated manifestation of the process for getting software from version control to users.

Infrastructure as Code (IaC)

The practice of managing and provisioning infrastructure through code instead of manual processes.

Feature Toggle

A technique that allows features to be toggled on or off during runtime, enabling deployment of partially completed features or selective rollout to specific users.

Blue-Green Deployment

A deployment strategy where two identical production environments (blue and green) exist, with only one serving production traffic at any time.

Canary Release

A technique to reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users before rolling it out to the entire infrastructure.

Shift Left

The practice of moving testing, security, and other concerns earlier in the development process to identify and fix issues sooner.

Real-World Application at TechTIQ Solutions

At TechTIQ Solutions, we apply these Agile terms and concepts in our daily work to deliver high-quality software efficiently. Here’s how some of these concepts translate to practice in our projects:

Case Study: Agile Implementation in Mobile App Development

For the Bike To Work mobile app project, TechTIQ Solutions implemented Scrum with two-week sprints. The team used:

• Daily Standups: 15-minute meetings each morning where team members discussed progress and obstacles

• Sprint Planning: Bi-weekly sessions to determine which user stories would be tackled in the upcoming sprint

• Story Points: Relative estimation to predict how much work could be completed each sprint

• Burndown Charts: Visual tracking of progress throughout each sprint

• Definition of Done: Clear criteria including code review, testing, and documentation

The project faced challenges with a remote backend team in Norway, but regular sprint reviews allowed for continuous feedback and alignment. By focusing on delivering working features in each sprint, the team was able to adapt to changing requirements while maintaining progress.

Case Study: Kanban for Maintenance Projects

For ongoing maintenance and enhancement of the Mobile Team Manager platform, TechTIQ Solutions implemented a Kanban approach:

• Kanban Board: Visualized workflow with columns for Backlog, Ready, In Development, Testing, and Done

• WIP Limits: Restricted work in progress to 2 items per developer to maintain flow

• Pull System: Team members pulled new work only when they had capacity

• Lead Time: Measured the time from request to delivery to set client expectations

• Continuous Delivery: Implemented automated testing and deployment to deliver fixes quickly

This approach allowed the team to respond quickly to critical issues while continuing to make progress on planned enhancements, providing maximum value to the client.

Common Misconceptions About Agile Terminology

Common Misunderstandings in Agile Terminology

Agile vs. Scrum

Many people use these terms interchangeably, but Agile is a set of values and principles, while Scrum is a specific framework for implementing Agile.

Velocity vs. Capacity

Velocity is a measurement of past performance (how much was completed), while capacity is a forecast of future performance (how much can be done).

Sprint Goal vs. Sprint Backlog

The Sprint Goal is a single, coherent objective for the Sprint, while the Sprint Backlog is the collection of items selected for the Sprint plus the plan for delivering them.

Done vs. Potentially Shippable

“Done” refers to meeting the Definition of Done criteria for a story, while “potentially shippable” means the increment could be released to users if desired.

Estimate vs. Commitment

An estimate is a forecast of how long something might take, while a commitment is a promise to deliver something by a specific time.

Conclusion

Understanding Agile terminology is essential for effective communication within Agile teams and organizations. This glossary provides a foundation for navigating the Agile landscape, but remember that the true value of Agile comes not from using the right terms but from embracing the principles behind them.

Whether you’re implementing Scrum, Kanban, or a hybrid approach, the focus should always be on delivering value to customers through collaborative software development and continuous improvement.

At TechTIQ Solutions, we’ve seen how proper implementation of Agile practices leads to better outcomes for complex enterprise projects and simpler applications alike. The key is selecting the right approach for your specific context and continuously refining your process.

Ready to Implement Agile in Your Organization?

TechTIQ Solutions can help you implement Agile methodologies tailored to your specific needs. Our experienced team has successfully applied Agile principles across numerous projects and can guide your organization through the Agile transformation process.

Contact us to discuss how we can support your Agile implementation:

• Email: [email protected]

• Phone: (+65) 8898 2997

• Address: 28 Sin Ming Lane #02-145, Midview city, Singapore 573972

Frequently Asked Questions

How do I choose between Scrum and Kanban for my project?

Choose Scrum when your project has defined iterations, stable teams, and benefits from regular planning cycles. Kanban works better for maintenance work, support tasks, or when priorities frequently change. Scrum provides more structure, while Kanban offers more flexibility. Some teams also implement “Scrumban,” combining elements of both approaches.

What’s the difference between a Sprint Review and a Sprint Retrospective?

The Sprint Review focuses on the product and what was built, with stakeholders providing feedback on the completed increment. The Sprint Retrospective focuses on the process and how the team worked together, with only the Scrum team participating to identify improvements for future sprints.

How should we handle urgent work that comes up during a Sprint?

For truly urgent issues, the Product Owner may negotiate with the Development Team to replace a Sprint Backlog item with the urgent work. For predictable but irregular work, some teams set aside capacity (buffer) within each Sprint. Alternatively, some organizations implement a Kanban system alongside Scrum to handle support or maintenance work.

What metrics should we track for our Agile implementation?

Start with basic metrics like velocity, sprint burndown, and release burnup to track progress. Also consider measuring technical debt, defect rates, and customer satisfaction. Mature teams often track lead time, cycle time, and flow efficiency to optimize their process. Remember that metrics should drive improvement, not just measure compliance.

How do we scale Agile practices for large organizations?

Start by establishing strong Agile practices at the team level before scaling. Consider frameworks like SAFe, LeSS, or Nexus based on your organizational context. Focus on coordination mechanisms like Scrum of Scrums or Communities of Practice to address cross-team dependencies. Most importantly, maintain Agile principles even as you scale the practices.