Glossary: Lean-Agile Glossary
- 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 tols 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. Good references for 5S are in all Lean books.
- 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.
- 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 the Agile framework. See also: Scrum, XP
- Alignment
- Actions to ensure that a process or activity supports the organization’s strategy, goals and objectives.
- Analysis Story
- Work that produces other stories. An analysis story has a question to be answered. It is “done” when the answer is known. Thus, analysis stories only have one “done.” See also: Story
- Analysis Task
- Work that leads to understanding requirements and generates development tasks. See also: Task
- Anti-Pattern
- Repeated practices that appear initially to be beneficial, but ultimately result in bad consequences that outweigh the hoped-for advantages.
- Autonomation
- A form of automation in which testing environment machinery automatically inspects each item after producing it and ceases production and notifies humans if a defect is detected. In software development, automated testing is a form of autonomation. See also: Test
- Back Burner
- A collection of stories and tasks the Sprint team will work on at some point in the future. Either the Product Owner has not prioritized them or has assigned them lower priority than the stories and tasks on the front burner. Teams or organizations may use “back burner” in one of the following four ways:
• Stories or tasks that are likely to be considered in the next iteration’s planning game
• Stories or tasks that are definitely planned to be worked on in the next iteration (rather than just being available for consideration).
• Stories or tasks that are assigned to the current iteration, but are not being worked on yet. As the team has time, these will get worked on after the front burner items are done.
• In a very fluid team, the planning game may assign more stories than can be done during the iteration. The back burner consists of stories and tasks that may slip into the next iteration.See also: Backlog, Front Burner
- Backlog
- The set of stories that are not yet done. Includes both Front Burner and Back Burner stories. See also: Back Burner, Dashboard
- Baseline Measurement
- The beginning point, based on an evaluation of output over a period of time, used to determine the process parameters prior to any improvement effort; the basis against which change is measured.
- 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 benchmarked 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.
- Best Practice
- A superior method or innovative practice that contributes to the improved performance of an organization, usually recognized as best by other peer organizations. It is often better to think in terms of "good" practices.
- Bottleneck
- Any resource whose capacity is less than or equal to the demand placed on it, thus constraining flow of work or information through the process. See also: Constraint, Impediment
- 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. Commonly used in kaizens. All books on facilitation discuss the many approaches to brainstorming.
- Bug
- Anything that is a potential source of dissatisfaction with the product. Bugs may be discovered during testing or even in conversation with the Business (as a defect in requirements). Depending on the size of the bug, a team may choose to generate a story or generate a task within a "bucket" story to be able to prioritize and manage work to resolve the bug.
- Build
- The process of taking one or more input items (requirements, configurations) and creating one or more output items. Software compile and load is an example of a build. Lean-Agile urges the use of continuous builds, during which tests are automatically performed, as we aim for perfection in the code.
- 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
- The rate at which stories or tasks are being completed, measured in hours per day. See also: Burn up, Story Point, Story Point Burn up
- Burn up
- The rate at which stories or tasks are growing, measured in hours per day. See also: Burn down, Story Point, Story Point Burn up
- 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 or responsibility for what the organization does. The Product Owner is usually part of the Business.See also: Role
- Business Owner
- The Business Owner is the person who has the ultimate responsibility for funding and using the products that are being created to deliver value to the customer.
- Business Value
- Business Value is what management is willing to pay for. It is a way to identify the value of “work” or a story.
- Certified Scrum Master
- Someone who is acting in the role of ScrumMaster on a Scrum team and who has attended a "Certified Scrum Master" class to obtain Certification. This training can be applied toward a "ScrumMaster Certification by Net Objectives", but is not as comprehensive as Net Objectives Scrum Master Certification training. Net Objectives is not affiliated with the Scrum Alliance. See also: Scrum, Scrum Master
- Chain Reaction
- As described by W. Edwards Deming, the chain of events that happens in quality initiatives: improve quality, decrease costs, improve productivity, increase market with better quality and lower price, stay in business, provide jobs and provide more jobs.
- Changeset
- A logical grouping of changes. Types of changesets include "pending changesets", "shelvesets", and "committed changesets.
- Chicken
- Someone who is interested in a project but has no responsibility for working on a task in the active iteration. They may observer team meetings but cannot vote or talk. For origin, see Pig. See also: Pig
- Class diagram
- A visual and static representation of classes and the relationships between them. Typically, Class diagrams are drawn using the conventions of UML (Unified Modeling Language)
- 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 with themselves 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 descrive the degree to which source code has been tested. Code coverage is expressed as a percentage of lines of code testd over the total lines of code.
- Commonality / Variability Analysis
- Commonality / Variability Analysis is 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. See also: Bottleneck, Impediment
- 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.
- Continuous Quality Improvement
- A philosophy and attitude for analyzing capabilities and processes and improving them repeatedly to achieve customer satisfaction. Also known as CQI or CPI (Continuous Process Improvement). See also: Kaizen
- Cost-Benefit Analysis
- An examination of the relationship between the monetary cost of implementing an improvement and the monetary value of the benefits achieved by the improvement, both within the same time period.
- 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 Information Technology) are sometimes called the “Business.”
See also: SIPOC, Voice of the Customer
- 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 standup meeting of the Sprint 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:
• What did you do yesterday
• What do you plan to do today
• What is getting in your way
In the literature, often called the “Daily Scrum.”
See also: Scrum
- Dashboard
- A type of information radiator that provides management and teams with graphs and reports indicating progress and trends and to identify potential problems. See also: Backlog
- 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 (art work, production plans, etc). The “demonstrable product” is the primary deliverable from each iteration
- Design Pattern
- An incomplete label for a collection of best practices for solving problems in a recurring context. The better term is the more general term, “Pattern” because patterns are involved with analysis, design, implementation, and testing. See also: Pattern
- Design Task
- Work that applies design patterns and coding principles and practices to specify code requirements. See also: Task
- Developer
- Those members of the Sprint team who apply technical knowledge and skills to create the product. Testers may also be developers.
- Development Story
- A story focused on designing and producing code. See also: Story
- Development Story
- When a requirement story is too large for an iteration and yet cannot be decomposed into iteration requirement stories, the developers create implementation stories to describe the requirement story will be implemented. Implementation stories:
• Do not have direct business value, but support the business value of the associated requirement story
• Has acceptance tests created by the implementers
• Are estimable
• Fit within an iteration
Example: Create interface to a credit card processing system.
See also: Non-specific Implementation Story, Story
- Development Task
- Work that generates code from analysis tasks. See also: Task
- Done
- The criteria for accepting a feature as finished. Specifying these criteria is the responsibility of the entire team, including the business. There are three levels of “Done” (also known as Done-Done-Done):
• Done: Developed, runs on developer’s box
• Done: Verified by running unit tests, code review, etc
• Done: Validated as being of deliverable quality with functional tests, reviews, etc
- 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. The subject of the book Emergent Design: The Evolutionary Nature of Professional Software Development by Scott L. Bain.
- Environment Story
- How the product will work in its environment. Constraints, competition, complementary technologies. See also: Story
- Error Proofing
- The ability to catch errors immediately, and to take corrective action to prevent problems down the line. Net Objectives identifies four strategies for error proofing: 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.
- Facilitator
- An individual specifically trained to enable groups and organizations to work more effectively, to collaborate and achieve synergy. The facilitator is a ‘content neutral’ party who by not taking sides or expressing or advocating a point of view during the meeting, can advocate 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 are implemented by using many stories. Features may be functional or non-functional.
Features provide the basis for organizing stories.
- FIT
- Framework for Integrated Test. See also: Test
- Forces
- The known factors concerning problems domains, solutions, and the understood results of applying a particular solution to a given problem. We call these contextual forces (what we need to solve), implementation forces (how we solve it), and consequent forces (what we gain and lose as a result of the solution). Patterns are best understood by investigating their forces See also: Pattern
- Front Burner
- Stories or tasks that the Product Owner has made top priority for the current iteration. During the iteration, the team will focus its primary efforts on front burner stories and tasks. See also: Back Burner
- 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. See also: Test
- 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.
- Green Belt
- (Related to Six Sigma) A person who has been trained in Six Sigma methods, has completed a process improvement project satisfactorily (possibly reviewed by a panel) and who will be involved in process improvement as part of their regular job.
- 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 sprint programming activity. A pricing test harness would confirm no defects from current pricing module programming.
- Impediment
- A technical, personal, or organizational issue that is preventing progress on delivering product. See also: Bottleneck, Constraint
- 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.
- Instrument
- The process of examing the amount of time spent in each area of code
- Integration Story
- A story that describes testing the product itself. See also: Story
- Integration System Test
- The activity that verifies that software code does not harm other parts of the software product. Integration system test is usually done by a tester with automated tools. See also: Test
- Inventory
- In Lean, the money invested to purchase things and organization intends to sell.
- 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.
- Iteration Plan
- The list of user stories for the upcoming iterationSee also: Product Backlog
- 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.See also: Refactor
- 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. See also: Continuous Quality Improvement
- Lean
- Producing the maximum sellable products or services at the lowest operational cost while minimizing waste. See also: Lean-Agile
- 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. Lean-Agile is the software development approach advocated by Net Objectives for software developers who want to be effective in creating products that add value to customers and to the business. See also: Lean
- Manual Test
- A document that lists the steps that a person follows to complete a test pass. Not automated. See also: Test
- Minimal Releasable Feature Set
- The collection of features that must be released together to provide value to the customer. In the literature, sometimes called “Minimal Feature Set” or Releasable Feature Set, which are less descriptive terms. See also: Releasable Feature Set
- Non-specific Implementation Story
- Stories that are created by developers that are not tied to a particular requirement story. These stories express work that developers need to do but do not have business value on their own and do not have acceptance tests.
Example: Learn how to process payments
See also: Development Story, Story
- Open-Closed Principle
- Suggested by Ivar Jacobsen, 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. We say we are “Open to extension but closed to modification”; hence, “Open-Closed”. This is a principle, and it is impossible to follow it literally at all times, but it can guide us in refactoring as well See also: Refactoring to the Open-Closed
- Pattern
- A collection of best practices for solving problems in a recurring context. Patterns are represented as collections of Forces and provide a professional language for high-fidelity communication among developers. The subject many books including “Design Patterns Explained” by Alan Shalloway and James R. Trott.See also: Design Pattern, Forces
- PDCA
- Plan-Do-Check-Act (PDCA) cycle is an iterative four-step problem-solving process for quality improvement. Plan: development of plan to effect improvement. Do: plan is carried out. Check: effects of plan are observed. Act: results studied and learning identified for future usage. Also known as the Deming Cycle, Shewhart Cycle and Deming Wheel.
- Performance Test
- A test that ensures that 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. See also: Test
- 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.
- Pig
- Scrum slang. Someone who is responsible for doing a task on an active iteration. It comes from the joke, “a chicken and a pig talk about breakfast. The chicken says, ‘Let’s have bacon and eggs.’ The pig replies, ‘That’s fine for you. You are just making a contribution, but I have to be fully committed.” Pigs are actively involved in the project. See also: Chicken
- Planning
- The activity that seeks to prioritize and define the stories and tasks for the next iteration. Also known as “loading the Front Burner.”
- 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 Backlog
- The set of stories that are not yet done. Includes both Front Burner and Back Burner stories. See also: Iteration Plan, Work Backlog
- Product Champion
- We prefer the term Product Champion to Product Owner for several reasons.
• Product Champion comes from the Lean world and encompasses the notion that their role is to lead (champion) the team into discovering the best product available for the customer(s), be they internal or external.
• The champion creates a team of developers to best provide value to the customer. But it is still the team that is responsible.
• The champion leads, the team works with them.
• The phrase “Product Owner” has the connotation that it is the Product Owner’s responsibility to create the value for the customer. It is not. It is only their responsibility to prioritize the backlog. This requires a team effort. The person prioritizing the backlog must understand value as well as cost.
The primary Business representative who represents the “voice of the customer” and the “voice of the business” to the Sprint team. The responsibilities of the Product Owner include the following: • Manage the Vision. The Product Owner establishes, nurtures, and communicates the product vision. Achieves initial and on-going funding for the project by creating initial release plans and the initial Product Backlog. • Manage the ROI. The Product Owner monitors the project against its ROI goals and an investment vision. Updates and prioritizes the Product Backlog to ensure that the most valuable functionality is produced first and built upon. Prioritizes and refines the Product Backlog and measures success against expenses. • Manage the Release. The Product Owner makes decisions about when to create an official release. For a variety of reasons it may not be desirable to release at the conclusion of every increment. Similarly, if an official release is planned for after the fifth increment it may be released (with fewer features) after the fourth increment in order to respond to competitive moves or capture early market share. The Product Owner makes these decisions in a manner consistent with the investment vision that has been established for the project. Also known as Product Champion. See also: Product Owner
- Product Owner
- See also: Product Champion
- Product Vision
- A short statement of the vision that is driving the project, expressed in business and customer value terms. The Product Owner provides the Product Vision. Expresses who it is for, what is the opportunity, the name of the product, the key benefit, key differentiators. Sometimes called the One Big Thing or Project Charter. Tools such as the Pro Forma Press Release are helpful in creating the Product Vision.
- Project
- A collection of releases, iterations, team members, and stories that creates a product. May have defined end dates or be on-going. May be:
• All of the software a team or related teams are working on
• A specific product or product group
• A version of a company's product suite
• A specific client implementation
- Quality Assurance
- A role and activity that assures integrity, does release testing. The job of QA is to prevent defects from happening in the first place... it is NOT to find bugs. See also: Release Testing
- Refactor
- The disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Usually referred to when fixing bad code. See also: Just-In-Time Design
- 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. We refactor to create Open-Closedness, and then we integrate the new code.See also: Open-Closed Principle
- Regression Testing
- A comprehensive set of tests with expected outcomes that are run prior to release to confirm that general system functionality is defect-free as a result of development in the Sprint. See also: Test
- Releasable Feature Set
- The result of release planning is a Releasable Feature Set. Each release should provide a cohesive, coherent, and consistent set of features, so that the product is useful and provides value. See also: Minimal Releasable Feature Set
- Release
- A version of a product that is promoted for use or deployment. Releases represent the rhythm of the business and should align with defined business cycles. A release contains a combination of requirement stories and iteration requirement stories that form a releasable product. A release may be internal and 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
- Role
- The role assumed by one or more individuals on a given project. People may serve multiple roles on a project and may change roles on different projects or even on different iterations. Scrum defines three roles: the Product Champion (who represents all customers and manages the Product Backlog); the Team (a combination of Business analysts, Developers, and Testers that is self-organizing within the guidelines, standards, and conventions of the organization, and that is responsible for completing the work in iterations); and the Scrum Master (who is a facilitator for the team and product owner, responsible for coaching and ensuring that the Scrum process is used correctly, for helping to remove impediments.)
See also: Business, Scrum Master, Tester
- Root Cause
- A factor that caused nonconformance and should be permanently eliminated through process improvement.
- Scrum
- Scrum is an Agile process or framework for managing Agile projects. It is a project management process more than a methodology (the latter is rather too heavy). The Agile Alliance is a group of analysts that originally developed the Scrum processes.See also: Agile, Certified Scrum Master, Daily Stand-up, XP
- Scrum Master
- Responsible for the process and the health of the team. Ensures that the team is fully functional and productive. Enables close cooperation across all roles and functions and removes barriers. Ensures that the process is followed. Facilitates the daily scrum, iteration reviews, and planning meetings. Also spelled “ScrumMaster.”See also: Certified Scrum Master, Role
- 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. See also: Customer, Six Sigma
- Six Sigma
- A method that focuses on increasing process performance and decreasing process variation through a variety of tools. This leads to defect reduction, improved profits, and higher quality. A process is considered well-controlled when its variation is within six sigmas from the centerline in a statistical control chart. See also: SIPOC
- Spike
- A thin piece of code that tests some portion of the system. It slices narrowly across the entire system to help developers learn about the risks, issues, and limitations of the environment. Spikes help the team discover engineering, risk, or business issues that must be addressed. Spikes are usually used in the architectural phase of the system, but are not always required. The outcome of a spike is a decision, not code.
- Sprint
- The Scrum term for an “iteration.” Usually, sprints are 2-4 weeks long.
A time-boxed period during which the team is focused on producing a demonstrable product – functionality that is ready to show to a customer and potentially ready to be delivered.
See also: Sprint Planning, Swarm
- Sprint Planning
- The activity to prioritize and identify the stories and concrete tasks for the next Sprint. Also known as “loading the Front Burner.” See also: Sprint
- Sprint Team
- A cross-functional group comprised of persons with skills who can perform three roles – customer (requirements & 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 Team, an Agile team, or a work cell.See also: Swarm
- Story
- A requirement, feature, and/or unit 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 Scrum Team, Business Owners, and the Product Owner.
Stories consist of the following elements:
• A description, usually in business terms
• A size, for rough estimation purposes, generally expressed in story points (such as 1,2,3,5,8)
• An acceptance test, giving a short description of how the story will be validated
Facets of a story include:
• Business value, direct or indirect. If this cannot be estimated, then a study story is required
• Instigator of the story, a customer or developer
See also: Analysis Story, Development Story, Environment Story, Integration Story, Non-specific Implementation Story, Task
- Story Checklist
- Standard tasks that must be part of every story to be considered complete.
- Story Point
- Story points are used in the planning game. A rating given to stories to express its relative complexity for purposes of estimating how much to load in an iteration. One approach is to use Fibonacci numbers (1,2,3,5,8 where 1 is low complexity, 8 is very complex) and then use the Planning Poker exercise to get the team to agree on estimates. The team will gain experience in how much can go into each iteration.See also: Burn down, Burn up
- Story Point Burn up
- The rate of progress the team is achieving in completing the project. It is measured as number of stories completed per sprint and tracked toward the full project scope. Along with velocity, it visibly shows the duration and length of the current project.See also: Burn down, Burn up
- Subject Matter Expert
- 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 simple: 1) Teamlets focus on only one story at a time. Within a sprint, teams should have only a few stories open at a time because the focus is on burning down stories. Do not dissipate energy by focusing on too much at once. 2) The swarm is the priority. While individuals may work on other tasks, their priority should be the swarmed story. 3) Swarms are Skill-based. If you have the skills to contribute to burning down a story, and you have capacity, you are expected to join in the teamlet, even if it is not exactly in your job description to do so. See also: Sprint, Sprint Team, Teamlet
- Task
- Tasks are descriptions of the actual work that an individual (or sub-team) does in order to complete a story. They are manage-able, do-able, and track-able units of work. Typically, there are several tasks per story. Tasks have the following attributes: A description of the work to be performed, in either technical or business terms; an estimate of how much time the work will take (hours, days); an owner, who may or may not be pre-assigned; an Exit criteria and verification method (test or inspection), and an indication of who will be responsible for the verification. All tasks must be verified, not just “done” See also: Analysis Task, Design Task, Development Task, Story, Testing Task
- Teamlet
- A group or sub-group of a Scrum team who agree to swarm on a work item 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. See also: Swarm, Work Cell
- Test
- Automatic and manual inspections of code and process to ensure correctness and completeness. Types of tests include Unit Test, Integration Test, System Test, Regression Test, Performance Test, and User Acceptance (Customer Acceptance) Test. Tests may be automated or manual.
See also: Autonomation, FIT, Functional Test, Integration System Test, Manual Test, Performance Test, Regression Testing, Release Testing, Test Case, Test Result
- Test Case
- A set of conditions or variables under which a tester determines if a story or task is partially or fully satisfied. Each requirement must have at least one test case. Sometimes, both a positive test case and a negative test case should be used. See also: Test
- Test Result
- The verdict from running a test. Common attributes are Pass, Fail, Uncertain.See also: Test
- 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.
- Tester
- Those members of the Sprint team who apply testing knowledge and skills to validate and verify the product. Testers may be developers or customers and will use a combination of manual and automated methods. Testers may also act as consultants to developers to develop testing strategies. See also: Role
- Testing Task
- Work that defines validation and verification tests for stories and code. See also: Task
- 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
- 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 delivery. 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.See also: Value Stream Manager
- Value Stream Manager
- 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. See also: Value Stream
- 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 “engineering hours” 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:
• Story velocity. Story velocity measures how fast the team completes stories.
• Task velocity. Task velocity measures how many “engineering hours” the team actually can perform in an iteration.
- Verification
- The testing activity that confirms, “I built what I intended to.”
- Voice of the Customer
- The "voice of the customer" (VOC) 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. See also: Customer
- Waste
- Any activity that consumes resources and produces no added value to the product or service a customer receives. Tom and Mary Poppendieck identify waste is 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) any extra features 5) making the wrong thing. Also known as muda.
- Work Backlog
- The work backlog is a prioritized list of things that a customer wants a development team or to produce. In practice, the work backlog is a collection of stories and tasks organized by development priorities. The Work Backlog is also known as the “Product Backlog.”See also: Product Backlog
- Work Breakdown Structure
- 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:
• Product work or activities
• Environment and Team work or activities
• Business work or activities
- 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 workcell is "teamlet" because thehy tend to be temporary, forming to complete a particular work item. See also: Teamlet
- Work Item
- In some Agile development tools, a record used to track an assignment and state of work. User Stories, Features, Bugs, Tasks are all examples of work items that may be tracked.
- XP
- 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. For more information, see Jim Shore’s book, The Art of Agile Development. See also: Agile, Scrum