Communication is essential to quality improvement. A common glossary of terms is critical to communication across teams. Begin with a common glossary of terms and then update them as new terms are discovered or invented.
The terms in this glossary are in common usage. They have been gathered from a number of sources including books, journals, web sites, and field experts.
| Term | Description |
| 5S | A basic Lean concept that helps to create an efficient and effective environment for work: “A place for everything and everything in its place.” Derived from five Japanese terms beginning with “s” used to create a workplace suited for visual control and lean production. 1) Seiri means to separate needed tools, parts and instructions from unneeded materials and to remove the unneeded ones. 2) Seiton means to neatly arrange and identify parts and tools for ease of use. 3) Seiso means to conduct a cleanup campaign. 4) Seiketsu means to conduct seiri, seiton and seiso daily to maintain a workplace in perfect condition. 5) Shitsuke means to form the habit of always following the first four S’s. An English equivalent might be, “Sort, Simplify, Sweep, Standardize, Sustain.” |
| Acceptance Test-Driven Development | Acceptance Test-Driven Development (ATDD) employs a test-first mindset where Business, developers, and testers work closely together to write acceptance tests before implementation begins. ATDD is very similar to Behavior Driven Development and are discussed together. |
| Acceptance Testing | Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. |
| Adaptive Management | Adaptive Management (AM), also known as Adaptive Resource Management (ARM), is a structured, iterative process of robust decision-making in the face of uncertainty, with an aim to reducing uncertainty over time via system monitoring. In this way, decision-making simultaneously meets one or more resource management objectives and, either passively or actively, accrues information needed to improve future management. Adaptive Management is a tool which should be used not only to change a system but also to learn about the system (Holling 1978). Because Adaptive Management is based on a learning process, it improves long-run management outcomes. The challenge in using the Adaptive Management approach lies in finding the correct balance between gaining knowledge to improve management in the future and achieving the best short-term outcome based on current knowledge (Allan & Stankey 2009). |
| Agile | Agile software development is a conceptual framework for undertaking software engineering projects that embraces and promotes evolutionary change throughout the entire life-cycle of the project. Scrum and XP are two software development methods based on Agile tenets. See also: Scrum, XP. |
| Backlog | A list of work to be completed that has various degrees of commitment associated with it depending upon where it is being used. There are three main backlogs in Leanban:
|
| Benchmarking | A technique in which an organization measures its performance against the performance of best-in-class organizations, determines how those organizations achieved their performance levels, and then uses the information to improve its own performance. Organizations may be internal or external to the company and may be in a different type of industry. Subjects that can be bench-marked include strategies, operations and processes. Sometimes, third-party organizations, such as the American Productivity and Quality Center, are used to conduct the benchmarks to protect confidentiality. |
| BDD | Behavior Driven Development is a method of defining the behavior required prior to doing design or implementation. It is very similar to Acceptances Test-Driven Development except that it typically is done in the Given <an event> When <a situation> Then <the desired behavior> (GWT). We discuss both together. |
| Best Practice | A superior method or innovative practice that contributes to the improved performance of an organization, usually recognized as “best” by other peers for given contexts. It is often worthwhile to focus on “good” practices rather than striving for “best” practices. |
| Brainstorming | A technique teams use to generate ideas on a particular subject. Each person on the team is asked to think creatively and write down as many ideas as possible. The ideas are reviewed after the brainstorming session. Most books on facilitation discuss the many approaches to brainstorming. |
| Bring Me a Rock | The common experience of product developers in which a customer or customer’s representative (the “Business Analyst”) tells the developer to make a product (“bring me a rock”). The developer makes a list of features about the product and proceeds to build it. When the product is finally delivered to the customer, the customer says, “That is not the rock I asked for! Go and bring me another.” Iterative methods address this problem by delivering small chunks of finished work to show customers for their approval. It reduces delay in customer feedback and allows the team to adjust to meet the true requirements. |
| Build Verification Test | A group of tests to determine the health of a build at a high level. Typically, these tests exercise the core functionality of code and help determine whether further testing is warranted. These are also known as “smoke tests.” |
| Burn-down Chart | A chart showing the rate (story points/day) at which stories or tasks are being completed. |
| Burn-up Chart | A chart showing the rate (story points/day) at which business value is growing. |
| Business | The “Business” is a short-hand for someone from another part of the organization who is not part of the technical development team but has expertise and/or responsibility for profitably addressing customers and markets. |
| Business Agility | Business agility is the quick realization of business value predictably, sustainably and with high quality. It requires the proper use of MBIs and MVPs. |
| Business Value | Business value is what drives product development. It is the measurable or intangible return the Business anticipates it can realize from the product. The Business is responsible for identifying Business value. Business value is what the Business is willing to pay for. Development work should always be traceable to Business value. |
| Cadence | The flow or rhythm of events, especially the pattern in which something is experienced. Cadence in Leanban is the rhythm of when backlogs are refreshed, work is readied for synchronization, retrospections are done, demos are presented, and teams reflect on their work. |
| Capability | The combination of people and people skills, processes, and technologies required in order to equip the Business / customer to use a product. All three are required since until the Business can begin to use a product, the product merely represents potential. |
| Code Analysis | The process of checking that code conforms to design guidelines, looking for common coding and design errors per coding standards. The team makes an agreement to conform to these coding standards; thus, code analysis serves an integrity check with how well the team is working according to their standards. |
| Code Coverage | A metric used to describe the degree to which source code has been tested. Code coverage is expressed as a percentage of lines of code tested over the total lines of code. |
| Cognitive Bias | Cognitive bias occurs when an individual see things from his own subjective view instead of seeing as it really is.
Humans automatically see the world through their own filter. When this happens in the business world risks are often not noticed nor attended to. |
| Collaboration | Collaboration benefits organizations, teams, and individuals by enabling col-leagues to work together to create new ideas from a starting point that is: uncertain, poorly understood, or innovative; adaptive or intangible; or requires change to accomplish.
Collaboration assumes that no one has the best, correct, or full answer and that the solution can only be found by exploring and synthesizing diverse points of view and using thought experiments and what-if scenarios. Collaboration is creative and the work of humans not machines. |
| Commonality / Variability Analysis (CVA) | A technique that enables developers to write code that can be easily modified later. It complements iterative development. It is described in Shalloway and Trott’s Design Patterns Explained: A New Perspective of Object-Oriented Design. |
| Constraint | Anything that limits a system from achieving higher performance or throughput; also, the bottleneck that most severely limits the organization’s ability to achieve higher performance relative to its purpose or goal. |
| Consultant | An individual who has experience and expertise in applying tools and techniques to resolve process problems and who can advise and facilitate an organization’s improvement efforts. |
| Contextually based prescription | People often need a well-defined place to start. Most frameworks provide a preset, prescriptive approach which often is not fite for purpose either due to the practices suggested, the roles defined or the culture within which it is being used. A contextually based prescription, on the other hand, is one that has been created for the situation at hand and includes helping the organization choose their way of working. |
| Continuous Process Improvement | A philosophy and attitude for analyzing capabilities and processes and improving them repeatedly to achieve customer satisfaction. Also known as Continuous Quality Improvement. |
| Cooperation | Cooperation benefits organizations, teams, and individuals by spreading the work across numerous functions, abilities, and methods (e.g., human and machine can cooperate to produce work). Cooperation assumes that the work to be done is well understood, generally predictable, and has an accepted action plan. It is about helping to execute an already determined plan. Cooperation improves efficiency. |
| Cost-Benefit Analysis | A method of project evaluation that compares the potential benefits with the anticipated costs. |
| Cost of Delay | What the cost of not getting something done by a certain point. Partly measured by what is lost by not having it. For example, if a product will achieve a revenue of $100,000 a month, then a 2 month delay costs $200,000 |
| Cross-Functional Team | Teams that have all of the capabilities to deliver the work they’ve been assigned. Team members can specialize in certain skills but as a whole, the team is capable of delivering what they’ve been called on to build. |
| Customer | The recipient of the output (product, service, information) of a process. Customers may be internal or external to the organization. The customer may be one person, a department, or a large group. Internal customers (outside of IT) are sometimes called the “Business.” |
| Customer Satisfaction | The result of delivering a product, service, or information that meets customer requirements. |
| Cycle Time | The total elapsed time to move a unit of work from the beginning to the end of a process. Cycle time includes process time, during which a unit is acted upon to bring it closer to an output, and delay time, during which a unit of work is spent waiting to take the next action. |
| Daily Stand-up | A stand-up meeting of the team where status is exchanged, progress is observed, and impediments are noted and removed. Typically, these meetings last 15 minutes. Each member answers three questions:
|
| Dashboard | A type of information radiator that provides management and teams with graphs and reports indicating progress and trends and to identify potential problems. |
| Demonstrable Product | A version of a product that can be demonstrated to customers. It may not be quite ready for release or delivery, since that usually requires additional work (such as art work and production plans). It is the primary deliverable of an iteration. |
| Design Pattern | A collection of best practices for solving problems in a recurring context. The more general term is “pattern” because patterns are involved with analysis, design, implementation, and testing. |
| Done | The criteria for accepting an MBI, feature, or story as finished. Specifying these criteria is the responsibility of the entire team, including the business. |
| Elevation | A planning chunk that helps the team plan work iterations that minimize risk, increase learning, and coordinate effectively with other teams. Given all of the work required to realize an MBI, the team defines an objective for a particular iteration or set of iterations. The elevation is what is required to achieve that objective and ensure that the resulting code integrates well and maintains technical integrity. |
| Emergent Design | Allowing a design to emerge over time, as part of the natural evolution of a system. Requires good practices and testing to ensure that the system is not inadvertently allowed to decay or become overly complex over time. See Emergent Design: The Evolutionary Nature of Professional Software Development by Scott L. Bain. |
| Error Proofing | The ability to catch errors immediately, and to take corrective action to prevent problems down the line. Four strategies for error proofing are: 1) eliminate possibility of error, 2) reduce occurrence if elimination is not possible, 3) reduce consequences of errors, 4) capture and address error early if they cannot be eliminated. |
| eXtreme Programming | See: XP. |
| Facilitator | An individual specifically trained to enable groups to work more effectively, collaborate, and achieve synergy. The facilitator is a ‘content neutral’ party; does not take sides or express or advocate a point of view during the meeting, advocates for fair, open, and inclusive procedures to accomplish the group’s work. |
| Feature | A feature is a business function that the product carries out. Features are large and chunky and could be implemented by using many stories. Features may be functional or non-functional. Features form a basis for organizing stories. |
| FIT | Framework for Integrated Test |
| Functional Test | The activity that validates a feature against customer requirements. Functional tests are usually done by a tester as part of the customer team. |
| Gemba | The “Gemba” is the place where value-added work is actually being done: a work cell, the developer team room, the help desk, the customer’s office. Management must go to these locations to observe, evaluate, coach, and engage with the team. This is in contrast to management practices that rely on management hierarchies, team leads or formal status meetings in conference rooms or management offices. |
| Happy Path | The basic course of action through a single use case. |
| Harness Tests | A group of test scenarios with expected outcomes related to a specific system module to confirm that defects have not been introduced as a result of current iteration programming activity. For example, a pricing test harness would confirm no defects from current pricing module programming. |
| Impediment | A technical, personal, or organizational issue that is preventing or delay in progress on delivering product. |
| Information Radiator | A type of visual control that displays information in a place where passersby can see it and get information about the project without having to ask questions. To be effective, the information must be current and must be easy to see and understand, with sufficient detail to explain status. |
| Intangible | Intangible metrics and deliverables are indirect drivers of change. For example, culture, leadership, behaviors, mental models, assumptions, teaming dynamics, social physics, and the ability to work on the organization. Intangible drivers of change are used to positively impact technical delivery and, when ignored, often have a negative impact on technical delivery and results. |
| Integration System Test | The activity that verifies that software code does not harm other parts of the software product. . Preferably, Integration system testing is done by a tester with automated tools. |
| Inventory | Work items that have been started but not completed. |
| Iteration | A time-boxed period during which the team is focused on producing a demonstrable product, some amount of functionality that is ready to be shown to the customer and potentially ready to be delivered. Usually, iterations are 2-4 weeks long. In Scrum, an iteration is called a “sprint.” |
| Iteration Plan | The list of user stories for the upcoming iteration. |
| Iteration Planning | The activity to prioritize and identify the stories and concrete tasks for the next iteration. Also known as “loading the front burner.” |
| Just-in-Time Design | The process of waiting until you know what the design needs to be and then refactoring code to meet these new needs before adding the functionality that is forcing the design change. |
| Kaizen | A Japanese term that means gradual unending improvement by doing little things better and setting and achieving increasingly higher standards. Masaaki Imai made the term famous in his book, Kaizen: The Key to Japan’s Competitive Success. |
| Lean | The approach that produces value for customers quickly through a focus on reducing delays and eliminating waste which results in increased quality and lower cost. |
| Lean-Agile | An approach to software development that incorporates principles, practices, and methods from lean product development, Agile software development, design patterns, test-driven development, and Agile analysis. Net Objectives advocates by this approach for those who want to be effective in creating products at scale that add value to customers and to the business. |
| Lean-Agile Team (Team) | The whole cross-functional group comprised of persons with skills who can perform three roles – Business analysts and SMEs (requirements and validation), developers, and test. The team selects the iteration goal and specifies work results, has the right to do everything within the boundaries of the project guidelines to reach the iteration goal, and organizes itself and its work. Also known as the Agile Team, Pod, Scrum Team, Team, or a work cell. |
| Leanban | A team-level process based on Lean Thinking that incorporates Scrum and Kanban practices as appropriate. Leanban was created by Net Objectives to provide a consistent approach for all teams across an organization while still enabling it to be tailored as needed for each team using it. |
| Manual Test | A document that lists the steps that a person follows to complete a test pass. Not automated. |
| Minimum Business Increment (MBI) |
The smallest set of functionality that must be realized in order for the customer to perceive value. Among other things, this means it:
|
| Minimum Viable Replacement (MVR) | Kevin Mireles has suggested another concept that is very helpful: The Minimum Viable Replacement, the “MVR.” This covers the situation faced by many large companies who spend a significant amount of their time replacing existing software. MVRs are for the increments used to replace an existing system in segments. |
| Open-Closed Principle | Suggested by Ivar Jacobson, refined by Bertrand Meyer, and promoted by patterns, the Open-Closed Principle suggests that it is better to create designs that can accommodate change by adding to them, rather than by changing them. “Open-Closed” means we are “open to extension but closed to modification.” This is a principle, and it is impossible to follow it literally at all times, but it can guide us in refactoring as well. |
| Operating Model | An organization is a complex system for delivering value. An operating model breaks this system into components, showing how it works. It can help different participants understand the whole. It can help those making changes check that they have thought through all elements and that the whole will still work. It can help those transforming an operation coordinate all the different changes that need to happen. |
| Operational Metrics | Operational metrics are direct drivers of change and governance. Operational metrics show status across the entire program or project. There are two kinds of operational metrics:
|
| Pattern | A collection of best practices for solving problems in a recurring context, represented as collections of forces and provide a professional language for high-fidelity communication among developers. The subject of many books including Design Patterns Explained (Shalloway and Trott 2004). |
| PDCA | Plan-Do-Check-Act (PDCA) cycle is an iterative four-step problem-solving process for quality improvement. Also known as the Deming Cycle, Shewhart Cycle and Deming Wheel.
|
| Performance Test | A test that ensures the required level of performance of a product is met. This test checks both that the functionality works and that the time required to do the work is acceptable. |
| Persona | A description of the typical skills, abilities, needs, tasks, behaviors, and backgrounds of a particular set of users. As an aggregation, the persona is a fiction but is used to ensure groups of users are accounted for. |
| Planning | The activity that seeks to prioritize and define the stories and tasks for the next iteration. Also known as “loading the product backlog.” |
| Portfolio Level | The Portfolio Level includes a diverse group of stakeholders working across organizational boundaries. The Portfolio Level is responsible for identifying, priority, sizing, and sequencing work based on Business value. Roles involved in the portfolio include the Value Stream Owners, the Business and Technology Sponsors, and stakeholders. Business strategy flows into the technology organization at the Portfolio Level. |
| Practice | A practice is something we, as a community, have discovered is simply always a good thing to do. For something to be promoted as a practice, it must be truly universal (you can always do it, and everyone should do it). |
| Process | A series of actions, changes, or functions performed in the making or treatment of a product. |
| Product | A collection of tangible and intangible features that are integrated and packaged into releases that offer value to a customer or to a market. |
| Product Vision | A short statement of the vision that is driving the project, expressed in business and customer terms while taking technological enablers into consideration: Who it is for, the opportunity, its name, the key benefit and differentiators. Typically, the Product Manager provides the product vision. Sometimes called the “Project Charter.” |
| Program Increment | A larger development time-box that uses cadence and synchronization to facilitate planning, coordinate higher-level retrospectives, and aggregate work for feedback. The Program Increment is usually composed of multiple team iterations, often 4-6 team iterations. |
| Program Level | The Program Level is the center of responsibility that is focused on an application area. Work is comprised of releases, enhancements, production support, and maintenance requests. The Program Level includes cross-functional representatives including the Product Manager, Business PM, and Technology Delivery Manager who prioritize work across the value stream. This level also is responsible for program ecosystem and operational metrics. |
| Project | A collection of releases, iterations, team members, and stories that creates a product. May have defined end dates or be on-going. These may be:
|
| Quality Assurance | A role and activity that ensures integrity of the code to be released. The job of QA is to prevent defects from happening in the first place… it is not ‘merely’ to find bugs. |
| Refactor | The disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Refactoring encourages and supports incremental design and implementation, the conversion of proofs of concept and early code into more suitable, stable code
Two types of refactoring are fixing bad code and injecting better design into good code as requirements change. |
| Refactoring to the Open-Closed | The same tools and techniques that are used to clean up poor design and code (aka Legacy Refactoring) can be used to change a design just enough to allow for a clean addition or change to it. We take a design that was adequate initially, but which cannot now be changed cleanly to accommodate a new or changed requirement. Refactor until the code follows the open-closed principle, and then we integrate the new code. |
| Release | A version of a product that is released externally to customers. Releases represent the rhythm of the business and should align with defined business cycles. A release contains a combination of Minimum Business Increment that form a releasable product. A release may be internal and may be used for further testing. |
| Release Testing | The activity that validates that the product is good enough to release to customers. Release testing is typically performed by a tester and is sometimes called “Quality Assurance” (QA).
Release Testing explores the statement, “We have built something that users can use.” Often, release testing exposes requirements that fail to satisfy actual users’ needs. See also: Quality Assurance, Test. |
| Retrospection | Retrospection is the structured reflective practice to learn and improve based on what has already been done. The purpose of retrospection is to build team commitment and to transfer knowledge to the next iteration and to other teams.
Retrospections must be done at the end of every iteration. A brief version, the “After Action Review” can be done at any time, whenever there is value for the team to stop and learn based on what has been done. In fact, the AAR can be more valuable because it allows the team to change while it can still help their current work. |
| Role | The role assumed by an individual on a given project. People may serve different roles on different projects or even different iterations. Lean-Agile defines three roles:
|
| Root Cause | A factor that caused nonconformance to plan and should be permanently eliminated through process improvement. QA helps lead Root Cause Analysis. |
| Scrum | An iterative and incremental Agile software development methodology or framework for managing product development. |
| Scrum Master | The Scrum Master champions the needs of the team to the organization and for championing the needs of the organization to the team. The Scrum Master is the team’s facilitator, shepherding the team as a servant-leader by creating a positive and safe environment, improving team cohesion, being creative and focused, asking difficult questions about process aimed at challenging the team to improve, bringing issues and impediments to the team, Product Owner, or management, and helping to develop the product backlog. This goes beyond the common understanding in Scrum. For this reason, Net Objectives refers to this role as a “Team Agility Coach.” |
| SIPOC | A diagramming tool used by Six Sigma process improvement teams to identify all relevant elements (suppliers, inputs, process, outputs, customers) of a process improvement project before work begins. |
| Standard Work | Standard work is the work process agreed to by the team doing it. By ‘standard’ we do not mean imposed, nor fixed. But rather the best way to do something.
Standard work acts as a backdrop for doing our job and immediately seeing how well we are doing. Its intention is to create tension between what we’re doing and what we’re supposed to be doing. This promotes learning. |
| Story | An invitation for a conversation about requirements, features, and/or units of business value that can be estimated and tested. Stories describe work that must be done to create and deliver a feature for a product. Stories are the basic unit of communication, planning, and negotiation between the Development Team, Business Owners, and the Product Manager. |
| Story Point | The sizing metric used in the Team Estimation game. They express relative complexity for purposes of estimating how much to place into an iteration. A common approach is to use Fibonacci numbers (1,2,3,5,8, …) where 1 is low complexity, 8 is more complex) and then use Team Estimation or Planning Poker to get the team to agree on estimates. |
| Story Point Burn-up Chart | A chart showing the rate of progress the team is achieving in completing the project. It is measured as the number of story points completed per iteration and tracked toward the full project scope. Along with velocity, it visibly shows the duration and length of the current project. |
| Subject Matter Expert (SME) | A person who can speak with authority on an aspect of a project or who knows to whom to talk in order to get answers. Subject Matter Experts may represent a technology, the business, the customer, process, or any other topic of importance to the project. |
| Swarm | The activity of a teamlet that forms to complete a work item. The rules for swarming are:
|
| System Evolution | System evolution is the process of building functionality from the system perspective. That is, building one layer (e.g., database) and then another on top of it (e.g., business layer), etc. |
| Systems Thinking | Systems thinking is considering a system to be an interrelated and interdependent set of parts which is defined by its boundaries and is more than the sum of its parts (subsystems). Changing one part of the system affects other parts and the whole system, with predictable patterns of behavior. Positive growth and adaptation of a system depend upon how well the system is adjusted with its environment, and systems often exist to accomplish a common purpose (a work function) that also aids in the maintenance of the system or the operations may result in system failure. The goal of systems thinking is systematically discovering a system’s dynamics, constraints, conditions and elucidating principles (purpose, measure, methods, tools, etc.) that can be discerned and applied to systems at every level of nesting, and in every field for achieving an optimized end state through various means.
See Systems Thinking and how it can be applied to frameworks and methods. For a great overview of systems thinking watch If Russ Ackoff had given a TED Talk |
| Task | Tasks are descriptions of the actual work that an individual (or sub-team) does in order to complete a story. Typically, there are several tasks per story. Tasks have the following attributes:
|
| Team Level | The Team Level consists of individual teams responsible for producing and implementing a Business value increment, for quality assurance, and for continuous incremental improvement. Work is composed of the stories and tasks for a specific release, enhancements, production support, and maintenance requests.
The Team Level also includes shared services. |
| Teamlet | A group or sub-group of a Lean-Agile team who agree to swarm on a work item (or story or task) in order to complete the work. The teamlet must have all of the knowledge and skills required to perform the work. Teamlets are generally formed at the Daily Stand-up, when the team reviews progress that has been made, and decide what needs to be worked on next. Teamlets are fluid, forming and disbanding based on the requirements of the work items at hand. The teamlet may assign a “Story Captain” to help the teamlet stay on track. |
| Test | Automatic and manual inspections of code and process to ensure correctness and completeness. Types of tests include Unit, Integration, System, Regression, Performance, and User Acceptance (Customer Acceptance) |
| Test-Driven Development | An evolutionary approach to development. In TDD, each test is written before the functional code that makes the test pass. The goal of TDD is specification and not validation, to think through a design before code is written, to create clean code that always works. |
| Time-box | An allocated period of time allowed for getting work done. This means that we commit to completing at a certain time, typically with a certain amount of effort (people and resources). We commit to getting as much work done as possible within this time frame. |
| Unit Test | The activity that verifies that software code matches the design specifications. Typically, unit testing is performed by a developer – by the code creator or by a “buddy” – however, testers often advise developers in testing approaches. Each unit test confirms that the code accurately reflects one intention of the system. |
| Use Case | In Lean-Agile, use cases express the details for a requirement story. If the use case becomes so large that it cannot be implemented in a single iteration, then the requirement story associated with the use case can be broken down into iteration requirement stories first. Alternatively, if a use case is more abstract, it can represent several requirement stories.
Use cases should be expressed in the style of Cockburn detailed use cases. They may be white box or black box and include a main scenario, exceptions, and alternatives. Use cases can refer to business rules and data definitions. |
| User Acceptance Test (UAT) | The activity that verifies that software code matches the business intent. UAT belongs to the customer. They decide what constitutes an acceptable product. Unit tests help ensure that the acceptance tests are not about functional failures, but about the actual acceptability of the approach. Thus, UATs should not result in “it crashed” but «I would like the menus to be more descriptive.” |
| Validation | The testing activity that confirms, “you built what I asked for.” |
| Value Stream | The set of actions that take place to add value to a customer from the initial request to value realization. The value stream begins with the initial concept, moves through various stages for one or more development teams (where Agile methods begin), and on through final delivery and support.
Click on ‘Value stream’ to the left for more information on them. |
| Value Stream Owner | A person responsible for systematic management approach with immediate impact on the critical elements of a company’s value streams. Makes change happen across departmental and functional boundaries. |
| Value-Added | A term used to describe activities that transform input into a customer (internal or external) usable output. An activity on a project is value-added if it transforms the deliverables of the project in such a way that the customer recognizes the transformation and is willing to pay for it. |
| Velocity | Velocity measures how many points the team spends during an iteration. The following velocities are used in the planning game to determine how many stories the customer should give to the team to estimate for the iteration:
|
| Verification | The testing activity that confirms, “I built what I intended to.” |
| Visual Control | A visual control is a lean tool that three primary purposes:
A visual control can take many forms. Simple Kanban boards and complex product management systems are examples of visual controls. |
| Voice of Customer | The “voice of the customer” is the term used to describe the stated and unstated needs or requirements of the customer. The voice of the customer can be captured in a variety of ways: Direct discussion or interviews, surveys, focus groups, customer specifications, observation, warranty data, field reports, complaint logs, etc. |
| Waste | Any activity that consumes resources, produces no added value to the product or service a customer receives, or delays development of value. Types of waste include 1) anything that does not add customer value, 2) anything that has been started but is not in production, 3) anything that delays development, 4) extra features, 5) making the wrong thing. |
| Weighted Shortest Job First | Weighted Shortest Job First is a method of deciding what should be worked on compared to other potential items of work. It is based on a definition by Don Reinersen: WSJF = Cost of Delay / Duration. |
| Work Breakdown Structure (WBS) | The Work Breakdown Structure is “a deliverable-oriented grouping of project elements which organizes and defines the total scope of the project.” The WBS organizes work according to three primary groups:
|
| Work Cell | A cross-functional set of resources and people required to perform work in a value stream. In Lean-Agile, the preferred term for a work cell is “teamlet” because they tend to be temporary, forming to complete a particular work item. |
| XP (eXtreme Programming) | A software development methodology adhering to a very iterative and incremental approach. XP consists of a number of integrated practices for developers and management; the original twelve practices of XP include Small Releases, Acceptance Tests, On-site Customer, Sustainable Pace, Simple Design, Continuous Integration, Unit Tests, Coding Conventions, Refactoring Mercilessly, Test-Driven Development, System Metaphor, Collective Code Ownership, and Pair Programming. |
| Yesterday’s Weather | The expectation that a team will complete as many story points worth of work in the next iteration as they did in the last. Of course, this will only be true after they have done a few iterations and have hit a somewhat steady level. Typically this is after 3-4 iterations. The term comes from the fact that before weather satellites, the most accurate way to predict weather was to say it would be the same as the day before. Hence, “yesterday’s weather” means we expect what happened before |