The Agile Coach glossary

Agile teams share a working vocabulary, and small differences in meaning can cause big misunderstandings. This glossary defines the Scrum, Kanban, and software-delivery terms you will hear most often, using the language of the current Scrum Guide where it applies, and notes why each one matters to the people doing the work.

Acceptance criteria: Acceptance criteria are the specific conditions a piece of work must meet to be accepted, written for an individual backlog item such as a user story. They describe expected behavior, often as concrete examples or scenarios. Clear criteria reduce back-and-forth during the Sprint and make it easier to write tests before or alongside the code.; Related:User story Definition of Done Backlog refinement Test-driven development (TDD)
Agile: Agile is an umbrella term for ways of working that deliver value in small increments, gather feedback often, and adapt plans as teams learn. It is grounded in the values and principles of the Manifesto for Agile Software Development rather than in any single method. Scrum, Kanban, and Extreme Programming are among the frameworks and practices commonly described as agile.; Related:Agile Manifesto Scrum Kanban Extreme Programming (XP)
Agile coach: An agile coach helps teams, leaders, and organizations adopt and improve agile ways of working. The role blends coaching, teaching, mentoring, and facilitation, and it often reaches beyond a single team to address management practices and organizational obstacles. A good coach builds the team's own capability so it can keep improving after the coach steps back.; Related:Scrum Master Retrospective Self-managing team Agile
Agile Manifesto: The Manifesto for Agile Software Development was written in 2001 by seventeen software practitioners who met in Snowbird, Utah. It states four values: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. It is supported by twelve principles and remains the shared reference point for what agile means.; Related:Agile Scrum Extreme Programming (XP)Lean
Backlog refinement: Backlog refinement, which the Scrum Guide calls Product Backlog refinement, is the ongoing activity of breaking down and further defining Product Backlog items into smaller, more precise items. It typically adds detail such as descriptions, order, and size. Refinement is not one of the formal Scrum events, but doing it continuously helps items become ready for selection in Sprint Planning.; Related:Product Backlog User story Acceptance criteria Sprint Planning
Burndown chart: A burndown chart plots the amount of work remaining against time, so the line should trend toward zero as work is completed. Teams use it for a Sprint or for a larger release. It is a complementary practice rather than part of the Scrum Guide, and it is most useful as a conversation starter about progress, not as a target to manage toward.; Related:Velocity Story points Sprint Backlog Throughput
Code review: Code review is the practice of having one or more teammates examine code changes before they are merged. It catches defects, spreads knowledge of the codebase, and keeps style and design consistent. Small, frequent reviews tend to move faster and provide better feedback than large, infrequent ones.; Related:Pair programming Trunk-based development Continuous integration (CI)Technical debt
Continuous delivery: Continuous delivery is the practice of keeping software in a releasable state at all times, so any change that passes the automated pipeline could be deployed to production on demand. The final release decision may still be made by a person. It lowers the risk of each release by making deployments small, routine, and repeatable.; Related:Continuous integration (CI)Continuous deployment DevOps DORA metrics
Continuous deployment: Continuous deployment goes one step beyond continuous delivery by automatically releasing every change that passes the pipeline to production, with no manual approval step. It depends on strong automated testing and monitoring, and often on feature flags to separate releasing code from turning features on. Teams that use it get very fast feedback from real users.; Related:Continuous delivery Continuous integration (CI)DevOps Trunk-based development
Continuous integration (CI): Continuous integration is the practice of merging every developer's work into a shared mainline frequently, at least daily, with each change verified by an automated build and tests. It surfaces conflicts and defects while they are still small and easy to fix. CI is the foundation that continuous delivery and continuous deployment build upon.; Related:Trunk-based development Continuous delivery Test-driven development (TDD)Extreme Programming (XP)
Cross-functional team: A cross-functional team has all the skills it needs to create value without depending on people outside the team. The Scrum Guide describes Scrum Teams as cross-functional, meaning members have all the skills necessary to create value each Sprint. This reduces handoffs and waiting, which are common sources of delay.; Related:Scrum Team Self-managing team Developers (Scrum)Flow
Cycle time: Cycle time is the elapsed time between when a work item started and when it finished. The Kanban Guide lists it as one of its core flow measures, alongside work in progress, throughput, and work item age. Shorter, more consistent cycle times make delivery more predictable and help teams make credible forecasts.; Related:Lead time Throughput WIP limit Kanban
Daily Scrum: The Daily Scrum is a 15-minute event for the Developers of the Scrum Team, held at the same time and place each working day of the Sprint. Its purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as needed. The 2020 Scrum Guide removed the traditional three questions, so teams may use any structure that serves that purpose.; Related:Sprint Goal Sprint Backlog Developers (Scrum)Timebox
Definition of Done: The Definition of Done is a formal description of the state the Increment must reach to meet the quality measures required for the product. In the Scrum Guide, it is the commitment attached to the Increment. Work that does not meet it cannot be released or presented at the Sprint Review, which keeps everyone clear about what finished really means.; Related:Increment Acceptance criteria Sprint Review Technical debt
Developers (Scrum): In Scrum, Developers are the people on the Scrum Team who are committed to creating any aspect of a usable Increment each Sprint, whatever their specialty. The 2020 Scrum Guide replaced the earlier term Development Team so there is one Scrum Team with three accountabilities. Developers are accountable for creating the Sprint plan, instilling quality by adhering to the Definition of Done, adapting their plan daily, and holding each other accountable as professionals.; Related:Scrum Team Product Owner Scrum Master Sprint Backlog
DevOps: DevOps is a set of cultural practices and tooling that brings software development and IT operations together so teams can deliver and run software quickly and reliably. It emphasizes shared ownership, automation, fast feedback, and learning from production. The research program now known as DORA has studied which capabilities predict strong delivery performance.; Related:DORA metrics Continuous delivery Continuous integration (CI)Flow
DORA metrics: DORA metrics are measures of software delivery performance from the DevOps Research and Assessment program. Many people know the original four keys, but DORA now describes five metrics: change lead time, deployment frequency, and failed deployment recovery time for throughput, plus change fail rate and deployment rework rate for instability. DORA's research holds that speed and stability are not tradeoffs, so teams should improve both together.; Related:DevOps Continuous delivery Lead time Throughput
Empiricism: Empiricism is the idea that knowledge comes from experience and that decisions should be based on what is observed. The Scrum Guide says Scrum is founded on empiricism and lean thinking, supported by three pillars: transparency, inspection, and adaptation. In practice, it means making work visible, checking it often, and changing course when the evidence says to.; Related:Scrum Lean Sprint Review Sprint Retrospective
Epic: An epic is a large body of work that is too big to complete in one Sprint and is broken down into smaller items such as user stories. Epics help teams and stakeholders discuss a significant capability without detailing every part up front. The term is a common convention in backlog tools rather than part of the Scrum Guide.; Related:User story Product Backlog Backlog refinement Product Goal
Extreme Programming (XP): Extreme Programming is an agile approach created by Kent Beck in the late 1990s that focuses on technical excellence and close collaboration. Its practices include test-driven development, pair programming, continuous integration, refactoring, small releases, and simple design. Many engineering habits that agile teams now consider standard trace back to XP.; Related:Test-driven development (TDD)Pair programming Refactoring Continuous integration (CI)
Flow: In Kanban, flow is the movement of potential value through a system, from the moment work starts until it is finished. Teams optimize flow by limiting work in progress, reducing waiting, and removing bottlenecks. Smooth flow makes delivery faster and more predictable, which is often more valuable than keeping everyone busy.; Related:Kanban WIP limit Throughput Cycle time
Increment: An Increment is a concrete stepping stone toward the Product Goal that is usable and meets the Definition of Done. Each Increment is additive to all prior Increments, and more than one may be created within a Sprint. Because Increments are real, working results, they give stakeholders something tangible to inspect and give the team genuine feedback.; Related:Definition of Done Product Goal Sprint Review Minimum viable product (MVP)
Kanban: Kanban is a strategy for optimizing the flow of value through a process, often visualized on a board with columns for each stage of work. The Kanban Guide describes three practices: defining and visualizing the workflow, actively managing the items in it, and improving it. Teams use Kanban on its own or alongside Scrum to make work visible and limit how much is in progress.; Related:Flow WIP limit Cycle time Throughput
Large-Scale Scrum (LeSS): Large-Scale Scrum is a framework developed by Craig Larman and Bas Vodde for applying Scrum with many teams working on a single product. It keeps one Product Owner and one Product Backlog for the whole product and encourages simplifying the organization rather than adding layers. LeSS is often chosen by organizations that want to scale while staying close to Scrum's original principles.; Related:Scrum Scaled Agile Framework (SAFe)Product Owner Product Backlog
Lead time: Lead time generally measures the time from when work is requested to when it is delivered, which makes it longer than cycle time because it includes waiting before work starts. DORA uses a related measure, change lead time, which runs from code being committed to that change running in production. Always state where the clock starts and stops, because teams define lead time differently.; Related:Cycle time DORA metrics Throughput Flow
Lean: Lean is a way of thinking that grew out of the Toyota Production System and focuses on delivering customer value while eliminating waste. In software, waste includes partially done work, handoffs, delays, and building features nobody needs. The Scrum Guide notes that Scrum is founded on empiricism and lean thinking, and Kanban draws heavily on lean ideas as well.; Related:Kanban Flow Empiricism Minimum viable product (MVP)
Minimum viable product (MVP): A minimum viable product is the smallest version of a product that lets a team test a key assumption with real users and learn from the results. The term was popularized by the Lean Startup movement. An MVP is about validated learning, not about shipping something low in quality, so it should still be usable for the audience it targets.; Related:Increment Lean Product Goal User story
Mob programming (ensemble programming): Mob programming, also called ensemble programming or software teaming, is a practice in which the whole team works on the same task, at the same time, on one shared computer or screen. One person types while the others guide, and roles rotate frequently. It spreads knowledge quickly, reduces handoffs, and helps teams tackle complex problems together.; Related:Pair programming Code review Cross-functional team Extreme Programming (XP)
Pair programming: Pair programming is a practice in which two developers work together on the same code, with one typically writing and the other reviewing and thinking ahead, switching roles often. It builds shared understanding, catches defects as they are written, and helps new team members learn quickly. It is one of the core practices of Extreme Programming.; Related:Mob programming (ensemble programming)Extreme Programming (XP)Code review Test-driven development (TDD)
Product Backlog: The Product Backlog is an emergent, ordered list of what is needed to improve the product, and it is the single source of work undertaken by the Scrum Team. Its commitment is the Product Goal. The Product Owner is accountable for effective Product Backlog management, though others may help with the work of refining it.; Related:Product Goal Product Owner Backlog refinement Sprint Backlog
Product Goal: The Product Goal describes a future state of the product that serves as a target for the Scrum Team to plan against. Introduced in the 2020 Scrum Guide, it is the commitment for the Product Backlog. The team should fulfill or abandon one Product Goal before taking on the next, which keeps long-term work focused.; Related:Product Backlog Sprint Goal Product Owner Increment
Product Owner: The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team, including effective Product Backlog management. That covers developing and communicating the Product Goal, creating and ordering backlog items, and making sure the backlog is transparent and understood. The Scrum Guide stresses that the Product Owner is one person, not a committee.; Related:Product Backlog Product Goal Scrum Team Sprint Review
Refactoring: Refactoring is improving the internal structure of existing code without changing its external behavior. It is done in small, safe steps, ideally backed by automated tests that confirm nothing broke. Regular refactoring keeps code easy to change and is one of the main ways teams pay down technical debt.; Related:Technical debt Test-driven development (TDD)Extreme Programming (XP)Code review
Retrospective: A retrospective is any regular meeting in which a team reflects on how it has been working and agrees on improvements to try. It focuses on people, interactions, processes, tools, and quality rather than on blame. In Scrum the formal version is the Sprint Retrospective, but teams using Kanban and other approaches hold retrospectives as well.; Related:Sprint Retrospective Empiricism Agile coach Self-managing team
Scaled Agile Framework (SAFe): The Scaled Agile Framework is a set of roles, events, and practices for coordinating agile work across many teams in large organizations, originally created by Dean Leffingwell. It groups teams into Agile Release Trains that plan and deliver together on a shared, regular cadence. SAFe is widely adopted but also debated, so it helps to understand its trade-offs before choosing it.; Related:Large-Scale Scrum (LeSS)Scrum Lean DevOps
Scrum: Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems. It is defined in the Scrum Guide by Ken Schwaber and Jeff Sutherland, most recently revised in 2020, and consists of the Scrum Team and its accountabilities, five events, three artifacts, and their commitments. Scrum is intentionally incomplete, so teams add complementary practices such as user stories or story points as they see fit.; Related:Scrum Team Sprint Empiricism Scrum values
Scrum Master: The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide and for the Scrum Team's effectiveness. They do this by coaching the team and organization, helping remove impediments, and making sure Scrum events are positive, productive, and kept within the timebox. The Scrum Guide describes Scrum Masters as true leaders who serve the Scrum Team and the larger organization.; Related:Scrum Team Agile coach Product Owner Developers (Scrum)
Scrum Team: A Scrum Team is a small group made up of one Scrum Master, one Product Owner, and Developers, with no sub-teams or hierarchies. The Scrum Guide says it is typically 10 or fewer people and describes three accountabilities within it rather than job titles. The team is cross-functional and self-managing, and it is responsible for all product-related activities.; Related:Developers (Scrum)Product Owner Scrum Master Self-managing team
Scrum values: The Scrum Guide names five values: commitment, focus, openness, respect, and courage. It explains that successful use of Scrum depends on people becoming more proficient in living these values. When the values are weak, the events and artifacts tend to become empty rituals.; Related:Scrum Scrum Team Empiricism Self-managing team
Self-managing team: A self-managing team decides internally who does what, when, and how. The 2020 Scrum Guide adopted the term self-managing in place of the earlier self-organizing to emphasize that the team, not an outside manager, makes these choices. Self-management works best when the team has a clear goal, the skills it needs, and real authority over its work.; Related:Scrum Team Cross-functional team Developers (Scrum)Scrum Master
Sprint: A Sprint is a fixed-length period of one month or less in which the Scrum Team turns ideas into value, and a new Sprint starts immediately after the previous one ends. Sprint Planning, the Daily Scrums, the Sprint Review, and the Sprint Retrospective all happen within it. The short, consistent rhythm creates regular points to inspect progress and adapt.; Related:Sprint Planning Sprint Goal Timebox Increment
Sprint Backlog: The Sprint Backlog consists of the Sprint Goal, the Product Backlog items selected for the Sprint, and an actionable plan for delivering the Increment. It is a plan by and for the Developers and is updated throughout the Sprint as they learn more. Its commitment is the Sprint Goal, which keeps the team focused even when the details change.; Related:Sprint Goal Developers (Scrum)Sprint Planning Product Backlog
Sprint Goal: The Sprint Goal is the single objective for the Sprint and is the commitment of the Sprint Backlog. It is created during Sprint Planning and gives the Developers flexibility in the exact work needed to achieve it. A clear Sprint Goal helps the team make trade-offs and encourages them to work together rather than on separate initiatives.; Related:Sprint Backlog Sprint Planning Product Goal Daily Scrum
Sprint Planning: Sprint Planning starts the Sprint by laying out the work to be performed. The Scrum Team addresses why the Sprint is valuable, what can be done this Sprint, and how the chosen work will get done, and it creates the Sprint Goal. It is timeboxed to a maximum of eight hours for a one-month Sprint and is usually shorter for shorter Sprints.; Related:Sprint Goal Sprint Backlog Backlog refinement Timebox
Sprint Retrospective: The Sprint Retrospective is the event in which the Scrum Team plans ways to increase quality and effectiveness. The team inspects how the last Sprint went with regard to individuals, interactions, processes, tools, and its Definition of Done, then identifies the most helpful changes. It concludes the Sprint and is timeboxed to a maximum of three hours for a one-month Sprint.; Related:Retrospective Sprint Review Empiricism Scrum Team
Sprint Review: The Sprint Review is the event in which the Scrum Team presents the results of its work to key stakeholders and discusses progress toward the Product Goal. Together they decide what to do next, and the Product Backlog may be adjusted. The Scrum Guide says it should not be limited to a presentation, and it is timeboxed to a maximum of four hours for a one-month Sprint.; Related:Increment Product Goal Product Owner Sprint Retrospective
Story points: Story points are a relative unit some teams use to estimate the size or effort of backlog items compared with one another, rather than in hours. They are a complementary practice and are not mentioned in the Scrum Guide. Points are only meaningful within a single team, so comparing them across teams or using them as a productivity target tends to backfire.; Related:Velocity User story Backlog refinement Burndown chart
Technical debt: Technical debt is the future cost created when a team takes shortcuts or leaves code in a state that is hard to change. Like financial debt, it can be a reasonable trade-off in the short term, but the interest shows up as slower delivery and more defects. Making debt visible and paying it down through refactoring keeps a codebase healthy.; Related:Refactoring Definition of Done Code review Test-driven development (TDD)
Test-driven development (TDD): Test-driven development is a practice in which a developer writes a small failing automated test, writes just enough code to make it pass, and then refactors, repeating in short cycles. It is associated with Kent Beck and Extreme Programming. TDD produces a safety net of tests and tends to lead to simpler, more modular designs.; Related:Refactoring Extreme Programming (XP)Continuous integration (CI)Acceptance criteria
Throughput: Throughput is the number of work items finished per unit of time, such as items completed per week. The Kanban Guide lists it as one of its core flow measures. Because it counts finished items rather than estimates, throughput is a straightforward basis for forecasting how much a team is likely to deliver.; Related:Cycle time Flow WIP limit Velocity
Timebox: A timebox is a fixed maximum amount of time allotted to an activity. In Scrum, every event is timeboxed: the Sprint lasts one month or less, and the Daily Scrum lasts 15 minutes. Timeboxes encourage focus, limit wasted effort, and create a predictable cadence for inspection.; Related:Sprint Daily Scrum Sprint Planning Scrum
Trunk-based development: Trunk-based development is a source-control approach in which developers integrate small changes into a single main branch, the trunk, at least daily, rather than keeping long-lived feature branches. Unfinished features are often hidden behind feature flags. It avoids painful merges and is closely linked to continuous integration and fast delivery.; Related:Continuous integration (CI)Continuous deployment Code review DORA metrics
User story: A user story is a short description of a capability written from the perspective of the person who wants it, often in the form: As a type of user, I want some goal, so that some benefit. It is a placeholder for a conversation rather than a full specification. User stories are a popular complementary practice for Product Backlog items, though the Scrum Guide does not require them.; Related:Acceptance criteria Epic Product Backlog Story points
Velocity: Velocity is the amount of work a team completes in a Sprint, usually measured in story points. Teams use their own recent velocity to help plan how much to take on. It is a planning aid for that team only, and treating it as a performance target or comparing it between teams usually distorts the numbers.; Related:Story points Burndown chart Sprint Planning Throughput
WIP limit: A work in progress limit caps how many items can be in a given stage or in the whole workflow at once. The Kanban Guide requires teams to explicitly control the number of work items between started and finished. Limiting WIP reduces multitasking, exposes bottlenecks, and usually shortens cycle time.; Related:Kanban Flow Cycle time Throughput