Agile Glossary

Acceptance Criteria act as indicators of what "done" means for a specific user story. (That is, Acceptance Criteria work in conjunction with the Definition of Done; Acceptance Criteria are user-story-specific, while the Definition of Done is global.) To cite a more formal definition, from (IEEE 610): 1. The external quality characteristics specified by the product owner (or a proxy for the PO) 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

Team members with different perspectives (for example, customer, development, testing) collaborate to write acceptance tests in advance of implementing a particular functionality. The discussions that occur to generate acceptance tests are often referred to as the "three amigos," representing the three perspectives of customer (what problem are we trying to solve?), development (how might we solve this problem?), and testing (what about…). These acceptance tests represent the user’s point of view and act as a way to describe how the system will function, as well as serve as a way of verifying that the system functions as intended.

A technique that enables rapid estimation of a potentially large set of work items with little discussion about each item. A common approach is to write all work items on index cards or Post-it Notes, and either slide them across a table top (if using index cards) or move them across a white board (if using Post-it Notes). The most common sizing construct is T-shirt sizing, where there might be columns for Extra-Small, Small, Medium, Large, and Extra-Large

A method of categorizing a group of items by themes (things they have in common). Items with a higher degree of correlation (affinity) are clustered together, while items with a lower level of correlation are further apart. See also affinity estimation

Pertaining to the Agile Manifesto and the set of values and principles on which the Agile Manifesto is based, as well as Lean thinking, a set of principles and practices that maximize customer value while minimizing waste and reducing time to market. Lean thinking includes five elements: the goal, kaizen (continuous improvement), product development flow, respect for people and Lean-Agile Leadership. One of the biggest differences between Agile development and Waterfall development is a recognition that there are a great many unknowns whenever a new software development undertaking begins, and that it is not realistic to make a plan in advance which can possibly account for all of those unknowns. To speed the process of discovery along, Agile development focuses on incremental delivery over short time periods, which shortens the feedback loop, and helps teams gain valuable insights from customers and stakeholders on the most recently built portion of the product (what Scrum calls the "Product Increment").

An output from human activity, such as a product, along with things that can potentially support or constitute a product, such as code, test scripts, user manuals, and so on. In Scrum, there are three artifacts: Product Backlog; Sprint Backlog; and the Increment.

An ordered list of items to be worked on, where the most important items are at the top of the list, and the least important items are at the bottom of the list. It is a common practice for the items at or near the top of the list to be much better articulated (that is, have more descriptive information) than those at the bottom, because especially when backlogs contain a large number of items, those at the bottom of the list might never be worked on, due to shifts in priority and other business constraints. See also Product Backlog; Sprint Backlog.

Many teams have planning conversations in addition to those that are formally part of Scrum, for instance. Backlog refinement is typically a conversation during which some or all team members seek to make various work items "ready" for the team to work on. It is also common for items to be added to or removed from the Product Backlog. For Scrum teams, it is common for backlog refinement to take place about once per Sprint. (Backlog refinement is not formally part of Scrum, however, it is common enough that it has been referred to as a Generally Accepted Scrum Practice, or GASP.)

A synthesis of practices originating with Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD), BDD augments TDD and ATDD in the following ways: applies the “Five Why’s” principle to each proposed user story, so that its purpose is clearly related to business outcomes; thinking “from the outside in”, in other words implement only those behaviors which contribute most directly to these business outcomes, so as to minimize waste; describe behaviors in a single notation which is directly accessible to domain experts, testers and developers, so as to improve communication; apply these techniques all the way down to the lowest levels of abstraction of the software, paying particular attention to the distribution of behavior, so that evolution remains inexpensive.

Although a common reaction when a project is thought to be behind schedule is to add people to the effort, the impact of the addition of more people is that it initially slows the project down. The term is named after Fred Brooks, author of a book called the Mythical Man Month, in which he describes this phenomenon. He observes that the time it takes for people added to a project to become productive is "ramp up" time, because as they learn the new problem space, they typically need to rely on one or more existing team members for information, which slows those team members down, at least for a period of time. diminishing their productivity while the new workers are not yet contributing meaningfully. Another impact of making a team larger is that the increases in the number of communication channels results in an exponential increase in communication nodes (as more people are added they spend more time trying to find out what everyone else is doing).

A regular, predictable rhythm or heartbeat. Actualizations of the concept include running Sprints of a consistent duration to establish a rhythm for a development effort, and releasing code to production in accordance with a reasonably consistent, time-based pattern.

1. In a general Agile team context, the amount of work that can be completed by that team during a given time interval, based on evaluation of the past history of that team, along with other data, as available; 2. In a Kanban context, a number that is set on a particular workflow state, to indicate the Work in Progress (WIP) limit, such that a new work item can only enter that workflow column when there is available capacity. For definition #1, it is important to point out that capacity is specific to that particular team.

A process or mechanism through which changes are introduced, at a systemic (organizational) level, or at a more tactical level, such as changes to a particular product or set of products. Various change management models exist, with different levels of rigor and complexity. In iterative software development, change management is essentially a continuous activity, throughout the product lifecycle.

A team that has an area of focus that tends to fall in one of these two categories: 1) working on a particular service; 2) working on a particular technical specialization, or a group of related areas of technical specialization. As such, component teams often work in areas that have strict Service Level Agreements (SLAs).

An extension of Continuous Integration, where the goal is to minimize lead time. The team relies on infrastructure that automates and instruments steps leading up to deployment, so that after each integration successfully meeting release criteria, the live application is updated with new code. Instrumentation is necessary to ensure that any suggestion of lowered quality results in aborting the deployment process, or rolling back the new features, and triggers human intervention.

The two main objectives are: minimize the duration and effort required by each integration; be able to deliver a product version suitable for release at any moment. To achieve these dual objectives, it is necessary to have an integration procedure which is reproducible and also mostly or entirely automated. Version control tools, team policies and conventions, and tools specifically designed for code integration are employed.

A development team that has everyone and everything it needs to produce a shippable product increment. To accomplish this, members of a team have many different skills, and seek to work together as much as possible to get the work done.

A chart that shows the number of items in each state of a workflow over time. Such a chart shows the length of time that it takes, on average, for work items to progress through a particular workflow state, or through some or all of a system. The CFD also makes it easier to visualize where bottlenecks are building up, constraining the flow of work.

A short meeting of no more than 15 minutes, during which a team shares knowledge, volunteers to help each other, identifies dependencies/risks, and agrees on next steps for removing roadblocks. It is important to emphasize that the purpose is NOT status reporting -- the desired outcome is team alignment. The term is synonymous with the daily standup in Extreme Programming (XP).

A working agreement for a team or teams that sets a standard for achieving a “Done” user story, in addition to user-story-specific Acceptance Criteria. It is common for a DoD to address conditions that need to be universally true for the product in question, such as the so-called "-ilities" (maintainability, scalability, security, usability). As stated in the Scrum Guide, it is important to "have a shared understanding of what it means for work to be complete, to ensure transparency."

A team level agreement clearly identifying the conditions work must meet before the team can commit to accepting it into a Sprint Commitment or PI Plan. The DoR is designed to protect the team from committing to high-risk or unclear work and clearly identifying the conditions work must meet so stakeholders can provide accurate information about the needed work.

The team of people responsible for building and delivery valuable software to the business. Typically a team will contain developers and testers, and often analysts, architects, designers and other Subject Matter Experts (SMEs) as needed.

A self-organizing, cross-functional team of people who collectively are responsible for all of the work necessary to produce working, validated product artifacts. The Development Team is one of the three roles that are part of Scrum, where the team should have everyone and everything it needs to deliver value on a repeatable basis, with little to no reliance on any external entity.

The idea that any given individual can maintain a limited number of social relationships, where each person in the network has some awareness of who every other person in the network is. Anthropologist Robin Dunbar sets this number at between about 150 and 200.

In contrast with a fully defined process, where it is thought possible to know everything in advance, an empirical process rests on the assumption that visibility, inspection, and adaptation are necessary when doing planning in relatively small, manageable chunks, where each small piece seeks to test one or more assumptions. For instance, an individual user story is stating an assumption about what a customer will find valuable, but is not a fully defined implementation plan in and of itself. Each subsequent delivery of value results in a more fully formed picture of what the customer wants, and either proves or disproves a particular hypothesis about customer needs and desires.

A large user story, completion of which could potentially take weeks or months. Epics can be helpful as placeholders for large requirements, for instance, as part of strategic visioning and roadmapping activities. Epics are progressively elaborated and broken down into a set of smaller user stories.

A rough calculation of the value, number, quantity, or extent of something. In Scrum, it is common for teams to estimate the size of portfolio backlog items, product backlog items, and sprint backlog items. It is also important to note that also a majority of Scrum teams do some form of estimation, estimation as a practice is not part of Scrum. Furthermore, there are some Agile software development teams that do just fine without estimation.

An approach to testing software which significantly different from more traditional, scripted testing activities, and which has the following characteristics: it emphasizes the tester’s autonomy, skill and creativity, much as other Agile practices emphasize these qualities in developers; it recommends performing test-related activities (such as test design, test execution, and interpretation of results) in an interwoven manner, throughout a project, rather than in a fixed sequence and at a particular “phase”; it emphasizes the mutually supportive nature of these techniques, and the need for a plurality of testing approaches rather than a formal test plan.

A software development approach that places emphasis on technical practices that development teams use to manage the flow of task-level work during sprint execution. Like other Agile approaches, It is successful because it stresses customer satisfaction via delivery in reasonably small batches. It also places strong emphasis on teamwork, featuring approaches such as pair programming, test-first development (aka Test Driven Development), collective code ownership, and refactoring. Note that it is commonplace for "Scrum Teams" to employ many of the XP technical practices, and thus, such teams are actually following an approach that is a Scrum-XP hybrid.

Any meeting or activity where a group is present can benefit from having a person present who makes sure they agree on what they are trying to accomplish, take steps that accomplish those goals, and confirm what they have achieved at the end of the conversation. Skilled facilitators use many techniques to help guide the group to help them achieve their goals, without steering the conversation in a particular direction. That is, a facilitator manages the method of the meeting, not the content of the meeting.

A hindrance or obstruction to getting something done. In Scrum, frequently used to describe some issue or blocker that is preventing a team from making progress on a work item. Also used in a broader organizational sense to describe anything that can potentially slow or stop progress.

An idea based on incomplete evidence used as a starting point for further investigation. Often referred to as an “educated guess” and used in trials, these are foundations for experiments used to test theories in product development and process improvement. A good hypothesis statement has a clear problem, a clear action and an expected outcome.

In Scrum, the sum of all the Product Backlog items that a team finishes during an iteration (Sprint), along with the value of the Increments of previous Sprints. At the conclusion of a Sprint, the new Increment must be "Done," which means the work items are in useable condition and also meet the Definition of Done. As such, an Increment is a body of finished work that achieves a step toward a vision or goal, regardless of whether the Product Owner decides to release it.

Handwritten, drawn, printed or electronic representations or displays which are placed in a visible location, so that all team members as well as others who pass by can see the latest information at a glance: count of automated tests, velocity, cycle time, incident reports, continuous integration status, and so on. Use of information radiators helps reinforce the notion that a team has nothing to hide from its visitors (customers, stakeholders, etc.), and also that it has nothing to hide from itself (it acknowledges and addresses problems).

Activities that seek to continuously improve all functions and involve all employees, from the executive level to the level of individual contributors. As such, it applies to processes, such as purchasing and logistics, that cross organizational boundaries into the supply chain. The foundational level of kaizen in a Scrum context is the Sprint Retrospective, such that areas of potential improvement are surfaced by individual teams, so that the team can prioritize and act upon those improvements.

Kanban is a technique that helps visually manage the way work flows though a system, for instance, through a software team's work queue. It is an agile approach that is often overlaid on an existing process–for instance, when a Scrum Team uses a physical or electronic board to see how work is flowing to done–limiting the work in process, and measuring and optimizing that flow of work. To quote from one of the most definitive books on the topic, David J. Anderson's Kanban: Successful Evolutionary Change for Your Technology Business" (aka the "blue book") (p. 12): "In software development, we are using a virtual kanban system to limit work-in-progress...The signal to pull new work is inferred from the visual quantity of work-in-progress subtracted from some indicator of the limit (or capacity)."

Teams make their work visible on a physical or electronic board, such the movement (flow) of work items toward done is apparent. On Kanban Boards, teams agree to Work In Progress (WIP) limits, where for particular workflow states, the number of work items cannot exceed a particular number, which is set by the team. Teams using Kanban Boards also agree to make policies explicit, where they define exit criteria that must be satisfied to move from one workflow state to another on the board.

Certain values, principles, techniques and practices have been proven to work in a variety of work environments, including manufacturing and software development. Many of these ideas originated from the Toyota Production System. The usage of the term "Lean" in conjunction with software development first occurred in the early 2000s, starting with a comparison of traditional lean principles, along with a set of lean tools and techniques, with corresponding agile practices. The usage of Kanban by many software development teams is an example of practical application of Lean concepts.

The notion in psychology that the human brain is capable of maintaining 7 +/- 2 pieces at a time for immediate recall. This principle is also applied to the ideal number of team members on a cross-functional team, such that, by keeping team size in this range, it is possible for every person on the team to be reasonably familiar with what every other member of the team is working on, and to potentially assist one or more team members.

The smallest usable deliverable that can serve as a means of validating the idea behind a business or product. The first increment of the build/measure/learn cycle, it can help demonstrate that the market exists for a particular idea. What often gets lost is the "minimalist" aspect; all that is necessary from a delivery perspective might be something as simple a landing page, or a service with an appearance of automation, but which is fully manual behind the scenes, which is sufficient for customers to interact with, so that it is possible to observe their behavior with the product or service. Seeing what people actually do with a product is much more reliable than asking people what they would do.

Addresses characteristics of a product that do not in and of themselves deliver direct user value, such as load handling, performance, browser compatibility, or mobile-friendly design. It is common for a Definition of Done to address various NFRs, and as such, NFRs can be seen as guardrails for the system being built, in terms of how the system behaves and performs. It is also common to refer to NFRs as "-ilities," for example, scalability, security, usability.

In a more formal sense, an eXtreme Programming (XP) practice, where two people work closely together, where they take turns writing code (the Driver) and reviewing and testing the code (the Navigator). Also, in a less formal sense, any time two team members work together such that the overall quality of the solution they produce is better than what would be possible if they worked alone, resulting in a lower chance that rework will be needed, either in the form of fixing defects or refactoring.

A technique that helps ensure conversations stay focused on accomplishing one or more specific objectives, by deferring discussion of any topics that do not directly contribute to accomplishing those objectives to a later time. Typically, a visible space is marked as a Parking Lot, and attendees add any out-of-scope topics to the Parking Lot, as they arise. A facilitator often helps curate the items as they are added to the Parking Lot, and works with the attendees to reach agreement on how to handle those items before the close of the meeting, either by discussing one or more of them (time permitting), and/or by agreeing on next steps for any items that could not be addressed during the meeting.

Plan, Do, Check, and Act, a cyclical method of performing work and receiving feedback on the work. Incorporates feedback loops to reinforce an empirical process, which focuses on inspection and adaptation instead of following a comprehensive, fully defined plan, where that plan is established up front and adhered to regardless of the outcomes or discoveries along the way.

To determine how many lines of communication exist between one node (person) and every other node in a group of people, the Permutation Formula shows that as team size increases, the lines of communication increase geometrically, to the point where effective 1:1 communication and team collaboration on a regular basis becomes not only difficult, but less effective. It is for this reason that the size of Agile teams most often falls in a range that falls between about 4 and 9. (Drawing a series of dots to represent each node of communication, that is, each team member, and connecting those dots, is also an effective way to illustrate this concept.)

A detailed biography/profile of fictitious user of a product, which is concise and visual. A common layout is a single page including a photograph (often a simple depiction, such as a cartoon), and a name and social or professional details: “Fred Rogers, 53, former host of a popular television show for children.”Because a software product is often intended for use by more than one type of person, with potentially different preferences and expectations, the team might choose to create one persona for each user category it deems important for the product.

A consensus-based technique where a team uses a physical deck of "planning poker" cards (or a proxy for physical cards) to agree on relative sizing of work items. Each team member reveals the value of the card representing their idea of relative size at the same time, at which time the team discusses outliers and votes again, if necessary. By hiding the chosen values until everyone is ready, the team can avoid the cognitive bias of anchoring, where the first number spoken aloud can set a precedent for subsequent estimates.

The way in which a principle is supported or realized via demonstration or actualization. For example, in Scrum, the principle of demonstrating progress is supported by the Sprint Review practice. Similarly, in Extreme Programming (XP), there are multiple technical practices that realize various Agile principles.

A list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver to achieve a specific outcome, such as the creation of a new product or modifications to an existing product. The Product Backlog is the single authoritative source for things that a team works on. Inclusion of a work item in a Product Backlog means that it is an option the team has for delivering a specific outcome; at any point a work item could be removed from a Product Backlog or deprioritized. The work items in a Product Backlog can vary considerably in size and also how well articulated they are, where more time is spent preparing the highest-priority work items, which are likely to be worked on sooner, than it is on items that are lower in priority. See also Sprint Backlog.

An individual with the authority to set the direction for a product, or a family of products, using analytical methods such as market research, trend analysis, and structured or unstructured interviews and other forms of interaction with individual customers or a sample of the customer population. As such, Product Managers set strategy and vision for the product(s) under their purview, and partner with others to make sure work done on the product(s) aligns with the organizational mission and vision, and is correctly prioritized with competing streams of work on other products.

The empowered central point of product leadership at the team level, and one of the three roles on a Scrum team, the PO acts as the single voice of the stakeholder community to the Scrum team. Key responsibilities include ensuring that the product vision, goals, and scope are clear, setting the priority for work that the team does, and providing formal acceptance of individual work items.

A person who is responsible for helping coordinate the activities associated with the planning, procurement and execution of a project, where a project is generally understood to be any undertaking that has a defined scope, defined start, and a defined finish. It is common for Project Managers to be an initial point of contact for any issues or discrepancies associated with the work being done on the project; rather than participating directly in the activities that produce the end result, Project Managers focus on keeping track of project progress, focusing primarily on reducing the risk of project failure, maximizing project benefits, and minimizing project costs. It is important to point out that PMs work outside the context of Agile teams; for example, the responsibilities of Scrum Masters and Project Managers are significantly different, and a Scrum Master is a role on a Scrum Team, while a Project Manager is not a role on a Scrum Team.

When the form of code is improved to remove unnecessary spaces, comments, clumsy logic structures, nested loops, and other anti-patterns that cause code performance to decrease. The overall end-to-end functionality from the user's perspective does not change, apart from a possible improvement in areas such as efficiency or performance.

A method of estimating that uses a scale to compare the complexity and effort for work items in association with each other, rather than trying to assign an exact value on an absolute scale. It is common for teams to use T-shirt sizes or numbers from a modified form of the Fibonacci Sequence as a frame of reference for establishing relative estimates. It has also been observed that teams reach a point of diminishing returns rapidly when they seek to attain a level of precision with estimation that is not realistically possible in software development.

A construct that helps teams manage product development and other "knowledge work" through empirical process control, in that it provides a means for teams to establish a hypothesis of how they think something works, test the hypothesis, reflect on the experience, and make any appropriate adjustments. It seeks to enable a dedicated, cross-functional Scrum Team to consistently deliver value and uses a particular set of Events, Artifacts, and Roles to show progress on an iterative basis. Scrum by itself is seldom enough to ensure success over the medium to long term, and thus "Scrum teams" typically employ principles and practices associated with Lean, Kanban, and eXtreme Programming (XP), to name a few examples.

A coach, facilitator, impediment remover, and servant leader, the SM is one of the three roles on a Scrum team. The SM works with the team to establish psychological safety, ensuring they are collaborating effectively and delivering business value at a consistent, sustainable pace. The SM also acts as a change agent at the team level and beyond, seeking to identify areas of potential improvement and launching experiments to help the team and the organization continuously improve.

Teams decide for themselves who will do what work, keeping in mind the skills and abilities of team members, and the preferred ordering of completing particular work items. That is, self-organizing teams are fully empowered in terms of HOW they complete a particular body of work, where it is assumed that they understand the WHAT and the WHY of that body of work.

A view of how groups interact, based on the ways in which their relationships and other dynamics are defined. A key aspect is based on building Communities of Practice, which tend to be more durable and to demonstrate autonomous forms of interactions, driven by the interests of the group. Communities of Practice can also be incubators for discovery, innovation, and Continuous Improvement.

In Scrum, a fixed timebox (iteration) that repeats during a product development effort. Throughout a Sprint, a team focuses on completing work items, so as to deliver business value during every Sprint, such that there is a steady flow of work to Done. The work items that the team completes during the Sprint are referred to collectively as the Increment.

A set of work items that are chosen to be worked on during a particular iteration; in Scrum, an iteration is called a Sprint, and thus the set of work items a team decides to work on during that iteration are collectively referred to as the Sprint Backlog. Teams are strongly encouraged to be very selective about how many work items they include in a Sprint Backlog; that is, only include work items that they are confident they can complete. When teams start a Sprint with more work items than they can realistically complete, what happens is that the team tries to work on too many things at the same time, and as a result, has trouble finishing work by the end of the Sprint. See also Product Backlog.

In Scrum, a statement, or a set of statements, which summarize what the expected outcome(s) is/are at the end of a Sprint. Establishing a Sprint Goal or Sprint Goals helps ensure that all members of a Scrum Team have a shared understanding of what they seek to accomplish, and also acts as a summation of business value which can be more readily understood by stakeholders than the list of work items that the Scrum Team intends to complete.

In Scrum, a meeting that occurs at the beginning of an iteration (Sprint), where the Scrum Team examines the Product Backlog, and selects a set of high-priority items to work on during that Sprint. The primary outcomes from Sprint Planning include articulation of a Sprint Goal or Goals, decisions on what to work on, and decisions on what approach is to be taken to complete the selected work items.

In Scrum, a meeting that occurs at the end of an iteration (Sprint), where a team reflects on the process that it is following, celebrates things that are going well, and identifies actionable steps associated with areas of potential improvement. A Scrum Team might choose to evaluate many different aspects of its work, focusing in particular on team dynamics, and also rules and artifacts that inform how it works together, such as its Definition of Ready, Definition of Done, and Team Working Agreement. It is important to emphasize that ONLY members of a Scrum Team attend its Sprint Retrospective, to help ensure that the members of the team have psychological safety and can have an open and honest conversation.

In Scrum, a meeting that takes place at the end of an iteration (Sprint), where one or more Scrum Teams engage with stakeholders to inspect the work that was done during the Sprint, and get feedback on that work. A significant portion of the Sprint Review consists of a demonstration of working software, emphasizing what functionality has changed with the last Sprint Review. The conversation during the Sprint Review can also potentially change the nature of the work that a Scrum Team does during subsequent Sprints, based on the nature of the customer feedback.

Many teams employ abstract units to represent the difference in relative complexity and effort associated with one work item versus another. For instance, a team might have an agreement in place where a very small work item is 1 story point, a medium-sized work item is 5 story points, and a large work item is 8 story points. Teams that use story points for relative estimation often use numbers from the Fibonacci Series to represent relative size, in part because each number in the series is significantly greater or lesser than the adjacent numbers, which helps serve as an indicator that uncertainty is greater as items get larger.

Working at a pace that is reasonable over the medium to long term makes it easier to plan releases and iterations and helps avoid putting teams in a "death march." situation. Arriving at a pace that is consistently sustainable over the course of the lifespan of work on a particular product is unique to each team. As described in the original guidance on the topic, from Extreme Programming, "Demanding this team increase velocity to match that team will actually lower their velocity long term. So what ever your team's velocity is just accept it, guard it, and use it to make realistic plans."

Whenever teams feel pressured to finish work ahead of deadlines that may not be realistic, they may lack sufficient time for activities such as code refactoring, and writing and executing various forms of tests. Over time, if teams are repeatably put in a similar situation of feeling they need to cut corners to meet a deadline, it gets increasingly difficult to add new features to, or even maintain, the code base, and the greater the degree of difficulty in enhancing or maintaining the code, the higher the level of technical debt. The use of a familiar financial metaphor helps reinforce the idea that the greater the amount of technical debt that is accrued in any given system, the more difficult it is to support, and eventually only "interest" is being paid on the debt, while nothing is being paid on the "principal."

A style of programming where three activities are tightly coupled: coding, testing (in the form of writing unit tests) and design (in the form of refactoring). It can be described by the following of rules: write a “single” unit test describing an aspect of the program; run the test, which should fail because the program lacks that feature; write “just enough” code, the simplest possible, to make the test pass; refactor the code until it conforms to the simplicity criteria; repeat, adding more unit tests and the corresponding code.

A means of capturing the essential elements behind a user story as originally articulated by Ron Jeffries: a "Card" (often a Post-It note or index card), which serves as a physical and/or virtual token giving durable form to what would otherwise only be an abstraction; a "Conversation" which can take place at different times and places among the members of the team, to get clarity about what is to be built, and which may be supplemented by written documentation, and; the "Confirmation", a means of making sure there is agreement on what "done" means for that user story, typically formalized via one or more Acceptance Criteria.

A constraint that is placed on an event, where when a particular amount of time has expired, the event is officially over. A two-week iteration or Sprint is an example of a timebox. It is also common to "timebox" the duration of particular meetings, where they end after a set amount of time.

The time that a product is actually being worked on, and value is being added, in a Lean Production system (an Agile Development Team that applies Lean principles such as flow and Kanban is part of a Lean Production system). This is typically only a small proportion of the total production time, since much of the time is taken up by moving, queuing, and waiting due to hand-offs. See also wait time.

Four stages of group dynamics - Forming - Storming - Norming - Performing - first described by Bruce Tuckman in 1965, in a Psychological Bulletin article titled "Developmental sequence in small groups." It has been observed that when a group experiences a change to its composition, for instance, when a person leaves or a new person joins, they often regress to one of the earlier stages. It for this reason, among others, that many practitioners prefer to keep groups (teams) intact for a reasonably long period of time.

Automated tests that concentrate on verifying that code works as written, and which act as safety flags in high-churn agile development environments with frequent check-ins, changes, and multiple developers in the same code base. The outcome of a unit test is binary: either "pass" if the program's behavior is consistent with the recorded expectations, or "fail" otherwise. By convention dating back at least to the JUnit family of tools, the color red (as in "getting a red bar") represents a failure of one or more tests, and the color green ("a green bar") denotes successful test execution. It is a common practice to automatically execute unit tests as part of every build.

A way of expressing a reasonably small unit of work that needs to be done to meet a particular customer or user need and thereby provide business value. User stories are articulated in such a way that they are understandable for both business people and technical people. It is a common practice to include a sentence in a format similar to “As a I want so that I get .” A user story is also an "invitation to a conversation" where a team makes sure they have a good enough understanding of the user story that they can build it without further conversation (see also the "3Cs"). When writing user stories on physical media (post-it notes or index cards) or in an electronic tool, it is important to agree on what the baseline set of attributes is for any given user story, for instance, story title/headline, story description, Acceptance Criteria.

A number that expresses the total volume of work completed by a team during an iteration, where those completed work items all satisfy the work-item-specific Acceptance Criteria, along with the global Definition of Done. Velocity is most often measured as the sum total of the abstract relative sizing units of the work items (story points), or in some cases, it's simply a count of the number of work items completed.

The time that goes by between processes in a Lean Production system. For instance, time during which a work item gets shuffled around or sits around waiting for someone to work on it. See also touch time.

A user story or other work item where work has started but not enough effort has been invested in it to consider it 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. Examples include documentation without code, code without tests, and any software that has been developed but not deployed to production. It is important for teams to strive to keep the number of things they are working on simultaneously to a minimum, which is known as a low "WIP limit." For instance, a team might set a WIP limit on how many work items can be in development at the same time.

A set of ground rules that constitute protocols among teams or when working with other parties. The idea is to make sure their is clarity on what is expected, customary, and acceptance insofar as the way in which a team or other group of people work together. Examples of things that might be included: when and where a Daily Standup/Daily Scrum takes place; who fills in for a particular person when they're away; ways in which collaboration tools are used; blocks of time during which team members agree to be reachable; preferred options for fun things to do as a group.