Agile Glossary

Falsifiable success criteria for a PBI established and agreed to by the Product Owner and Team that guides Developers in meeting expectations that, if met, would result in acceptance of the PBI by the Product Owner.

Overhaul of all aspects of an organization based on and values and principles of Agility in order to optimize it for a more desirable purpose. Think of it as caterpillar to butterfly.

A mindset of iterative and incremental delivery of value through collaboration and continuous improvement.

An object representing work or value that is designed to maximize transparency of key information, and provides opportunity for inspection and adaptation. Examples in Scrum include Product Backlog, Sprint Backlog, and Product Increment.

An accumulation of uncompleted work or items that needs to be addressed in the future. In Scrum, there are two backlogs: Product Backlog, and Sprint Backlog.

Simple visual chart used to quickly understand the amount of work remaining vs. time remaining in the sprint.

The capability of an organization to be responsive to changing market conditions while continuously delivering value.

High-level goals for the organization that are measurable and intended to have an impact on the business. Typically addressed by high-level items, such as the successful completion of one or more Roadmap-level items.

Card, Conversation, Confirmation. Commonly referred to as key attributes of a User Story - small enough to fit on an index card, simplified to a conversation starter, and articulation of how success can be confirmed.

A systematic approach to helping people adapt to transitions by utilizing effective two-way communication and feedback strategies.

The act of helping someone else define and achieve their own goal through their own actions.

A group of people who voluntarily form a community focused on a topic of interest to learn, share, and advocate together.

A person who possesses deep or specialized knowledge of a technology system and acts as a teacher, steward, or shepherd (not a gatekeeper) in helping others to understand and effectively utilize the system.

A Team that includes people from a single functional area or single type of component system, specializing in their single area of focus which is one of many components that must be brought together to deliver end-to-end value.

Extension of Continuous Delivery in which the code is fully automated through deployment to Production without manual intervention.

Extension of Continuous Integration in which the code is then automatically compiled and released to an environment, but requires manual action for ultimate deployment to Production.

Frequent merging and testing of code to reduce the risk of collisions and defects by using modern tools and test automation.

A Team that includes people from different functional areas, ideally including all functions needed by the team to achieve end-to-end value delivery.

A person or entity that buys the Product.

The amount of time calculated from when work begins until it is done.

A timeboxed event of 15 minutes or less for the Developers of the Scrum Team to resynchronize with each other by inspecting progress toward the Sprint Goal and adapting the Sprint Backlog as necessary, adjusting the upcoming planned work. (aka Daily Standup, Daily Meeting, Daily Huddle)

A Team Member who is fully allocated to one, and only one, Team and is not responsible for any work outside of that Team.

A problem with the product that does not meet the quality standards of the Product.

A formal description of the state of the Increment when it meets the quality measures required for the product. Typically a list of conditions to be met for a given Product.

A formal description of the state a Product Backlog Item must meet in order to be pulled into a Sprint. Typically a list of conditions to be met for a given Product.

A formal description of the state of the Increment when it meets the conditions required when the product is fully available to be used by the customer. Typically a list of conditions to be met for a given Product.

A situation where additional work is needed by an outside party in order to proceed or complete the overall work.

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint. The specific skills needed by the Developers are often broad and will vary with the domain of work.

An approach by which improvement is made through running an experiment, inspecting the outcome based on real data, learning and adapting for the next experiment, and repeat.

A large User Story, typically too large to be completed in a single Sprint. From the concept of a large book vs. a short story.

A guess.

Actions taken by a neutral party to enable a person or group to more easily achieve their goal.

A cohesive set of functions that together provide value to a user.

A Team that includes people with all the knowledge and skills to deliver a feature end-to-end to a customer.

A series of numbers in which each number is the sum of the previous two, starting with 0 and 1. (0,1,1,2,3,5,8,13,21, etc).

An educated guess at what might happen in the future based on past data. Commonly used for weather, stock market, and product delivery.

A functional piece of a Product that is Done (based on the Product's Definition of Done), but might not yet be the fully envisioned product or feature. (aka Product Increment)

Delivering piece by piece by breaking the work into smaller functional pieces.

Delivering multiple times by repeatedly and continuously improving and refining the product over time.

A process by which problems, ideas, work items, or requests are collected and evaluated by a decision-maker.

An acronym used to evaluate if a User Story is valid: Independent, Negotiable, Valuable, Estimable, Small, and Testable.

A consistently repeated timebox in which work is executed Synonym for a Sprint

A lean-based process framework used to visualize and manage work by utilizing Work-in-Progress limits to create a smooth pull-based flow of work across the system that allows for the identification of bottlenecks and delays in the system.

A visual board used to make work items transparent and measurable with defined columns representing process steps, and managed by Work-in-Progress (WiP) Limits.

A set of quantifiable measurements used to gauge the most important and impactful aspects that will lead to success, improvement, or help to identify critical problems.

The amount of time calculated from when a request is made until it is done.

The minimum functionality that a Product Owner is willing to promote publicly that won't embarrass them.

The most basic version of a Product with the minimal amount of functionality that can be delivered to a willing end user that can be used to test an initial hypothesis.

An extension of Pair Programming in which the entire Team, not just 2 people, work together on an item but still only one person is actively typing on the keyboard.

A meeting facilitation technique where a group of people dynamically create topics and an agenda, typically based on a theme, that allows the people present to address the questions and topics that are of interest to them at that moment.

An overarching long-term goal for which the organization should be designed in order to achieve the most optimal business results.

A systematic approach to helping people adapt to transitions in the organization by utilizing effective two-way communication and feedback strategies.

Two people collaborate, while only one person is using the keyboard, to solve a problem together.

A representation of a person who is a potential user, stakeholder, or influencer where certain impactful attributes are articulated to achieve a shared understanding of the person for the purposes of building a Product to meet their needs.

An estimation technique where each person secretly decides on their estimate on a PBI, using numbered cards that only they can see. Then all people reveal their cards simultaneously and if there is no consensus, they discuss the differences of opinion. Replay until consensus is reached.

The act of managing high-level goals, prioritization, investment decisions, personnel allocations, etc. across multiple Products.

The act of evaluating items in a list and stack-rank ordering the items based on some criteria (typically by business value).

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, and well-defined users or customers. A product could be a service, a physical product, or something more abstract.

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Any item in the Product Backlog. Typically in the form of a defect, user story, research task, technical debt, etc.

The act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size.

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.

Typically a job title for a person who manages a product.

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. The Product Owner is one person, not a committee.

A high-level view of the projected evolution of the Product over time, typically including Product Goals, major Features, Customer Problems to be addressed, supporting needs, and other aspects as determined by the Product Owner.

Referring to PBIs, a PBI that meets the Definition of Ready and is understood well enough by the Team that they can bring it into Sprint Planning work out the details and commit to it for the Sprint.

A development technique typically utilized in Test Driven Development (TDD) by which the developer cleans up the code to make it clear and understandable to others after they have solved the coding problem.

Estimation of items in comparison to each other, rather that absolute measures such as time estimation.

Deployment of the Increment such that it is usable by the end User.

A high-level view of the projected evolution of the Product over time, typically including Product Goals, major Features, Customer Problems to be addressed, supporting needs, and other aspects as determined by the Product Owner.

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization. The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework. 

A scaling pattern where each Team sends Developer(s) as representatives to meet with Developers from other Teams in a scaled Daily Scrum after their own Daily Scrum to synchronize across the teams to increase awareness and reduce the risk of conflicts, collisions, and redundancy in their work on a day-to-day basis.

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers.

Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal. Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how. The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work. The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.

Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master.

Commitment, Focus, Openness, Respect, and Courage. These values give direction to the Scrum Team with regard to their work, actions, and behavior.

Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

A custom framework resulting from the combination of key aspects of Scrum and Kanban.

A team that internally decides who does what, when, and how to get their work done.

A team that extends self-management to also include what work they decide to work on.

A person or group of people who provide support or services to Teams where there is a common need for the service but either limited availability of the person, or inconsistent need such that it is not feasible or cost-effective for those people to be on each Team that may need them.

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how). The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail so that they can inspect their progress in the Daily Scrum.

The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives. The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog.

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team. Sprint Planning addresses the following topics: Topic One: Why is this Sprint valuable? Topic Two: What can be Done in this Sprint? Topic Three: How will the chosen work get done?

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. The Sprint Retrospective concludes the Sprint.

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations.

The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed. During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint.

A timeboxed event of 1 month or less which acts as a container for all other Scrum events during which all work and meetings occur. A new Sprint starts immediately after the conclusion of the previous Sprint and is consistent in length from Sprint to Sprint.

Any person who is not on the Team, but who cares about the people on the Team or the work the Team is producing. Examples are customers, users, business people outside the team, Managers of people on the team, etc.

A number, typically using a modified Fibonacci sequence, assigned to a PBI based on relative sizing for use in comparing PBIs to each other numerically and can be summed for purposes of Velocity.

Breaking a single User Story into multiple User Stories while maintaining the integrity of the INVEST criteria.

A person with deep knowledge or experience in a topic who is often utilized as a stakeholder, advisor, consultant, reviewer, or collaborator to provide information or feedback to aid Teams in their development efforts.

Working at a pace without undue stress or pressure that can be sustained consistently and indefinitely.

A development technique in which many Team members collaborate together on a single item.

An analogy in which a person has a single skill or knowledge in which they are very deep, and they also have a breadth of additional skills that are not as deep but still valuable to the team. Deep and Broad, like the capital letter "T".

A simple board with a set of columns to track work visually. Typically columns of "To Do", "Doing", and "Done" are used.

A group of people dedicated to a common purpose committed to working together toward a common goal.

An accumulation of suboptimal code or tasks left undone during development, typically to expedite product delivery. These shortcuts create debts, which accumulate interest in the form of an increased effort to remediate the debt in the future. As more suboptimal code and undone tasks accumulate over time it becomes increasingly difficult and costly to maintain and enhance the system over time, eventually bankrupting the Product development process to the point that system maintenance needs overwhelm the ability to build new features. The result is frustrated Teams, unhappy stakeholders, and lost customers.

The amount of work output from a workflow system in a specified amount of time.

The maximum about of time for an activity or event, typically for a Scrum Event. For example, 15-minute timebox for the Daily Scrum.

A Team member who is dedicated to one and only one Team, but for only one Sprint at a time. At the conclusion of a Sprint, the Traveler leaves the Team and determines which Team to join for the next Sprint (typically during Sprint Planning).

A person or entity that uses the Product.

A product management technique of visually building out and managing a product backbone based on user needs, goals, and features in order to elaborate a level of detail usable by a Team as well as understandable by stakeholders using User Stories at the lower levels of detail.

Typically used to articulate a PBI, it tells a concise story about a need from the user's perspective typically in the form of who, what, and why.

A measure of the benefit a user might derive from the functionality delivered.

A backward-looking output measure calculated as the sum of the Story Points of PBIs that met the Definition of Done by a Team in a single sprint in the past. It is not a forward-looking measure, not a goal, not a wish, not a performance management metric, not an individual carrot/stick, or any other thing besides a past measure of Team output.

Breaking PBIs into multiple PBIs while ensuring they will include all layers of the value delivery stack such that the end user can utilize the resulting output.

A limit applied to a column in a Kanban board to improve the flow of work by actively managing the amount of simultaneous activity undertaken by a Team.

A measure of the number of items actively in Progress on a Kanban board, or an individual column on a Kanban board.