Glossary

Overview

Entries in this glossary are arranged alphabetically. An entry may be a single word, such as Scrum, a phrase, such as acceptance criteria, or an acronym, such as TDD. If a term has more than one definition, the definitions are numbered.

The following cross-references are used to show a term’s relationship to other terms in the glossary:

• See refers to a preferred term or to a term whose definition serves to define the term in question.

• See also refers to a related term.

• Synonymous with refers to a synonym or term with a nearly identical meaning.

• Contrast with refers to a term with a substantially different meaning.

Definitions

A

acceptance criteria. 1. The external quality characteristics specified by the product owner from a business or stakeholder perspective. Acceptance criteria define desired behavior and are used to determine whether a product backlog item has been successfully developed. 2. The exit criteria that a component or a system must satisfy in order to be accepted by a user, customer, or other authorized entity (IEEE 610).

acceptance test. 1. The testing carried out to verify that the acceptance criteria have been met. 2. A test that defines the business value each product backlog item must deliver. It may verify functional requirements or nonfunctional requirements such as performance or reliability. It is used to help guide development (Crispin and Gregory 2009). 3. Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers, or other authorized entity to determine whether or not to accept the system (IEEE 610).

acceptance-test-driven development (ATTD). A technique in which the participants collaboratively discuss acceptance criteria, using examples, and then distill them into a set of concrete acceptance tests before development begins. Synonymous with specification by example.

accuracy. How close an estimate is to the actual value—the proximity of the measure to its true value. For example, estimating that the product will ship in October 2015 is accurate if the product ships any day during October 2015. Contrast with precision.

activity. 1. A Scrum practice that involves taking action or performing a process, for example, sprint-planning activity, daily scrum activity, sprint review activity, and sprint retrospective activity. 2. In a general sense, the work performed by the Scrum team members such as writing code, performing tests, creating estimates, and so on. See also practice.

adaptation. One of the three pillars of empirical process control; feedback is used to make an adjustment to the work product being developed or the process by which it is being developed. See also empirical process control, inspection, transparency.

agile. 1. A specific set of values and principles, as expressed in the Agile Manifesto (Beck et al. 2001). 2. An umbrella term used for a group of related approaches to software development based on iterative and incremental development. Scrum is an agile approach to development. See also Extreme Programming, Kanban, Scrum.

all-at-once product development. Doing all types of work (for example, analysis, design, coding, integrating, and testing) opportunistically within a single iteration.

all-before-any. A characteristic of a sequential development process, where the work product from a previous step in a process is transferred to the next step using a batch size of 100%. See also batch size.

anticipatory process. See plan-driven process.

approach. A specific way to realize a practice or activity. For example, Scrum specifies a sprint retrospective. How a team chooses to perform a sprint retrospective is its approach, which may be different from the approaches of other teams. See also activity, practice.

artifact. A tangible by-product produced during product development. The product backlog, sprint backlog, and potentially shippable product increment are examples of Scrum artifacts. See also practice.

assumption. A guess, or belief, that is presumed to be true, real, or certain even though there is no validated learning to know that it is true. Contrast with validated learning.

ATTD. See acceptance-test-driven development.

B

batch size. The cardinality of a set of items to be processed at some future step. See also work in process.

Boy Scout rule. 1. Always leave the campground cleaner than you found it. If you find a mess on the ground, clean it up regardless of who might have made the mess. 2. Every time you are in an area of the code doing work, always leave the code a little cleaner, not a little messier, than you found it. See also technical debt.

burndown chart. A graph that shows on the vertical axis the quantity of work (in either hours or product backlog item units) remaining over time, which is shown on the horizontal axis. Because less and less work should remain over time, the general trend in the graph is to burn down to a point where no work remains. We can show projected outcomes on burndown charts by calculating a trend line to see when work might be completed. Contrast with burnup chart.

burnup chart. A graph that shows the progress of work toward a goal line associated with a value on the vertical axis. As work is completed over time (the horizontal axis), the progress line moves up (burns up) to be nearer to the goal line. We can show projected outcomes on burnup charts by calculating a trend line to see when work might be completed. Contrast with burndown chart.

C

cadence. A regular, predictable rhythm or heartbeat. Sprints of consistent duration establish a cadence for a development effort. See also synchronization.

capacity. 1. The quantity of resources available to perform useful work. 2. A concept used to help establish a WIP limit by ensuring that we only start work to match the available capacity to complete work. See also work in process.

ceremony. A ritualistic or symbolic activity that is performed on well-defined occasions. Some people refer to the core Scrum activities of sprint planning, daily scrum, sprint review, and sprint retrospective as ceremonies. See also activity, unnecessary formality.

chaotic domain. 1. A situation that requires a rapid response. We are in a crisis and need to act immediately to prevent further harm and reestablish at least some order. 2. One of the domains in the Cynefin framework. See also Cynefin. Contrast with complex domain, complicated domain, disorder domain, simple domain.

chickens. A metaphor used by some Scrum teams to indicate that people are invested in the goal of the Scrum team, but at a level of involvement (not accountable) rather than commitment. Best used to refer to people outside of the Scrum team. Derived from an old joke about a chicken and a pig: “In a ham-and-eggs breakfast, the chicken is involved, but the pig is committed.” Contrast with pigs.

chief product owner. The overall product owner within a product owner team on a large development effort. See also product owner.

commitment. The act of binding oneself to a course of action. Scrum encourages commitment. Commitment means that during both good times and bad, each team member is dedicated to meeting the team’s collective goal. Contrast with forecast.

complex adaptive system. A system with many entities interacting with each other in various ways, where these interactions are governed by simple, localized rules operating in a context of constant feedback. Examples include the stock market, the brain, ant colonies, and Scrum teams.

complex domain. 1. A situation in which things are more unpredictable than they are predictable. If there is a right answer, we will know it only with hindsight. 2. One of the domains in the Cynefin framework. See also Cynefin. Contrast with chaotic domain, complicated domain, disorder domain, simple domain.

complicated domain. 1. A situation in which there might be multiple right answers but expert diagnosis is required to figure them out. 2. One of the domains in the Cynefin framework. See also Cynefin. Contrast with chaotic domain, complex domain, disorder domain, simple domain.

component team. A team that focuses on the creation of one or more components of a larger product that a customer would purchase. Component teams create assets or components that are then reused by other teams to assemble customer-valuable solutions. Contrast with feature team.

conditions of satisfaction. The conditions under which a product owner would be satisfied that a product backlog item is done. Conditions of satisfaction are acceptance criteria that clarify the desired behavior. See also acceptance criteria.

confidence threshold. 1. The definition of done for envisioning (product-level planning). 2. The set of information that decision makers need in order to have sufficient confidence to make a go/no-go funding decision for more detailed development.

continuous delivery. See continuous deployment.

continuous deployment. Deploying each new feature to users immediately after it is built, integrated, and tested. Synonymous with continuous delivery, integration.

continuous integration. A technical practice where members of a single team or multiple teams integrate their work as frequently as is practical. See also integration, technical practices.

cost of delay. The financial cost associated with delaying work or delaying achievement of a milestone. Cost of delay emphasizes the concept that time has a real financial cost, and to make economically sensible trade-offs it is important to know that cost.

cross-functional team. A team composed of members with all the functional skills (such as UI designers, developers, testers) and specialties necessary to complete work that requires more than a single discipline.

customer uncertainty. Uncertainty surrounding who the customers of a product are. See also uncertainty. Contrast with end uncertainty, means uncertainty.

Cynefin. A sense-making framework that helps us understand the situation in which we have to operate and decide on a situation-appropriate approach (Snowden and Boone 2007).

D

daily scrum. A synchronization, inspection, and adaptive planning activity that a development team performs each day. This core practice in the Scrum framework is timeboxed to no more than 15 minutes. Synonymous with daily stand-up. See also inspect and adapt.

daily stand-up. A common approach to performing a daily scrum whereby the participants stand for the entirety of the activity. Standing up promotes brevity and helps ensure that the activity does not exceed its timebox. See daily scrum.

DEEP. An acronym coined by Roman Pichler and Mike Cohn for remembering a set of criteria used to evaluate the quality of a product backlog. The criteria are Detailed appropriately, Emergent, Estimated, and Prioritized. See also product backlog.

defined process. A process with a well-defined set of steps. Given the same inputs, a defined process should produce the same output every time (within a defined variance range). Contrast with empirical process control.

definition of done. 1. A checklist of the types of work that the team is expected to successfully complete by the end of the sprint, before it can declare its work to be potentially shippable. A bare-minimum definition of done should yield a complete slice of product functionality, one that has been designed, built, integrated, tested, and documented and will deliver validated customer value. 2. Sometimes described as the acceptance criteria that apply to all product backlog items. Contrast with definition of ready.

definition of ready. A checklist of conditions that must be true before a product backlog item is considered ready to pull into a sprint during sprint planning. Contrast with definition of done.

development team. A self-organizing, cross-functional team of people who collectively are responsible for all of the work necessary to produce working, validated assets. One of the three roles that constitute every Scrum team. See also cross-functional team, product owner, ScrumMaster, Scrum team.

disorder domain. A dangerous state where we really don’t understand or can’t make sense of the situation we are in. Our goal is to get out of this domain. 2. One of the domains in the Cynefin framework. See also Cynefin. Contrast with chaotic domain, complex domain, complicated domain, simple domain.

done. See definition of done.

dot voting. A technique that allows participants to vote their preferences among a set of items by placing a colored dot on items that they believe are higher priority than other items. Items with more dots are higher priority than items with fewer dots. This technique is frequently used during the sprint retrospective activity. See also sprint retrospective.

E

economic filter. The decision criteria used by an organization to evaluate the economics of a proposed product in order to decide whether or not to fund it. Contrast with strategic filter.

emergence. 1. Individual, localized behavior that aggregates into global behavior that is disconnected from its origins. 2. An attribute of complex adaptive systems. 3. When applied to software development, recognizing that it is not possible to a priori determine the correct set of features, designs, or plans. Instead, over time as more information is learned, important information will emerge from the experience gained on prior work. See also complex adaptive system.

emergent opportunity. An opportunity that was previously unknown, or was deemed sufficiently unlikely to occur and therefore not worth spending money on at the time.

emotions seismograph. A graphical representation of the emotional ups and downs of team members over the course of a sprint. A technique frequently used during the sprint retrospective activity. See also sprint retrospective.

empirical process control. A style of work that leverages the principles of inspection, adaptation, and transparency. Contrast with defined process.

end uncertainty. Uncertainty surrounding what will be built (the product). See also uncertainty. Contrast with customer uncertainty, means uncertainty.

envisioning. An activity that captures the essence of a potential product and creates a rough plan for the creation of that product. Envisioning begins with the creation of a vision, followed by the creation of a high-level product backlog and frequently a product roadmap. Synonymous with product planning. See also product roadmap.

epic. A large user story, perhaps a few to many months in size, that can span an entire release or multiple releases. Epics are useful as placeholders for large requirements. Epics are progressively refined into a set of smaller user stories at the appropriate time. See also feature, progressive refinement, theme, user story.

essential Scrum. The values, principles, and practices of the Scrum framework combined with rules and proven approaches to applying Scrum practices. See also approach, practice, rule, Scrum framework.

estimation. A rough calculation of the value, number, quantity, or extent of something. In Scrum, we estimate the size of portfolio backlog items, product backlog items, and sprint backlog tasks. See also forecast.

event timeline. A visual, chronologically ordered depiction of the meaningful events that occurred over a period of time. A common technique used during sprint retrospectives. See also sprint retrospective.

exploitation. Making a decision based on the certainty of the information we currently possess. Contrast with exploration.

exploration. The act of acquiring or buying knowledge by performing some activity such as building a prototype, creating a proof of concept, performing a study, or conducting an experiment. Contrast with exploitation.

external stakeholders. Stakeholders who are typically external to the organization that is developing a product, for example, customers, partners, and regulators. See also stakeholders. Contrast with internal stakeholders.

Extreme Programming (XP). An agile development approach that is complementary to Scrum. Extreme Programming specifies important technical practices that development teams use to manage the flow of task-level work during sprint execution. See also agile.

F

fail fast. A strategy of trying something, getting fast feedback, and then rapidly inspecting and adapting. In the presence of high levels of uncertainty, it is often less expensive to start working on a product, learn whether we made a good decision, and if not, kill it fast before more money is spent. See also fast feedback, inspect and adapt, pivot.

fast feedback. A principle that states that feedback today is much more valuable than the same feedback tomorrow, because today’s feedback can be used to correct a problem before it compounds into a much larger problem, and provides the ability to truncate economically undesirable paths sooner (to fail faster). See also fail fast.

feature. 1. A slice of business functionality that is meaningful to a customer or user. 2. Used by some to mean a medium-size user story that can and will be divided into a collection of smaller user stories that together will be implemented to deliver the value of a feature. See also theme, user story.

feature team. A cross-functional and cross-component team that can pull end-customer features from the product backlog and complete them. See also cross-functional team. Contrast with component team.

fixed-date release. A release that must be delivered on a known future date. The scope of the release, and possibly the cost, needs to be flexible. Contrast with fixed-scope release.

fixed-scope release. A release that must have a specific set of features. The date on which the features are delivered and/or the costs are flexible. Contrast with fixed-date release.

flow. 1. The smooth, steady movement of work through the development process to ensure that good economic value is delivered. 2. Avoiding idle work in economically sensible ways. 3. The opposite of big batch, big release, and big bang.

forecast. 1. Making statements, predictions, or estimations about events whose actual outcomes have not yet been observed. 2. The 2011 “Scrum Guide” term for what a development team generates during sprint planning. See also estimation. Contrast with commitment.

framework. See Scrum framework.

G

grooming. See product backlog grooming.

group. A collection of people who share a common label (the group name) but have not yet formed a team whose members have learned how to work together and trust each other. Contrast with team.

H

happened-upon technical debt. A status category for technical debt that represents debt that the development team was unaware existed until it was exposed during the normal course of performing work on the product. Contrast with known technical debt, targeted technical debt. See also technical debt.

I

ideal day. A unit for estimating the size of product backlog items based on how long an item would take to complete if it were the only work being performed, there were no interruptions, and all resources necessary to complete the work were immediately available. See also ideal hour. Contrast with story point.

ideal hour. A unit for estimating the size of the design, build, integrate, and test work, represented as sprint backlog tasks. Often referred to as an effort-hour, person-hour, or man-hour. See also ideal day.

idle work. Work that is not actively being pursued as it sits in some queue. Contrast with idle workers.

idle workers. People who have available capacity to do more work because they are not currently 100% utilized. Contrast with idle work.

impediment. A hindrance or obstruction to doing something. Frequently used to describe some issue or blocker that is preventing a team or organization from performing Scrum in an effective way.

implementable story. A user story that is sized small enough to fit nicely within a sprint. Synonymous with sprintable story.

incremental development. 1. Development based on the principle of building some before building all. 2. A staging strategy in which parts of the product are developed and delivered to users at different times, with the intention to adapt to external feedback. See also iterative and incremental process, iterative development.

incremental funding. Funding some of the product development without committing to funding all of it. Using incremental funding, we fund just the first small part of the development effort and revisit the funding decision after we have the critical validated learning we are paying to get from the first part. See also confidence threshold, validated learning.

information radiator. A visual display that presents up-to-date, sufficiently detailed, and important information to passersby in an easy, self-interpretable format.

innovation accounting. A measurement/accounting system that uses actionable metrics to evaluate how fast we are learning as a critical measure of progress toward converging on a business-valuable result (Ries 2011).

innovation waste. The lost opportunity to create an innovative solution. Frequently occurs when a prescribed solution is provided with a product backlog item.

in-process product. A product that is currently under development, already live in production, or currently being sold. See also portfolio planning.

insight backlog. A prioritized list of previously generated insights or process improvement ideas that have not yet been acted upon. The insight backlog is generated and used during sprint retrospectives. See also sprint retrospective.

inspect and adapt. 1. A common phase in Scrum that refers to the inspection and adaptation principles of empirical process control. 2. The principle of inspecting a product or process and making adaptations based on what is learned. 3. A key part of the learning loop. See also adaptation, empirical process control, inspection, learning loop.

inspection. One of the three pillars of empirical process control, involving thoughtful examination and processing of feedback to make adaptation decisions regarding the process or product. See also adaptation, empirical process control, transparency.

integration. The combining of the various components or assets of some or all of a product to form a coherent, larger-scope work product that can be validated to function correctly as a whole. See also continuous integration.

internal stakeholders. Stakeholders who are internal to the organization that is developing the product, for example, senior executives, managers, and internal users. See also stakeholders. Contrast with external stakeholders.

inventory. See work in process.

INVEST. An acronym coined by Bill Wake for remembering a set of criteria used to evaluate the quality of user stories. The criteria are Independent, Negotiable, Valuable, Estimatable, Sized correctly (small), and Testable. See also user story.

iteration. A self-contained development cycle focused on performing all of the work necessary to produce a valuable outcome. See also all-at-once development, sprint.

iterative and incremental process. A style of development that leverages both iterative development and incremental development. See also incremental development, iterative development.

iterative development. A planned rework strategy where multiple passes over the work are used to converge on a good solution. See also incremental development, iteration, iterative and incremental process.

J

just in time (JIT). A characteristic of a process whereby the assets or activities of a work stream become available or occur just as they are needed.

K

Kanban. An agile approach overlaid on an existing process that advocates visualizing how work flows through a system, limiting the work in process, and measuring and optimizing the flow of work. See also agile, work in process.

known technical debt. A status category for technical debt that represents the debt that is known to the development team and has been made visible for future consideration. Contrast with happened-upon technical debt, targeted technical debt. See also technical debt.

L

last responsible moment (LRM). A strategy of not making a premature decision but instead delaying commitment and keeping important and irreversible decisions open until the cost of not making a decision becomes greater than the cost of making a decision.

learning loop. A feedback loop focused on increasing learning. Generally follows these steps: make an assumption (or set a goal), build something (perform some activities), get feedback on what was built, and then use that feedback to inspect what was done relative to what was assumed.

lifecycle profits. 1. The total profit potential for a product over its lifetime. 2. In the case of portfolio planning, the total profit potential of the entire portfolio rather than a single product.

LRM. See last responsible moment.

M

means uncertainty. Uncertainty surrounding how something will be built. See also uncertainty. Contrast with customer uncertainty, end uncertainty.

minimum marketable features (MMFs). The smallest or minimum set of functionality related to a feature that must be delivered for the customer to perceive value (for it to be marketable). Contrast with minimum releasable features.

minimum releasable features (MRFs). 1. The minimum set of features that must be present in a release to make it viable—useful enough to end customers such that they want it and would be willing to pay for it. 2. Features composed from a collection of minimum marketable features. Synonymous with must-have features. See also minimum marketable features.

minimum viable product (MVP). A product that has just those features that allow the product to be deployed, and no more.

MMFs. See minimum marketable features.

MRFs. See minimum releasable features.

MVP. See minimum viable product.

Musketeer attitude. 1. All for one and one for all. 2. The attitude among members of a team that they are all in the same boat and that they will win or lose together as a team.

must-have features. The set of features that must be present in the upcoming release for the release to be viable. Synonymous with minimum releasable features. Contrast with nice-to-have features, won’t-have features.

N

naive technical debt. A form of technical debt that accrues due to irresponsible behavior or immature practices on the part of the people involved. Contrast with strategic technical debt, unavoidable technical debt. See also technical debt.

nice-to-have features. Features that are targeted for the upcoming release but could be excluded if there are insufficient resources to finalize their development. Contrast with must-have features, won’t-have features.

nonfunctional requirement. 1. A requirement that does not relate to functionality but to attributes such as reliability, efficiency, usability, maintainability, and portability, which product backlog items must possess in order to be fully accepted by the stakeholders. 2. Each nonfunctional requirement is a candidate for inclusion in the definition of done. See also definition of done.

P

PBI. See product backlog item.

persona. 1. A user archetype, synthesized from the ethnographic data of real users, that helps guide decisions about product features, navigation, interactions, and visual design. 2. A fictitious person that is the prototypical instance of a particular user role. See also user story.

pigs. A metaphor used by some Scrum teams to indicate that people are invested in the goal of the Scrum team at a commitment level (accountable for the outcome). Most people consider the members of the Scrum team to be pigs. See also Scrum team. Contrast with chickens.

pivot. 1. To change directions but stay grounded in what we have learned. 2. A structured course correction designed to test a new fundamental hypothesis about a product, strategy, and engine of growth (Ries 2011).

plan-driven process. A style of development that attempts to plan for and anticipate up front all of the features a user might want in the end product and to determine how best to build those features. The work plan is based on execution of a sequential set of work-specific phases. Synonymous with anticipatory process, predictive process, prescriptive process, sequential process, traditional development process, waterfall process.

Planning Poker. A consensus-based technique for the relative sizing of product backlog items.

point inflation. The unfortunate behavior of inflating the value of product backlog size estimates in an attempt to conform to or optimize an unwisely conceived measure (such as achieving a target velocity).

portfolio backlog. A backlog composed of products, programs, projects, or high-level epics. See also portfolio planning.

portfolio planning. An activity for determining which products (or projects) to work on, in which order, and for how long. Sometimes referred to as portfolio management.

potentially shippable product increment. Results that are completed to a high degree of confidence and represent work of good quality that is potentially shippable to end customers at the end of a sprint. Being potentially shippable does not mean the results will actually be delivered to customers. Shipping is a business decision; potentially shippable is a state of confidence.

practice. The way in which a principle is supported or realized. For example, the principle of demonstrating progress is supported by the sprint review Scrum practice. See activity, artifact, role, rule. See also principle, values.

precision. How exact an estimate is. For example, saying a product will ship on October 7, 2015, is more precise than saying a product will ship in October 2015. Contrast with accuracy.

predictive process. See plan-driven process.

prescriptive process. See plan-driven process.

principle. A fundamental truth or belief that serves as the foundation for how we approach product development. An example Scrum principle is to demonstrate progress frequently. See also practice, values.

principle of least astonishment. Acting or developing work products in a way that is least likely to startle those around you.

product. 1. The result of a product development effort. 2. A good or service consisting of a bundle of tangible and intangible attributes that satisfies consumers and is received in exchange for money or some other unit of value. 3. Typically a longer-lived, more stable artifact against which organizations might conduct one or more projects. See also product development effort. Contrast with project.

product backlog. A prioritized inventory of yet-to-be-worked-on product backlog items. See also product backlog item.

product backlog grooming. The activities of writing and refining, estimating, and prioritizing product backlog items.

product backlog item (PBI). 1. An item such as a feature, defect, or (occasionally) technical work that is valuable from the product owner’s perspective. 2. An item in the product backlog. See also product backlog.

product development effort. The full scope of work performed to create or enhance a product or service. Contrast with project.

product owner. The empowered central point of product leadership. One of the three roles on a Scrum team; the single voice of the stakeholder community to the Scrum team. The product owner defines what to do and in what order to do it. See also Scrum team.

product owner proxy. A person enlisted by the product owner to act on his behalf in particular situations. See also product owner.

product planning. See envisioning.

product roadmap. A description of the incremental nature of how a product will be built and delivered over time, along with the important factors that drive each individual release. Useful when developing a product that will have more than one release. See also envisioning.

product vision. A brief statement of the desired future state that would be achieved by developing and deploying a product. A good vision should be simple to state and provide a coherent direction to the people who are asked to realize it. See also envisioning.

progressive refinement. To disaggregate, in a just-in-time fashion, large, lightly detailed product backlog items into a set of smaller, more detailed items.

project. 1. A temporary endeavor undertaken to create a unique product, service, or result (PMI 2008). 2. An effort that completes when its objectives have been obtained. Compared with a life of a product, a project is shorter in duration. Frequently multiple projects are performed over the full cradle-to-grave lifecycle of a product. Contrast with product.

project chartering. The set of up-front work needed to define a project at a sufficient level of detail that a funding decision can be made. Synonymous with project inception, project initiation.

project inception. See project chartering.

project initiation. See project chartering.

Q

queue. A holding place for items (an inventory) as they wait for the next action in a work stream. See also inventory, work in process.

R

refactoring. A technique for restructuring an existing body of code by improving/simplifying its internal structure (design) without changing its external behavior. Refactoring is one of the principal techniques for managing technical debt. See also technical debt, technical practices.

relative size measure. A means of expressing the overall size of an item where the absolute value is not considered, but the relative size of an item compared to other items is considered. For example, an item of size 2 is half the size of an item of size 4, but we have no idea how big an item of size 2 or 4 is in some absolute sense. See also ideal day, story point.

release. 1. A combination of features that when packaged together make for a coherent deliverable to customers or users. 2. A version of a product that is promoted for use or deployment. Releases represent the rhythm of business-value delivery and should align with defined business cycles.

release goal. A clear statement of the purpose and desired outcome of a release. A release goal is created by considering many factors, including the target customers, high-level architectural issues, and significant marketplace events. See also release.

release plan. 1. The output of release planning. On a fixed-date release, the release plan will specify the range of features available on the fixed future date. On a fixed-scope release, the release plan will specify the range of sprints and costs required to deliver the fixed scope. 2. A plan that communicates, to the level of accuracy that is reasonably possible, when the release will be available, what features will be in the release, and how much will it cost. See also fixed-date release, fixed-scope release.

release planning. Longer-term planning that answers questions like “When will we be done?” or “Which features can I get by the end of the year?” or “How much will this cost?” Release planning must balance customer value and overall quality against the constraints of scope, schedule, and budget. See also release plan.

release train. An approach to aligning the vision, planning, and interdependencies of many teams by providing cross-team synchronization based on a common cadence. A release train focuses on fast, flexible flow at the level of a larger product. See also scrum of scrums.

retrospective. See sprint retrospective.

risk. 1. The likelihood that an event will be accompanied by undesirable consequences. Risk is measured by both the probability of the event and the seriousness of the consequences. 2. Any uncertainty that is expected to have a negative outcome for the activity. See also uncertainty.

role. A cohesive set of responsibilities that may be fulfilled by one or more people. The three Scrum roles are product owner, ScrumMaster, and development team. See also practice, principle.

rule. A common practice or generally reliable method of action in a particular situation. A rule may be broken when the pragmatics of a situation dictate that a different course of action should be pursued. The Scrum framework includes rules. See also essential Scrum, Scrum framework.

S

Scrum. A term borrowed from the sport of rugby. 1. A lightweight agile framework for managing complex product and service development. 2. An iterative and incremental approach to developing products and managing work. See also agile, Scrum framework.

Scrum framework. A collection of values, principles, practices, and rules that form the foundation of Scrum-based development. See also Scrum.

ScrumMaster. The coach, facilitator, impediment remover, and servant leader of the Scrum team. The ScrumMaster is one of the three roles on a Scrum team. The ScrumMaster provides process leadership and helps the Scrum team and the rest of the organization develop their own high-performance, organization-specific Scrum approach. See also Scrum team, servant leader.

Scrummerfall. See WaterScrum.

scrum of scrums (SoS). An approach to coordinating the work of multiple Scrum teams wherein one or more members of each Scrum team come together to discuss and resolve inter-team dependency issues. See also release train.

Scrum team. A team composed of a product owner, ScrumMaster, and development team that works on a Scrum development effort. See also development team, product owner, ScrumMaster.

self-organization. 1. A bottom-up emergent property of a complex adaptive system whereby the organization of the system emerges over time as a response to its environment. 2. A property of a development team that organizes itself over time, without an external dominating force applying traditional top-down, command-and-control management. 3. Reflects the management philosophy whereby operational decisions are delegated as much as possible to those who have the most detailed knowledge of the consequences and practicalities associated with those decisions. See also complex adaptive system, emergence.

sequential process. See plan-driven process.

servant leader. 1. A person who achieves results for her organization by giving priority attention to the needs of her colleagues and those she serves. 2. A philosophy and practice of leadership based on listening, empathy, healing, awareness, persuasion, conceptualization, foresight, stewardship, commitment, and community building. See also ScrumMaster.

silent grouping. A facilitation technique for getting people to group related items without talking, relying only on the individual placement and movement of items (typically cards or sticky notes) as a means of communicating and coordinating among the participants. A technique frequently used during the sprint retrospective activity. See also sprint retrospective.

simple domain. 1. A situation in which everyone can see cause and effect. Often the right answer is obvious and undisputed. 2. One of the domains in the Cynefin framework. See also Cynefin. Contrast with chaotic domain, complex domain, complicated domain, disorder domain.

single-piece flow. A state where items are produced one at a time and flow (are pulled) through the development process as a single unit.

solution. A product or a service that results from a development effort.

SoS. See scrum of scrums.

specification by example. See acceptance-test-driven development.

sprint. A short-duration, timeboxed iteration. Typically a timebox between one week and a calendar month during which the Scrum team is focused on producing a potentially shippable product increment that meets the Scrum team’s agreed-upon definition of done. See also definition of done, iteration, potentially shippable product increment.

sprintable story. See implementable story.

sprint backlog. 1. An artifact produced at a sprint-planning meeting and continuously updated during sprint execution that helps a self-organizing team better plan and manage the work necessary to deliver on the sprint goal. 2. A list of the product backlog items pulled into a sprint and an associated plan for how to achieve them—frequently expressed in terms of tasks that are estimated in ideal hours. See also ideal hour, sprint planning, task.

sprint demo. 1. An activity of a sprint review where the completed (done) product backlog items are demonstrated with the goal of promoting an information-rich discussion between the Scrum team and other sprint review participants. 2. A term that is frequently used synonymously to refer to the entire sprint review. See also sprint review.

sprint goal. A high-level summary of the goal the product owner would like to accomplish during the sprint. Frequently elaborated through a specific set of product backlog items.

sprint planning. A time when the Scrum team gathers to agree on a sprint goal and determine what subset of the product backlog it can deliver during the forthcoming sprint. During sprint planning, a sprint backlog is produced to help the team acquire confidence that it can deliver the committed product backlog items. See also sprint backlog, sprint goal.

sprint retrospective. An inspect-and-adapt activity performed at the end of every sprint. The sprint retrospective is a continuous improvement opportunity for a Scrum team to review its process (approaches to performing Scrum) and to identify opportunities to improve it. See also inspect and adapt, sprint retrospective.

sprint review. An inspect-and-adapt activity that occurs after sprint execution where the Scrum team shows to all interested parties what was accomplished during the sprint. The sprint review gives everyone with input in the product development effort an opportunity to inspect what has been built so far and adapt what will be built next. See also inspect and adapt, sprint demo.

stakeholder. A person, group, or organization that affects or can be affected by an organization’s actions. See also external stakeholders, internal stakeholders.

stakeholder value. The value that a solution delivers to stakeholders. Sometimes used interchangeably with customer value. See also stakeholder.

story. See user story.

story mapping. 1. A technique that takes a user-centric perspective for generating a set of user stories. Each high-level user activity is decomposed into a workflow that can be further decomposed into a set of detailed tasks. 2. A two-dimensional representation of a traditional one-dimensional product backlog list. See also product backlog, user story.

story point. A measure of the relative size of product backlog items that takes into account factors such as complexity and physical size. Typically determined by engaging in Planning Poker. See also ideal day, Planning Poker, relative size measure.

strategic filter. The decision criteria used by an organization to evaluate whether a proposed product meets the strategic criteria to move forward for additional consideration. Contrast with economic filter.

strategic technical debt. A form of technical debt that is used as a tool to help organizations better quantify and leverage the economics of important, often time-sensitive, decisions. Sometimes taking on technical debt for strategic reasons is a sensible business choice. Contrast with naive technical debt, unavoidable technical debt. See also technical debt.

sustainable pace. The appropriately aggressive pace at which a team works so that it produces a good flow of business value over an extended period of time without getting burned out.

swarming. A behavior whereby team members with available capacity and appropriate skills collectively work (swarm) on an item to finish what has already been started before moving ahead to begin work on new items. See also T-shaped skills.

synchronization. Causing multiple events to happen at the same time. Frequently used to ensure that multiple Scrum teams work together in a coordinated way by starting and ending their sprints on the same days. See also cadence.

T

tacit knowledge. Unwritten and unspoken knowledge (including insights, intuitions, and hunches) that is hard, but not impossible, to articulate with formal language. The opposite of explicit or formal knowledge. Sometimes referred to as “know-how.”

targeted technical debt. A status category for technical debt that represents debt that is known and has been targeted for servicing by the development team. Contrast with happened-upon technical debt, known technical debt. See also technical debt.

task. The technical work that a development team performs in order to complete a product backlog item. Most tasks are defined to be small, representing no more than a few hours to a day or so of work.

task board. An information radiator used during sprint execution to communicate the progress and flow of task-level work within a sprint. See also information radiator, task.

TDD. See test-driven development.

team. A small, cross-functional collection of diverse, collaborating people who are aligned to a common purpose and goal. Team members trust each other and work together to achieve the goal, holding themselves mutually accountable for the outcome. Contrast with group.

technical debt. 1. A term used to describe the obligation that a software organization incurs when it chooses a design or construction approach that is expedient in the short term but that increases complexity and is more costly in the long term. 2. A metaphor that facilitates the communication between business and technical people regarding implementation artifact inadequacies. See also naive technical debt, strategic technical debt, unavoidable technical debt.

technical practices. The specific practices or techniques that are used during sprint execution to properly perform the work required to deliver features that have manageable levels of technical debt and meet the Scrum team’s definition of done.

technical stories. A “user” story (product backlog item) that delivers no perceived end-user value but does deliver important architecture or infrastructure needed to deliver future user value. See also user story.

technique. A defined procedure that is used to perform some or all of an activity or support an approach. See also activity, approach.

test-driven development (TDD). 1. An evolutionary approach to development based on writing a failing automated test before the functional code that makes the test pass. Once the code is written to pass the test, the cycle is then repeated, including refactoring the existing code to ensure a coherent cross-functional design. The goal of test-driven development is specification and not validation—to think through a design before code is written, to create clean code that always works. 2. An example of test-first development. See also refactoring, technical practices, test-first development.

test-first development. A technical practice where the tests are written before the development is performed. An example is test-driven development. See also technical practices, test-driven development.

theme. A collection of related user stories. A theme provides a convenient way to indicate that a set of stories have something in common, such as being in the same functional area. See also epic, user story.

timebox. A fixed-length period of time during which an activity is performed. In Scrum, sprints are timeboxed iterations where a team works at a sustainable pace to complete a chosen, WIP-limited set of work. See also sprint, timeboxing.

timeboxing. A time management technique that helps organize the performance of work and manage scope. See also timebox.

traditional development process. See plan-driven process.

transparency. One of the three pillars of empirical process control; open access to the unbiased information required for inspection and adaptation. See also adaptation, empirical process control, inspection.

T-shaped skills. A metaphor used to describe a person with deep vertical skills in a specialized area (such as UX design) as well as broad but not necessarily very deep skills in other relevant areas (such as testing and documentation). Team members with T-shaped skills better enable swarming behavior. See also swarming.

U

unavoidable technical debt. A form of technical debt that is usually unpredictable and unpreventable and accrues through no fault of the team building the product. Contrast with naive technical debt, strategic technical debt. See also technical debt.

uncertainty. Something that is not known or established. Often considered synonymous with risk but is actually broader in scope because uncertainty includes both risks (negative outcomes) and opportunities (positive outcomes). See also risk.

unknown unknowns. The things that we don’t yet know that we don’t know.

unnecessary formality. 1. A ceremony that has a real cost but delivers little or no value (a form of waste). 2. Process for the sake of process. See also ceremony, waste.

user role. 1. The name for a class of product users. 2. One of the key elements of a user story that defines the recipient of the value delivered by a user story. See also user story.

user story. A convenient format for expressing the desired business value for many types of product backlog items. User stories are crafted in a way that makes them understandable for both business people and technical people. They are structurally simple and typically expressed in a format such as “As a <user role> I want to achieve <goal> so that I get <benefit>.” They provide a great placeholder for a conversation. Additionally, they can be written at various levels of granularity and are easy to progressively refine. See also epic, progressive refinement, theme, user role.

user-story-writing workshop. A workshop lasting from a few hours to a few days where a diverse team of participants collectively brainstorms desired business value and creates user story placeholders for what the product or service is supposed to do. See also user story.

V

validated learning. A term proposed by Ries (2011) to describe the progress made when important assumptions have been confirmed or refuted by subjecting each assumption to one or more customer validation tests. Contrast with assumption.

values. 1. Those things that we hold dear or precious. 2. The foundation of a shared operating agreement among members of a team. Core Scrum values include honesty, openness, courage, respect, focus, trust, empowerment, and collaboration.

variability. The spread or dispersion of a set of data representing non-identical outcomes. In manufacturing, variability is always waste. In product development, some variability is necessary to develop innovative solutions. See also waste.

velocity. A measure of the rate at which work is completed per unit of time. Using Scrum, velocity is typically measured as the sum of the size estimates of the product backlog items that are completed in a sprint. Velocity is reported in the same units as product backlog items—usually story points or ideal days. Velocity measures output (the size of what was delivered), not outcome (the value of what was delivered).

W

waste. Any activity that consumes resources and produces no added value to the product or service that a customer receives.

waterfall. A term referring to the graphical depiction of a development process in which the sequential phases of work are shown flowing steadily downwards like a cascading waterfall. See also plan-driven process.

waterfall process. See plan-driven process.

WaterScrum. Overlaying waterfall-style development on the Scrum framework. An example would be performing an analysis sprint, followed by a design sprint, followed by a coding sprint, followed by a testing sprint. Synonymous with Scrummerfall.

weighted shortest job first (WSJF). An economically optimal algorithm for scheduling work in an environment where both the cost of delay and the duration vary among the work items. See also cost of delay.

WIP. See work in process.

won’t-have features. The set of features that are specifically declared to not be in the upcoming release. Contrast with must-have features, nice-to-have features.

work in process (WIP). Work that has entered the development process but is not yet finished and available to a customer or user. Refers to all assets or work products of a product or service that are currently being worked on or waiting in a queue to be worked on.

WSJF. See weighted shortest job first.

X

XP. See Extreme Programming.