Blog

Glossary

Help the agile community practice continuous learning.

If you have suggestions for revisions to existing terms or ideas for new terms, let us know.

 

5S: Five terms beginning with “S” used to create a clutter free workspace.

Sort – Separate needed items for those not needed.
Straighten – Arrange an appropriate location for all items.
Shine – Clean the work area.
Standardize – Establish a standard process for maintaining a clean uncluttered work area.
Systemize – Maintain the commitment to the five S’s.

Abnormal Sprint Termination: Ending a Sprint before the iteration is complete due to some exceptional situation or circumstance.  This can be done only with approved by the Product Owner and is very rare.

Activity: The task or function that when performed produce a product or service.

Agile: Culture whose norms and behaviors align with the values and principles established in the Agile Manifest for Software Development.

Agile Project Management: A project management approach also known as Agile Scrum and originally developed for the software industry.  Agile project management is an approach that delivers value early and often through rapid time-boxed iterations known as sprints.  Unlike a waterfall approach to project management, the deliverables of every Agile project sprint are proven to contribute directly to customer value creation; e.g. a fully tested unit of code, or a new form or procedure that is in place and being used.
Agile is a Lean approach to project management.

Agile Manifesto For Software Development: Set of values and principles that espouse a culture and work environment where customer satisfaction through fast delivery of value and self-organizing teams are at forefront.

Andon board: A term for a visual control device that allows anyone to see and manage the status of the value stream.

Appreciative Inquiry: An approach to bringing change to organizations that builds on the holistic history of positive stores and successes.  Appreciative inquiry engages people to link the positives of the past with the organization’s current capabilities to consciously construct a better future.

Auto-Documentation: Building into the process the ability to automatically document both the process followed and the output of that process.

Backlog: Activities held in inventory that have yet to be initiated as work-in-progress, See Product Backlog or Sprint Backlog.

Backlog Grooming: Is the process of adding new user stories to the backlog, re-prioritizing existing stories as needed, creating estimates, and deconstructing larger stories into smaller stories or tasks. Rather than grooming the backlog sporadically throughout an iteration, the team may hold a backlog grooming session once per iteration. Scrum Alliance founder Ken Schwaber recommends that teams allocate 5% of their time to revisiting and tending to the backlog.

Backlog Item: A unit of work, usually a story or a task, listed on the project backlog.

Balanced Flow: An approach to achieve continuous flow of a value stream by designing each of the roles of the value stream to statistically take the same amount of wall clock time to produce their value.  The flow is balanced by adjusting the activities and resources assigned to each role to equalize their timing.

Batch: A collection of multiple items for processing at some future step.

Bottleneck: Any point in the value stream where the capacity to produce work is less than the work ready to be performed.

Branching: In version control and software configuration management, branching is the process of duplicating objects (e.g., sources files or directory) such that the duplicates can be modified in parallel.

Burndown Chart: A report showing the sprint task hours completed by a team during an Agile sprint.  Typically, a burndown chart is updated daily.  The Y axis indicates the number of task hours remaining and the X axis indicates the time duration of the sprint.

Burnup Chart: Representation of the amount of stories completed, with points plotted on an X and Y axis that map an upward trend of work completed until reaching 100%.

Business Owners: Business Owners are a small group of management stakeholders who have the primary efficacy, governance, and ROI responsibility for the value delivered by a specific release train. Business Owners play a key role throughout the flow of value, and have particularly critical roles during Release Planning, where they participate in the management review and problem solving meeting, approve plans, and assign Business.

Cadence: Is the flow or rhythm of events or the pattern in which something is experienced. Cadence is something that Agile teams strive to achieve as it allows them to operate efficiently and sustainably within the iterative cycles that most Agile methods promote. In its simplest form, cadence allows Agile teams to focus on development and delivery of the product rather than on process. Cadence is sometimes used as a verb to mean “to give a rhythm or flow to something, for example, a work process.”

Capability: The expertise and resources necessary to produce a product or service.  Example capabilities are project management, requirements analysis, training, risk management, quality assurance, etc.

Capacity: Capacity refers to the measurement of how much work can be completed within a given, fixed time frame by estimating the number of available, productive work hours for an individual or team. To accurately estimate capacity, it is important to factor in all known variables such as meetings, holidays and vacations, as well as the effects of multi-tasking and normal administrative tasks.

Chicken: A comical reference to a person who is interested in a project such as a stakeholder, but who is not directly responsible for delivery of product.  Also, see Pig.

Constraints: Anything that limits a value stream from achieving higher performance; i.e. throughput, cycle time, quality.

Continuous Flow? A value stream that experience no wait states.  In a state of continuous flow, the work time and the service time of a value stream are identical.

Continuous Performance Improvement: An approach that engages employees in an unrelenting focus on improving the effectiveness and efficiencies of the value streams of an organization.

Cross-Functional Team: Team comprised of members with all functional skills and specialties necessary to complete a project from start to finish.

Customer: The internal or external recipient of the value produced by an upstream role of a value stream.  In Scrum, this is the Product Owner.

Customer Value: Something of work in usefulness or importance to a customer.  Sometimes used interchangeable with stakeholder value.

Cycle Time: The wall clock time necessary to complete a single item or work. For example, the cycle time to enter the data from one order is the wall clock time from when the data entry starts until it is complete.

Daily Scrum: A daily stand-up meeting held during the Sprints that is typically time-boxed to no more than 15 minutes during which the Scrum Team members report their progress to each other since the previous daily scrum and plan and synchronize their work for the day.  They also inform the ScrumMaster of any noise they have encountered.  The ScrumMaster, Team, and Product Owner may participate, other (chicken) may observe at the discretion of the Team.

DMAIC: The five stages of a cycle of continuous improvement associated with the “six sigma” approach.

Define – Identify the stakeholders, the problem, and its scope.
Measure – Establish the metrics for analyzing the problem and determining the impact of any proposed changes
Analyze – Review the collected data, establish performance gaps and variation, identify best practices
Improve – Design and develop a solution, validate and then implement the solution
Control – Establish new standards, update measurement systems, and plant to maintain and improve

Done: In Scrum, a feature is considered done as mutually agreed between the Team and Product Owner and when it conforms to an organization’s standard, conventions and guidelines.  Done is a mutually agreed state or degree of completeness of functionality. Generally, 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.

However, the exact criteria for what constitutes “Done” varies to meet the specific needs of different organizations and initiatives. An important agile principle is to deliver (potentially) releasable software after every iteration. The definition of done is a key component of Agile project governance used to help teams comply with this principle.

Demo (Demonstration): At the end of each iteration, the development unit performs a demo of the functionality completed during the iteration. The demo is a forum for the customer to provide feedback on the product’s development to influence the evolution of the product.

DevOps: Is a philosophy of approach to software development and a set of practices that stresses communication, collaboration and close cooperation between the agile development teams and information technology professionals who are responsible for deploying and maintaining the software systems. This is accomplished, in part, by including IT/deployment/operations personnel as members of the Agile Release Train and by following a set of DevOps guidance practices.

Effectiveness: Maximizing the overall performance of a value stream.  Sometimes there is a tradeoff where increasing effectiveness cause reduced efficiency of certain individual activities.

Efficiency: Maximizing the performance of a single activity of a value stream.  Sometimes there is a tradeoff where increasing efficiency cause reduced effectiveness of the overall performance of the value stream.

Emergence: The principle that the best designs, and the best ways of working come about over time through doing the work, rather than being defined in advance.

Empirical (Control) Process:  Given variable (non-static) inputs, outputs generated are inspected frequently for acceptability and adaptation to better meet expectations in the future.  New product development typically constitutes an environment worthy of empirical control process because there is usually lower probability that repeated generation of an acceptable output, especially early in the development.  Agile development processes are empirical.

Empiricism: The principle of “inspect and adapt” which allows teams or individuals to try something out and learn from the experience by conscious reflection and change.

Epic: A large story that is too big to be completed in a single Agile sprint.  Epics are useful as placeholders for lower priority requirements in the backlog.

Estimation: The process of agreeing on a size measurement for the stories or tasks in a product backlog. On agile projects, estimation is done by the team responsible for delivering the work, usually using a planning game.

Fail-Fast: This is a strategy where experiments are deployed rapidly so that the feedback (failure or success) can be used to improve the overall system. The mindset behind this is that failing fast leads to success more quickly than failing slowly over long periods of time. For example, failure in a market may take the shape of a product that doesn’t sell as expected. Getting this product to market faster (or better: testing the market first before launching it) reveals how target audience actually receive the product.

Feature: A coherent business function or attribute of a software product or system. Features are large and chunky and usually comprise many detailed (unit) requirements. A single feature typically is implemented through many stories. Features may be functional or non-functional; they provide the basis for organizing stories.

Fibonacci Sequence: The sequence of numbers from the Hindu-Arabic numeral system by where the next number is derived by adding together the previous two.  This is often used for Story Points.

First In, First Out: The order something is taken from a queue or batch; also known as FIFO.

Five Levels of Agile Planning: The Five Levels of Planning are:

  1. Vision
  2. Roadmap
  3. Release
  4. Iteration (or Sprint)
  5. Daily

The top-level (Vision) represents the “big picture” of the overall effort. The planning at this level encompasses more strategic product information and fewer details on the product specifics. Working through to the bottom level, more details are included in the produced plans. In whole, the five levels of agile planning represent a holistic understanding of what we are building, why we are undertaking the effort and how we plan to deliver.

Flow: The movement of items of value from one role to the next in a value stream.

Four Ds (Agile): The four types of tasks that can make up an Agile story:

Discover – Gather/research information, define sprint deliverables
Develop – Create implementation plans, construct and test deliverables
Deliver – Train employees, execute plans, release deliverables
Debrief – Monitor results, adjust deliverables, closeout stories

Future State Value Stream: A snapshot view of a value stream as it might appear to an observer at some point in the future.

Impediment List: A list of events, noise, actions, or items that interfere with or impede the Team from efficiently completing its work.  The team and ScrumMaster can compile this list on an on-going basis or do so at the Sprint Retrospectives.  The ScrumMaster typically is responsible for managing this backlog.

Increment: Portion(s) of complete product functionality developed during a Sprint.  The portion(s) may or may not be able to be implemented independently of other functionality.

Innovation and Planning: SAFe provides for periodic Innovation and Planning sprints, which serve a variety of purposes, including: providing an estimating buffer for meeting objectives; a dedicated time for Inspect and Adapt and Release Planning activities; a cadence-based opportunity for innovation; time for continuing education; time for working on the technical infrastructure, tooling, and any other impediments; and time for backlog refinement.

Inspect and Adapt: Is a slogan used by the Scrum community to capture the idea of discovering over the course of a project emergent software requirements and ways to improve the overall performance of the team. It neatly captures the both the concept of empirical knowledge acquisition and feedback-loop-driven learning.

INVEST (acronym): Is an acronym that defines a simple set of rules used in creating well-formed user stories.

Independent Stories should not be dependent on other stories.

Negotiable. Stories should capture the essence of the requirement and should not represent a contract on how to solve it.

Valuable. Stories should clearly illustrate value to the customer.

Estimable. Stories should provide just enough information so they can be estimated. It is not important to know the exact way that a particular problem will be solved. It must only be understood enough to provide a high-level estimate.

Small Stories should strive to be granular enough in scope that they may be completed in as little time as possible, from a few weeks to a few days.

Testable Stories need to be understood well enough so that tests can be defined for them. An effective way to ensure testability is to define user acceptance criteria for all user stories.

Iteration: A time boxed cycle of development. In Scrum, this is called a Sprint.

Kaizen: A term for incremental improvement.  Kaizen is a people and process oriented way of thinking as opposed to problem and solution oriented thinking.

Kaizen Event: A term that refers to a short burst to identify and implement improvements to a value stream.  Lean Kaizen are typically a few days in duration.

Kanban: A term for a visual indicator that indicates when to execute an activity in a value stream.  A version of Kanban boards may also be used as information radiators to provide visibility to an Agile spring backlog and work-in-progress.

Last In, First Out: The order something is taken from a queue or batch; also known as LIFO.

Lean: An umbrella term for a powerful combination of techniques to maximize customer value while minimizing waste and achieving continuous flow through a sustainable culture of continuous improvement.  Lean is a term used in the U.S. for what was originally created as the “Toyota Production System.”  Also referred to as Lean Office, Lean Production, Lean Thinking, Lean Enterprise, etc.

Lean Startup: Is a business methodology designed to apply Lean manufacturing principles to business and product development. Lean Startup uses the scientific method to remove waste from product development, focusing on:

  • Rapid experimentation to validate or invalidate product and business ideas to develop a sustainable business
  • Enabling entrepreneurship in enterprises as a driver of innovation and new product development in uncertain times
  • A clear process for building products, measuring customer response, and learning and making decisions quickly
  • A new model of accounting and success measurement that improves innovation outcomes

Minimum Viable Product (MVP): Potentially confusing, the strict Lean Startup definition is the smallest thing we can test to enable one cycle of the build – measure – learn loop.

MoSCoW: Is a feature classification/categorization method rooted in rapid application development that is commonly utilized in agile projects. The method is intended for short, time-boxed development iterations in which the focus remains on items deemed most critical for delivery within the time-boxed period. MoSCoW is a modified acronym that represents four levels of priority classification.

Must have – These are time critical project requirements that must be delivered in order for the project not to be considered an outright failure. These are generally baseline, or critical path features.
Should have – These are also critical project level requirements; however, they are not as time critical as must have requirements.
Could Have – These are considered nice-to-have requirements. They are features that are not necessarily required for the success of the iteration or project, but would increase end-user/customer satisfaction in the completed product.
Won’t have – These are the lowest priority requirements. They are not scheduled or planned within the delivery time box.

Noise: Anything that impedes or prevents a Team Member from doing his or her job.

Nonfunctional Requirements (NFR): Describe system attributes such as security, reliability, maintainability, scalability, and usability. They can also be constraints or restrictions on the design of the system. Nonfunctional Requirements are persistent qualities and constraints, and unlike functional requirements, are typically revisited as part of the _Definition of Done_. NFRs exist at Team, Program and Portfolio Backlog levels.

Outcome: A measurable result produced by a value stream that has value a customer would pay for.

PDCA: The four stages of a cycle of continuous improvement popularized by W. Edward Deming:

Plan – Define the problem, methods to measure it, and obtain management support for future stages
Do – Do the tests and prototypes to understand the problem, establish root cause, and investigate alternatives
Check – Analyze the results of the “do” stage to determine if a solution effectively resolves the problem while breaking nothing else
Act – Fully implement the identified solution

Performance Principles: A rule or standard used to align day-to-day tactical decision making with the organization’s strategy and value statement.  Value statements establish worth; a principle is a standard for achieving that worth.  If values are the what; principles are the how.

Persona: A persona is a fictional character that is created to represent the attributes of a group of a product’s users. Personas are helpful tools to use as a guide when deciding on a product’s features, functionality or visual design. Personas allow a team to easily identify with a fictional version of the product’s end users.

Pig: A person committed to delivery of product in the project; i.e. A member of the Scrum Team.  Also, see chicken.

Planning Poker: Is a consensus-based technique for estimating, mostly used to estimate effort or relative size of tasks in software development.”

Poka Yoke: A term that means mistake proofing

Portfolio Backlog: The Portfolio Backlog is the highest-level backlog in SAFe, and serves as a holding stage for Epics that make it through the Kanban systems and await implementation. It contains the prioritized set of Business and Architectural Epics necessary to achieve market differentiation, operational efficiencies, or competitive solutions.

Product: Broadly speaking, product refers to a collection of tangible and intangible features that are integrated and packaged into software releases that offer value to a customer or to a market. The term “product” is often used in Agile software development to denote the software that is the subject of the iteration or release. As such, “product” is generally used interchangeably with other names for software release including “software release”, “system”, or “business application.”

Product Backlog (PB): An inventory of Agile project/product stories defining an improvement project stacked ranked by priority that have not yet been selected for an Agile sprint. A project backlog may include both software product related stories as well as project stories not related to a software product.

Product Owner (PO): Defines a role in an Agile project that is responsible for maintaining the product backlog.  This person represents all stakeholders to the project.  In XP, this is the Customer.

Product Vision: A product vision is a brief statement of the desired future state that would be achieved through the project initiative. The product vision may be expressed in any number of ways including financial performance, customer satisfaction, market share, functional capability, etc. The product vision is typically the responsibility of executive sponsorship and is articulated to the Agile development team by the business and by the product owner, if the team is using Scrum.

Process: Rules for performing activities. Process rules describe when an activity is to be performed, how it is performed, and what resource should be used.

Program Portfolio Management (PPM): Represents the highest-level fiduciary and content authority in a program portfolio. These responsibilities rest with the business executives who have the necessary knowledge and best understand the internal financial constraints and external market conditions for each Value Stream.

Pull System: When a downstream role of a value stream pulls work from the role or store that is directly upstream.  This is the opposite of a push system.

Push System: When the upstream role of a value stream pushes work to the role or store that is directly downstream.  This is the opposite of a pull system.

Quality: The continuous improvement of the effectiveness and efficiency of value added work, while reducing or eliminating waste or non-value added work.

Queue: A physical store for items as they wait for the next action in a value stream.

Ramp-Up Time: The wall clock time it takes from starting an activity until full productivity for that activity is reached.

Regression Test: A test completed to validate previously completed and tested code. The regression test is performed in an effort to ensure that subsequent deliveries of code segments have not corrupted previously completed code. These tests are also often performed after defects are remediated to ensure that the fixes have not corrupted any other portion of the software.

Release: A logical bundling of product functionality that is implemented into production during the life of a project.  It may comprise product built over several Sprints.

Release Burndown Chart: A visible chart to show progress towards a release.

Release Plan: A plan that incorporates the steps and tasks necessary to implement a product after an agreed amount to time, number of iteration (Sprint) and/or functionality level are achieved.

Resource: The assets of the organization including people, processes, technologies, materials, and time.

Retrospective: A session where the Team and ScrumMaster reflect on the process and make commitments to improve.

Roadmap: The road map (or product road map) is a document that further distills the product vision as defined in the product charter into a high level plan. Commonly, the roadmap will attempt to outline project work that spans one or more releases, by grouping requirements into prioritized themes and estimating the execution schedule against said themes. Additionally, roadmap is considered to be the second level in the five-level agile planning process.

Role: A self-contained collection of assigned activities performed by one or more individuals of an organization. A role is defined by its ability to complete all activities assigned to it without the need to interrupt the work and transfer ownership for any of the assigned activities to anyone else.

Sashimi: An Agile concept of delivering value in slices rather than in layers/stages.  An Agile Story is sashimi because it can be proven it is done.  It is not possible to prove that a requirements document is done.

Scaled Agile Framework (SAFe): The Scaled Agile Framework® (SAFe), also known as SAFe for Lean Enterprises, brings together values and practices from industry experts who have uncovered empirically proven approaches to increasing organizational agility. The collective framework is represented via the “Big Picture” and is packaged in a way that visualizes how Agile can manifest itself across all levels of the organization.

Scrum: A lightweight framework for managing complex projects.  Scrum is one of a number of methodologies under the Agile umbrella.  Scrum was originally developed to guide complex software projects.  Scrum delivers, incremental iterative time-boxed sprints that deliver value early and often.

Scrum of Scrums: Similar in intent to the daily scrum (or daily stand up), the scrum of scrums is a daily communication forum commonly used in larger projects utilizing multiple scrum teams. As more teams are introduced, the likelihood of intra-team impediments due to overlapping work and dependencies increases. The scrum of scrums is an effective way of managing these impediments. Typically, this meeting occurs after all of the individual team scrum meetings have been completed. An individual from each scrum team (usually the scrum master) is tasked with representing the scrum team in this meeting. The agenda of this meeting is virtually identical to that of the daily scrum, other than the three questions are modified slightly to better reflect the focus on teams.

  • What did my team accomplish yesterday?
  • What will my team commit to, or complete, today?
  • What impediments or obstacles are preventing my team from meeting its commitments?

ScrumMaster: The person responsible for properly and effectively implementing, coaching and facilitating and Scrum process, including maximizing its benefits and removing noise from the Scrum team.  A ScrumMaster facilitates communication and helps to remove impediments to sprint performance.

Scrum Team: The Product Owner, The ScrumMaster and the Development Team.

ScrumBut: The claim that a team or organization is using Scrum, but upon close examination, it is discovered that some of many of the root practices and disciplines of scrum are being avoided or ignored, either intentionally or unintentionally.  The consequence is typically lost efficiency and a sub-optimal development approach.

ScrumNot: The claim that a team or organization is using Scrum, but upon close examination, it is discovered that all of the root practices and disciplines of Scrum are being avoided or ignored, either intentionally or unintentionally.  This is not Scrum and leads to the typical loss of efficiency and a sub-optimal development approach.

Segregate Complexity: Establishing parallel branches in a value stream based on the complexity of the work performed.  Each branch can then be optimized for the complexity of work assigned.

Self-Organization: The principle that those closest to the work best know how to do the work, so set clear goals and boundaries and let them make all tactical and implementation decisions, cf. Emergence, Empiricism.

Seven Wastes: The seven categories of waste:

Transportation – Moving a resource from one place to another
Inventory – A capital outlay that has not yet produced income
Motion – Moving the entity that creates the product
Waiting – Inactive resources
Over-processing – Doing more than the customer requires
Over-production – Producing anything before it is needed
Defects – An error that requires rework

Silo: A term describing a functional area of an organization.  For example, a customer service department, that has very little communication or integration with other functional areas.  A “silo view” is the opposite of a “system-wide view.”

Six Sigma: A statistical approach for measuring variability.

Spike: A short, time-boxed piece of research, usually technical, on a single story that is intended to provide just enough information that the team can estimate the size of the story.

Sprint: A time-boxed work or cycle (typically a week, 2 weeks, or a month in duration) during which the Scrum Team works to produce (and potentially implement) the functionality and requirements selected from the Product Backlog for the particular Sprint.

Sprint Backlog: An inventory of Agile tasks that have been selected for an Agile sprint. The list of tasks created by the Scrum Team that it decides are necessary to produce the functionality or requirements selected form the Product Backlog for that Sprint.

Sprint Goal: The key focus of the work for a single sprint.

Sprint Planning Meeting (1 and 2): Sprint Planning 1 involves discussion between the Team and Product Owner wherein the Team selects the stories it feels it can complete in the upcoming Sprint.  Sprint Planning Meeting 2 is where the Team determines its tasks for the Stories and then commits to completing them to a state of done.

Sprint Review Meeting: A meeting time-boxed to no more than 4 hours held at the end of every Sprint where the team demonstrates to the Product Owner and other stakeholders what was accomplished during the Sprint.  Only completed (done) functionality should be demonstrated.

Stakeholder: Any party that has an interest in the product/service produced by an organization’s value stream.

Stakeholder Value: The worth of the stakeholder’s interest in the product/service produced by an organization’s value stream. Sometimes used interchangeably with customer value.

Story (User): Based upon the story concept as described in eXtreme Programming, a story point is the relative “size” of a piece of functionality based upon the effort it will take to develop it.  Can be state as a User Story (focused on user perspective) or Technical Story (focused from a technical perspective). A token representing a project or product requirement, typically state in the form:

As a <role>,
I want <business functionality>,
So that <business benefit>.

Story Points: A method for estimating the size of an Agile story used as a alternative to estimating the story in hours.  Story points compare one story to another to determine a relative size and then assign points denoting that size.  The anticipated velocity of a sprint team is then used to estimate how many story points they can deliver in a sprint.

Task: A discrete unit of work. Agile stories are broken down into a collection of tasks that must be performed to complete the story in one sprint.  Tasks are typically sized to represent 4 to 8 hours of labor.

Technical Debt: A small shortcut or omissions taken over the life of a project accumulate and cause problems down the road. It emanates from intentional, and sometimes unintentional, choices made throughout the project with the acceptance of their shortcomings, which will have to be recovered at some point to assure a quality product is delivered.

The Three C’s: “Card, Conversation, Confirmation”; this formula (from Ron Jeffries) captures the components of a User Story:

a “Card” (or often a Post-It note), a physical token giving tangible and durable form to what would otherwise only be an abstraction
a “Conversation” taking place at different time and places during a project between the various people concerned by a given feature of a software product: customers, users, developers, testers; this conversation is largely verbal but most often supplemented by documentation;
the “Confirmation”, finally, the more formal the better, that the objectives the conversation revolved around have been reached.

Theme: A collection of Agile stories that have a common affinity.

Theory of Constraints: Streamline operations by focusing on end-to-end throughput effectiveness, not individual efficiency.  Seeks to identify bottlenecks and provide alternatives for their elimination.

Time-Boxed: There are three constraints of any project: cost, scope, and time.  A time-boxed project fixes time and allows cost and scope to vary to meet the time.  An Agile project is delivered in time-boxed iterations that are fixed in calendar time.

User Experience (UX): While Agile Teams have the full responsibility for implementing the code, including the user interface (UI) elements, the User Experience designer works at the Program Level to provide cross-component and cross-program design guidance so as to provide a consistent user experience across the components and systems of the solution.

Value: Something of worthy in usefulness or importance to the possessor.  Note that value is determined by the recipient of the product/service not the producer.

Value Stream: A holistic collection of value added and non-value added activities that are chained together to create customer value in terms of a product or service.

Velocity: The amount of functionality that a Scrum Team can achieve in a Sprint based upon story points.  Referred to as a historical measure of the number of story points a team completes in a sprint.

Vision Statement: A high-level description of a project which includes who it is for, why it is necessary and what differentiates it from similar products.

Voice of the Customer: A principle of ensuring that the “real” customers’ requirements have been solicited and are well understood.  The voice of the customer informs and determines the specification and qualities of the product.

Wall Clock Time: The continuous measure of time between two milestone events.

Waste: Anything that does not add to or support the creation of customer value.  Note that waste is determined by the recipient of the product/service not the producer.

Waterfall Project Management: An approach to project management named by the discrete gate handoff from one project stage to the next.  Typically, waterfall stages are requirements, design, development, test, implement.

Work-In-Progress: Assets of a product or service that are currently in work and not yet completed. For example; batch of sales orders that are waiting in a queue to be processed are work-in-progress.

Work: The execution of activities that consume resources and product a product or service.

Workspace: The area where stakeholder value is created. The workspace is an important concept in Lean process improvement because it is the location where customer value is created.

XP: An Agile based development process created by Kent Beck in 1996 where the focus tends to be on engineering practices. Scrum and XP are often used together.

Leave a Comment

Your email address will not be published. Required fields are marked *