Agile has grown steadily since its formal inception in 2001. For more than two decades, this iterative approach to project management and software development has been helping teams deliver value to customers faster and with fewer bumps along the way.
Consequently, Agile can boast a rich history alongside a huge body of knowledge standing at the intersections of design thinking, product management, and DevOps. These, in turn, have spawned dozens of Agile and domain-specific terms that may be confusing (maybe even overwhelming). For that reason, we’ve created this Agile glossary to help you navigate the vast oceans of Agile with confidence.
AC (Acceptance Criteria)
Acceptance criteria is a set of predefined requirements (criteria) a user story must meet — taking into account all possible scenarios — to be considered complete. Only when the story satisfies those criteria can the Product Owner, end users, and other stakeholders mark the story as “acceptable” or complete. Acceptance Criteria focus on functional aspects of a single item of work (rarely on non-functional ones). They apply at the Epic, Feature, and Story (or Task) levels.
Acceptance Testing
Acceptance Testing, or User Acceptance Testing (UAT), is one of the quality assurance (QA) processes. The goal of the AC is to determine if — and to what degree — the end product meets the Acceptance Criteria with respect to users’ needs, requirements, and business processes. Acceptance Tests ensure the product solves the business problem from the end user’s point of view.
Agile Board
An Agile board represents an Agile development process in a visual way. Development teams can use it to see the current status of each task; group tasks; estimate efforts for each task; and track task progress. The columns on the board represent task development progress throughout the development cycle. Typically, those columns are “To Do,” “In Progress,” and “Done” but it can have more to accommodate the project’s needs.
Agile Transformation
Agile Transformation is the process of adopting an Agile approach by the organization across all departments, processes, and structures. The process of transformation is a significant (but slow) paradigm shift that can take years. It involves a radical change in attitudes, values, mindsets, and ways of thinking to entirely introduce change in organizational culture.
Antipattern
An antipattern in Agile is a common practice, process, or structure for a certain course of action or solution that aims to remedy a situation. But eventually, the practice proves ineffective, counterproductive and produces undesired consequences. Following an antipattern creates more problems than it solves.
Backlog
In Agile, a backlog is a prioritized list of work items (tasks) the completion of which is crucial for supporting a strategy. The most important tasks sit at the top of the backlog. This way, the development team, and Product Owner know what they should deliver first and what comes next. Typical items on a backlog include user stories, changes to existing functionality, and bug fixes. Also, depending on the backlog role, you can have a Sprint Backlog, Product Backlog, and Release Backlog.
Backlog Refinement
A Backlog Refinement is a collaborative event during which the team estimates the amount of effort they’d need to complete work items in the backlog. The team also comes up with other technical information to help the Product Owner prioritize the work. The intent of Backlog Refinement is to ensure that the list contains relevant, detailed, and estimated work items with respect to their priority. It also helps teams to understand the objectives of the project or product. (Former name: Backlog Grooming)
Build
Software build is a process of converting source code files to a standalone form so users can run software on their devices to interact with it. One of the most important steps of a software build is the compilation process, where source code files are converted into executable code. Other typical steps include file compression, updating database schema, creating an installer or executable file, etc.
Build Automation
Build automation is the process of automating the creation of a software build within a CI/CD pipeline. Specifically, it automates the retrieval of source code, compiling it into binary code, executing automated tests, and publishing it into a shared, centralized repository. Build automation is one of the critical DevOps processes.
Burndown Chart
A burndown chart is a graphical representation of the amount of work left to do in an epic or Sprint versus time. The outstanding work (or backlog) is typically shown along the vertical (X) axis and the time along the horizontal (Y) axis. Burndown charts help you predict how likely a team is to complete its work in the time available. They also enable managers and teams to identify issues before they become a problem (for example, scope creep).
Burnup Chart
A burnup chart is a graphical representation of the amount of work that has already been completed in an epic or Sprint. The completed work is typically shown along the vertical (X) axis and the time along the horizontal (Y) axis. Burnup charts help motivate teams by showing progress toward the end goal.
Business Agility
Business Agility refers to how quickly an organization is able to adapt to uncertain situations or changing environments (e.g., new technologies, customer behavior). Agile organizations are able to turn challenges into opportunities and find solutions to changing market requirements. Common examples of Business Agility methodologies are Scrum, DevOps, Business Intelligence (BI), and Kanban.
Cadence
Cadence refers to the number of days or weeks a Sprint, iteration, or release lasts. It’s a consistent sequence (rhythm) of events and activities that take place on a regular, predictable schedule. Therefore, your team forms a cadence when it carries on with its successive iterations and keeps a consistent iteration duration. In flow-based Agile methodologies like Kanban, cadence is the continuous flow (or the overall project length).
Collective Code Ownership
Collective code ownership extends the responsibility for producing and maintaining quality code to all programmers. Therefore, no single person claims ownership over any part of the system, and anyone can make any necessary changes anywhere in the code. The change might be completing a development task, fixing a defect, or improving the code’s overall structure.
CD (Continuous Delivery)
Continuous Delivery is a software engineering and DevOps practice in which code changes are automatically prepared for a release to production. Continuous Delivery expands upon Continuous Integration by deploying all code changes to a testing environment and/or a production environment after the build stage. Before an update goes to production, a human needs to manually approve it.
Continuous Deployment
Continuous Deployment goes one step further than Continuous Delivery. With this approach, every change that passes all stages of the production pipeline is released to customers. Continuous Deployment is similar to Continuous Delivery, but releases require no human intervention — they happen automatically. Only a failed test will prevent the deployment of a new change to production.
CI (Continuous Integration)
Continuous Integration is part of both Continuous Delivery and Continuous Deployment. Developers practicing CI integrate (merge) their new code with the code base at least once a day throughout the development cycle. The automated tests are run against each iteration of the build. This approach helps developers identify integration issues earlier (when they’re easier to fix) and avoid problems at the final merge for the release.
Continuous Improvement
The modern concept of Continuous Improvement — based on the Japanese “kaizen” and Deming Circle of Plan, Do, Check, Act — is a process of improving quality and efficiency through small, incremental changes and reducing waste. In Kanban, Continuous Improvement refers to the process of improving the flow of work and reducing the cycle time, resulting in increased productivity.
Cycle Time
A Cycle Time is the duration between when the development team starts to work on a feature and when it goes to end users. It represents the time it takes to deliver a feature from the developer’s point of view.
Daily Meeting
A Daily Meeting is a ~15-minute team meeting that takes place every day at the same time (usually, in the morning) and ideally in front of the task board. The purpose of the Daily Meeting is to bring everyone together, give the team an opportunity to discuss the tasks they’re working on, identify any obstacles preventing progress, and produce an action plan for the next day of work. (Similar names: Daily Stand-up — from Extreme Programming; Daily Scrum — used in Scrum; huddle; roll-call)
DoD (Definition of Done)
The Definition of Done is a sort of a “working agreement” between team members that defines a set of standards for identifying a backlog item as “done.” In other words, a story is “Done” when it doesn’t require any further work. Unlike the Acceptance Criteria, the Definition of Done applies to all the work, not necessarily just a single user story.
DoR (Definition of Ready)
A Definition of Ready is a set of agreements (conditions) that every user story in the backlog must satisfy to be even considered during Sprint Planning. And then, added to a Sprint (moved from the backlog to development). A Ready story is a detailed narrative user story team can describe according to the INVEST principle.
DEEP (Detailed, Estimated, Emergent, Prioritized)
DEEP is a set of 4 attributes that help define a high-functioning backlog:
- Detailed appropriately (backlog items should contain enough contextual information for the team to understand and discuss them)
- Estimated (lower-priority items will have less precise estimates than items at the top of the backlog, but all should have at least a rough estimate)
- Emergent (backlog evolves, so new items will be added or removed)
- Prioritized (items are ranked based on their value, and the higher-value items sit at the top of the backlog)
Development Team
A development team is a cross-functional and self-organized group of people who work together to build software or service. Cross-functional means that Agile development teams consist of professionals with the necessary skills to turn requirements into a production-ready product. The team’s self-organization is based on the premise that no single person is in charge. Therefore, the whole Agile team needs to remain invested in their shared goals.
DevOps (Development and Operations)
DevOps merges development and operations teams into one that works across the entire application lifecycle. Coming from an Agile approach, DevOps practices enable software development (dev) and operations (ops) teams to accelerate delivery through automation, collaboration, fast feedback, and iterative improvement.
Epic
An epic is one of many issue types in Jira. It represents a large user story you can break down into several smaller stories (or issues). An epic can be large enough to span multiple projects and teams. It can also take multiple Sprints to complete. Because of the epic’s size and duration, the scope and the subsequent stories may change over time to accommodate customer feedback and lessons learned over the course of development.
Estimation
During the Agile estimation process, the development team estimates the effort required for the completion of a prioritized task in the product backlog. Everyone on the development team estimates each task individually using hours or — more commonly — story points. Estimates help break down, plan, and prioritize the upcoming work and, ultimately, plan Sprints more accurately.
Facilitation
Agile facilitation is the art of managing groups and providing the fundamentals to enable and strengthen collaborative work. Facilitators use facilitation techniques and team coaching strategies to ensure the goals of a meeting are met. They also help identify and remove blockers that prevent teams from meeting their objectives.
GWT (Given-When-Then)
Given-When-Then is a template (or formula) for writing acceptance tests that specify a system’s behavior. The essential idea is to break down a test scenario into three sections:
- Given — pre-condition that describes the context for the scenario
- When — describes the action/behavior in relation to the context
- Then — a post-condition that specifies the expected observable behavior
Information Radiator
An information radiator is a big visual chart displayed in such a place that everyone on the development team (and even passersby from outside the team) can easily see it. The chart shows key information in an easily digestible format. It can visualize the workflow and progress, indicate the blockers, and show what the team is working on at any time. One of the typical examples of an information radiator is a Kanban board.
INVEST
Development teams can use INVEST as a guide to creating quality user stories. If the story does not meet one or more of the INVEST criteria, teams may consider rewording or rewriting it. According to the INVEST principle, a good user story:
- Independent = is self-contained.
- Negotiable = leaves room for discussion.
- Valuable = delivers value to stakeholders.
- Estimable = enables fairly accurate approximation.
- Small = fits one iteration or Sprint.
- Testable = descriptive enough to make testing possible.
Iteration
An Agile iteration is a short period of time during which a development team produces, tests, and delivers some portion of work (Product Increment). Each iteration has specific start and completion dates by which the team is expected to complete the deliverables they have planned. In Scrum, specifically, an iteration is called Sprint.
Kanban
Kanban is a workflow management method used for managing and improving work. It helps balance demands with available capacity and address bottlenecks. In Kanban, the work flows continuously instead of being divided into individual timeboxes (as opposed to iterations/Sprints). The flow of the work is represented on a (Kanban) board. This visual approach enables organizations to optimize work delivery across multiple teams and handle complex projects.
Kanban Board
A Kanban board is a project management tool designed for work visualization. It’s similar to Agile and Scrum boards (but not the same). The main difference is the continuous nature of Kanban methodology itself — Kanban boards visualize an ongoing process throughout the lifecycle of a project, so there are no start and end dates. For that reason, the tasks on the Kanban board don’t have strict deadlines either.
Lead Time
Lead Time refers to the duration from the date of task creation to the date of completion. As such, Lead Time is a measurement from the user’s point of view: Users are more concerned with how long it takes for a feature to go from “requested” to “complete.” In other words, it’s the total time the client is waiting for a feature delivery.
Milestone Retrospective
Project Milestone Retrospective takes place after a set period of time or when the project is about to finish. All the team’s permanent members (not just developers) hold a ~1- to 3-day meeting to run a detailed analysis of significant project events. This meeting is facilitated and has more structure than an iteration or Sprint Retrospective.
MMF (Minimum Marketable Feature)
A Minimum Marketable Feature is a feature that provides significant value to the user. At the same time, it’s small enough to allow teams to deliver it in a very short time. Delivering the MMF is not a popular practice. But it aligns well with the first principle of the Agile Manifesto because both the first Agile principle and MMF talk about early and continuous value delivery to the customer. MMF is part of the Minimum Marketable Product.
MMP (Minimum Marketable Product)
A Minimum Marketable Product is a product that teams can develop with the least effort and that would generate revenue for the business. MMP allows organizations to focus on releasing a product with a limited number of features so they can start earning money faster.
MVE (Minimum Viable Experiment)
A Minimum Viable Experience refers to how end users feel when they interact with a Minimum Viable Product. The goal of MVE is to encourage users to re-engage with the product and become its advocates. The MVE is not concerned with what users do or manage to achieve when using a product, but with how it makes them feel.
MVP (Minimum Viable Product)
A Minimum Viable Product (MVP) is a product in the early stages of development. It has a basic (minimal) but sufficient set of features to go to market and gain interest and feedback from its first users.
Niko-Niko Calendar
A Niko-Niko calendar, or a mood board, is a visual tool that enables tracking of the mood of an Agile team. The calendar layout consists of rows and columns that store each team member’s name and the expression of their emotions on a given day. At the end of the working day, each team member summarizes their mood on that day with an emoticon or a color-coded mood marble. Niko-Niko calendar is one of the Information Radiators.
Persona
Agile personas are fictional customers (product/service end users) who have all the ideal core characteristics typical of your target audience. These characteristics may include demographic traits like geographical location, age, and job title, as well as psychographic traits such as behavior, needs, and pain points. Fictional but reality-based personas help Agile teams understand the purpose of the product they’re building.
Planning Poker®
Planning Poker® is an Agile estimating technique based on common consensus among team members. To “play” Planning Poker® means to estimate individual product backlog items for the upcoming Sprint (or even for a few Sprints ahead). Agile teams express their estimations with the help of story points, ideal days, or any other estimation units. Remote teams can use the Planning Poker app for their estimation meetings.
PBI (Product Backlog Item)
In Agile development, a Product Backlog Item (PBI) is a single element representing a piece of work that exists in the Product Backlog. That piece of work must be small enough to allow developers to complete it in a Sprint. PBIs can include bugs, change requirements, epics, specifications, or user stories. The Product Owner is responsible for compiling and prioritizing the PBIs.
Product Increment
In Scrum, Product Increment is the sum of everything the development team has built in the most recent and all previous Sprints. At the end of a Sprint, only the backlog items that meet the Definition of Done (items with the status “Done”) count toward the Increment. The Increment(s) delivered in the last Sprint require verification to ensure they work well together with the previous Increments.
PM (Product Manager)
The Product Manager is a product specialist who oversees all processes related to building and selling a product or service. Those processes include the identification of customer needs, creating the product, and taking it to market. For that reason, PMs must liaise between multiple departments and teams to gather all the necessary information and develop successful strategies.
PO (Product Owner)
The Product Owner is a member of the Scrum team who’s responsible for the development of the product. The PO interacts with customers, users, the development team, and other key stakeholders in the organization. Their role is to maximize the value of the product resulting from the work of the Scrum Team and provide clarity to the team about a product’s vision and goals.
Refactoring
Refactoring is a systematic process of improving the internal structure of code. The goal is to clean up the mess in a code without introducing any new functionalities into it.
Relative Estimation
Relative estimation is one of the estimations approaches Agile team members can use to determine how much effort they would need to complete individual tasks. They carry out their estimations by comparing one task or user story with similar ones they’ve completed in a previous Sprint or iteration.
Release Plan
An Agile Release Plan is a project management tool in the form of a document. It captures and tracks the goals and direction for an upcoming release. A Release Plan is short-term and typically serves as an internal working document for product and development teams.
Scrum Master
The Scrum Master is a guide and facilitator for a Scrum development team. They’re also accountable for establishing Scrum and ensuring it’s followed by helping others understand Scrum theory and practice on the team and organization levels.
Sprint Goal
A Sprint Goal is a specific, measurable, and shared goal/objective representing the expected outcome of a Sprint. The Goal comes in the form of a short, one- or two-sentence description explaining what the team plans to achieve during the Sprint. The goal itself is the result of negotiations between the development team and the Product Owner.
Sprint Planning
Sprint Planning is a collaborative Scrum event that initiates Sprint. The purpose is to define what the development team can deliver in the upcoming Sprint (and how they can achieve it). It is a collaborative event that involves the entire Scrum team, including PO and Scrum Master. The planning is divided into three parts (The What, The How, and The Who) and results in two tangible products: Sprint Backlog and Sprint Goal.
Sprint Retrospective
A Sprint Retrospective is a meeting that concludes the Sprint. It’s held after a Sprint review and before the next Sprint starts. The Sprint Retrospective gives team members an opportunity to reflect on their interactions, processes, tools, and the Definition of Done. It is also a good time for teams to think about applying past insights to the upcoming Sprint.
Sprint Review
The Sprint Review is the second to last event of the Sprint and takes place before Sprint Retrospective. During this event, the Scrum Team and key stakeholders invited by the PO inspect the outcome of the Sprint, collect feedback from all stakeholders, and adjust the backlog to meet new opportunities.
Story Mapping
Story mapping (or user story mapping) outlines the user’s journey through the product by building a simple model that visualizes that journey. The mapping process involves arranging user stories along two independent dimensions. The user activities go along the horizontal (Y) axis, roughly in the order in which the user would perform the task. The vertical axis (X) shows user stories increasing by priority and/or the implementation complexity level.
SP (Story Points)
Story points are units of measure the Agile team can use to express an estimate of the overall effort they would require to fully implement a PBI or any other piece of work. Teams assign story points relative to the amount of work, work complexity, and the potential risk that goes with the product backlog item.
Story Splitting
Story splitting means breaking up one user story into smaller stories. The individual smaller stories created from the larger one are complete user stories, with each offering a measurable business value.
Technical Debt
Technical debt is the difference between what a certain solution promised to deliver and the actual outcome. In other words, it’s the consequence of taking delivery shortcuts (e.g., hastily coded features) instead of a more time-intensive approach that would result in better quality.
Three C’s (Card, Conversation, Confirmation)
The Three C’s (Card, Conversation, Confirmation) formula captures the components of a user story:
- Card is a place for one user story that helps keep the user stories concise and makes the story less abstract.
- Conversation stands for a dialogue between developers, Product Owners, the Scrum Master, and stakeholders that fosters collaboration and gaining a shared understanding of the story requirement.
- Confirmation of the user story comes in the form of acceptance tests that capture the essential requirements.
Three Amigos
Three Amigos represents the three primary perspectives to examine an increment of work before, during, and after development:
- Business perspective — a Business Analyst or Product Owner ensures everyone understands the problem they present through the user stories.
- Development perspective — a Developer discusses and assesses product features that support the user stories.
- Testing (quality) perspective — a software tester helps by finding edge cases and missing scenarios in the stories.
Timebox
A timebox determines when a team must complete an iteration or Sprint and deliver the Sprint goal. It may also stand for a time limit allocated for a single task or activity. For example, a Scrum event or a meeting with stakeholders.
User Story
A user story is a general description of a change in system behavior from the perspective of a user. A story tells what a user wants to do with the digital product, or what they would like the product to be able to do for them in the future. User stories typically follow the “As a (role), I want (function), so that (reason/ business value).”
Velocity
Velocity in Agile is a metric that calculates the time it took team members to complete user stories within a particular Sprint against their estimate. The timeframe can be measured in iterations, Sprints, or weeks, while the completion of user stories in hours, man-days, or story points.
Those are your Agile terms from A to Z (okay, from A to V, because there aren’t any W, X, Y, or Z ones yet). Looking for an Agile solution? Just look under “A” for “Appfire.”
