Agile describes values and principles. Scrum is a framework with defined accountabilities, events, artifacts, and commitments. That distinction matters when a team names work, writes policies, or interprets delivery reports. A Scrum team plans a Sprint around a Sprint Goal. A Kanban team manages work as a flow and does not need fixed Sprints.
This practical glossary organizes Agile Scrum terms around the decisions teams make. It separates formal framework definitions from common practices and organization specific usage, so a familiar word is not mistaken for a universal rule. Scrum definitions follow the November 2020 Scrum Guide.
Use the glossary as a terminology reference, not as a substitute for the relevant framework guide. Where a term belongs to SAFe, XP, Kanban, or a local workflow, its scope is identified.
What Agile and Scrum terms mean, and how to use this glossary
Agile describes values and principles for developing and delivering products. The Manifesto for Agile Software Development expresses four value preferences, and its 12 principles provide further guidance. Agile does not prescribe one process, board layout, role model, or cadence.
Scrum is a lightweight framework for helping people and teams generate value through adaptive solutions to complex problems. Its official Guide defines accountabilities, events, artifacts, and commitments. Kanban, Extreme Programming, and SAFe have their own concepts and terminology. A term can be formal in one approach and a local convention in another.
- Framework definition: Meaning stated in the relevant guide, such as Scrum’s Sprint Goal.
- Common practice: A technique teams often use but the framework does not require, such as a particular user story sentence format.
- Organization specific usage: A local title, status, field, or policy that belongs in the team’s own documentation.
Before using a term in a policy or report, identify its framework and scope, then decide whether it is a formal rule or a local convention.
Agile foundations: values, principles, and delivery language
- Agile: An approach guided by the Agile Manifesto’s values and principles. Agile is not a single method, certification, board, or checklist.
- Agile Manifesto: The 2001 statement of four value preferences for software development: individuals and interactions, working software, customer collaboration, and responding to change, while recognizing value in the items on the right.
- Agile principles: The 12 principles behind the Manifesto. They include delivering valuable software regularly, welcoming changing requirements, sustaining a healthy pace, building quality in, and reflecting on how to become more effective.
- Agile mindset: Informal shorthand for applying Agile values and principles to decisions. It is not a Scrum artifact or a substitute for explicit working agreements.
- Iteration: A timeboxed development cycle in approaches that use iterations. Duration varies. Scrum calls its fixed length cycle a Sprint, while Kanban does not require fixed iterations.
- Agile transformation: Organizational change in how products and services are developed and delivered. Introducing a team board or training in one framework does not, by itself, establish an organization wide transformation.
Use Sprint when referring to Scrum’s event. Use iteration for a timeboxed cycle where the approach uses one. Do not call a continuous flow Kanban period a Sprint merely because a team reviews work regularly.
Scrum roles, events, and artifacts
The Scrum Guide describes a Scrum Team as cross functional and self managing, typically with 10 or fewer people. It defines three accountabilities within the team: Developers, the Product Owner, and the Scrum Master. It does not set a five person minimum or require three separate full time job titles.
- Developers: The people in the Scrum Team who create any aspect of a usable Increment each Sprint. The accountability includes more than software programmers.
- Product Owner: The person accountable for maximizing product value and for effective Product Backlog management. Product Owner is not automatically synonymous with Product Manager or Project Manager.
- Scrum Master: The person accountable for establishing Scrum as described in the Guide and for the Scrum Team’s effectiveness. This is a facilitative accountability, not a command role.
- Sprint: A fixed length event of one month or less that contains the other Scrum events and produces an Increment. One or two week Sprints are common choices, not universal requirements.
- Sprint Goal: The single objective for the Sprint. It provides focus while giving Developers flexibility in how they organize the work.
- Product Backlog: An ordered, emergent list of what is needed to improve the product. The Product Owner is accountable for managing it effectively.
- Sprint Backlog: The Sprint Goal, the Product Backlog items selected for the Sprint, and the Developers’ actionable plan for delivering the Increment. Developers adapt the plan as they learn. Changes must not endanger the Sprint Goal or reduce quality.
- Increment: A concrete stepping stone toward the Product Goal. It must meet the Definition of Done and be usable. A Sprint Review presentation by itself is not an Increment.
- Backlog refinement: Ongoing work to break down and further define Product Backlog items, including adding detail, ordering, and sizing. It is not one of Scrum’s five formal events.
The five formal Scrum events are the Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. Their purposes form one operating cycle:
Backlog items, acceptance, and work breakdown
Scrum requires Product Backlog items but does not require a particular writing format or hierarchy of epic, story, and task. These terms can help teams organize work, but their precise meanings should be documented locally.
- Work item: A general label for a unit of tracked work, such as a feature, defect, Product Backlog item, or task.
- Epic: Common shorthand for a large body of work that may be divided into smaller items. It is not a Scrum artifact.
- User story: A common way to describe a user need and its benefit. An optional format is, “As a [user], I want [capability], so that [benefit].” Scrum does not require this pattern.
- Task: A smaller piece of work used to organize execution. It is not automatically a Product Backlog item or a user story.
- Acceptance criteria: Item specific conditions that help clarify what a particular requirement or Product Backlog item should do. Their format and owner depend on team practice.
- Acceptance testing: Checking specified behavior or conditions for an item. It is not a separate universal Scrum event, and there is no single required owner or sequence.
- Definition of Done: The shared description of quality measures an Increment must meet to be considered complete. In Scrum, it applies to the Increment, not only to one story.
Acceptance criteria describe conditions for a particular item. The Definition of Done describes the shared quality standard for the Increment. Check item behavior against its criteria, then assess Increment quality against the Definition of Done.
A compact work item record can keep those decisions distinct. This is a hypothetical editorial example, not a Scrum mandated schema:
{
"id": "PAY-42",
"type": "user_story",
"description": "As a customer, I want to download a receipt.",
"acceptance_criteria": [
"A successful payment has a downloadable receipt.",
"The receipt shows the payment date and total."
],
"status": "in_review",
"definition_of_done": "The team quality policy applies to the Increment, not this item alone."
}When configuring a work tracking system, agree on item types, status meanings, and who resolves unclear acceptance conditions before creating reports. Keep the definitions in the team’s source of truth and use the same terms in forms and dashboards. ConsultEvo’s ClickUp setup and automation service is relevant when those definitions need to be translated into a work tracking environment, but the service page is not evidence for Scrum rules.
Kanban, workflow, and flow measures
- Kanban: A method for managing work through a defined workflow. The Official Kanban Guide describes practices including visualizing work, making policies explicit, managing flow, using feedback loops, and limiting Work in Progress.
- Kanban board: A visualization of the team’s actual workflow. Columns represent states the work passes through. Kanban does not mandate a three column To Do, In Progress, Done layout.
- Work in Progress: Work that has started but is not finished under the team’s defined workflow. Agree what counts as active work before measuring or limiting it.
- WIP limit: A policy that constrains how much work is allowed in a defined part of the system. It can expose a capacity issue and is not merely a decorative number on a board.
- Bottleneck: A constrained workflow step that limits the rate or smoothness of work moving through the system. Look for persistent queues or stalled work before changing the process.
- Impediment: An obstacle that hinders the team’s progress. A bottleneck describes a flow constraint, while an impediment can be a specific blocked decision or dependency.
- Task board: A broad term for a visual display of work. It is not a distinct framework and does not specify the workflow or policies shown.
Map the states work actually passes through, agree what qualifies for each state, and observe where work waits. Set a WIP limit only after the team understands the workflow and the work counted in each part of it. Kanban does not require fixed iterations.
Estimation, charts, and delivery engineering
- Story points: A team local approach to relative estimation, often considering effort, complexity, and uncertainty. There is no universal conversion from points to hours.
- Velocity: The amount of work a particular team completes in an iteration or Sprint, measured using that team’s own convention. It can support planning in that context, but it is not a standardized productivity score or a sound basis for ranking teams.
- Burndown chart: A chart showing remaining work over time for a defined scope. It does not, by itself, explain why work remains or whether the scope changed.
- Burnup chart: A chart showing completed work against total scope over time. Showing both makes scope changes more visible than a remaining work line alone.
- Continuous Integration: Frequently integrating code changes into a shared codebase, with each integration verified by an automated build and tests. Martin Fowler’s explanation of Continuous Integration distinguishes it from related delivery practices.
- Continuous Delivery: Keeping software in a releasable state through the delivery process. Release to production can remain a separate business or operational decision.
- Continuous Deployment: Automatically releasing qualifying changes to production. It goes beyond Continuous Delivery and is not implied merely by running CI.
- Refactoring: Improving code’s internal structure without intending to change its externally observable behavior. Tests help detect unintended changes.
For a useful chart or metric, record the team, period, scope, and measurement convention. A velocity record belongs to one team and one Sprint. A burndown is a series of time stamped observations for a defined Sprint and scope. A burnup should retain scope changes rather than hiding them.
Scaling and other Agile approaches
- XP, or Extreme Programming: An Agile software development framework with engineering and collaboration practices. Its short cycles and technical practices do not make it another name for Scrum or establish a universal cycle length. The Agile Alliance XP entry describes weekly cycles.
- SAFe: A framework for applying Agile and Lean ideas across larger organizations. Its terms should be interpreted within the relevant SAFe version and implementation.
- Agile Release Train: SAFe terminology for a long lived team of Agile teams organized to deliver value within a value stream. Team size guidance depends on the version and implementation.
- Program Increment: A SAFe planning construct that coordinates work across an Agile Release Train for a planning horizon. Cadence and structure depend on SAFe guidance and implementation. The available SAFe 5.0 glossary describes a common structure of several Iterations, often four development Iterations followed by an Innovation and Planning Iteration, but this is not a universal Agile timebox.
- Scrum of Scrums: A coordination pattern some organizations use to discuss dependencies across Scrum teams. It is not a formal Scrum event, and there is no universal participant threshold or meeting cadence.
- Scrumban: A hybrid label commonly used for combinations of Scrum practices and Kanban flow practices. It is not one standardized specification.
Commonly confused Agile and Scrum terms
| Terms | Keep this distinction | Practical check |
|---|---|---|
| Agile and Scrum | Agile is values and principles. Scrum is a framework. | Name the method when describing a team rule. |
| Product Backlog and Sprint Backlog | The Product Backlog is ordered product work. The Sprint Backlog adds the Sprint Goal, selected items, and Developers’ plan. | Do not label future product work as Sprint work before planning. |
| Acceptance criteria and Definition of Done | Criteria apply to an item. The Definition of Done applies to the Increment. | Check both at their respective scope. |
| Product Owner and Product Manager | Product Owner is a Scrum accountability. Product Manager is an organization specific title. | Document decision rights instead of assuming titles are synonyms. |
| Iteration and Sprint | A Sprint is Scrum’s fixed length event. Iteration is broader timebox language. | Do not apply either term to continuous flow Kanban by default. |
| CI and Continuous Delivery | CI integrates and verifies changes. Continuous Delivery keeps software releasable. | Check release readiness, not only automated tests. |
| Velocity and productivity | Velocity is a team’s local planning measure, not a universal measure of value or productivity. | Do not compare point totals across teams. |
| Burndown and burnup | Burndown shows remaining work. Burnup shows completed work against total scope. | Prefer burnup when scope change needs to be visible. |
Put consistent terminology into team practice
Before configuring a board or report, agree on the approach and the meaning of every field it will store. A lightweight review can prevent a local label from being mistaken for a framework rule.
- Identify the approach. State whether the policy concerns Scrum, Kanban, SAFe, XP, or a local combination.
- Define the term and scope. Say whether it describes an accountability, event, product item, workflow state, or metric.
- Name the decision owner. Use the Scrum Guide for Scrum accountabilities. For local statuses and acceptance practices, record who makes or confirms the decision.
- Set the source and version. Link formal definitions to the relevant guide and version, and keep local definitions with the team’s working agreements.
- Validate reports against the definition. Confirm that the data grain matches the metric. Velocity is one team per Sprint, while burndown observations are time stamped observations within a defined Sprint and scope.
- Every controlled field has a documented meaning, allowed value, and owner.
- Every metric states its team, period, scope, and measurement convention.
- Time series use an observation timestamp and scope version rather than overwriting prior states.
- Concurrent metric or status writes use a database enforced unique key or transactional upsert where appropriate, not lookup before create as the only deduplication safeguard.
- Ambiguous acceptance conditions, disputed ordering, and Sprint Goal changes have a named human review path.
For example, an illustrative data model might use team_id + sprint_id + metric_name as a uniqueness key for one velocity summary per team and Sprint. Burndown snapshots would need a key such as sprint_id + observed_at + scope_version. Status history would require one record per transition, not one mutable row per work item. These are editorial design recommendations, not fields mandated by Scrum or Kanban.
Prefer simple allowed value lists for framework, status, and work item type. Use human review when criteria are ambiguous, a Sprint Goal is threatened, or teams disagree about scope. Do not calculate cross team productivity from velocity or combine measurements with different scopes because they share a label.
References and version notes
The Agile Manifesto and its principles are primary sources for Agile values and principles. Scrum definitions above follow the November 2020 Scrum Guide. Kanban practices follow the Official Kanban Guide. The SAFe glossary cited is specifically for SAFe 5.0. These sources define terms in their own contexts, so use the relevant guide when making a framework decision.
Historical adoption figures are intentionally not used as current benchmarks. The 2018 Stack Overflow survey reported Agile and Scrum usage among its survey respondents, but those results describe that population and year rather than worldwide current adoption.