Glossary Adaptive
| Term | Definition |
|---|---|
| Adaptive Approach | A development approach where requirements can be uncertain and volatile throughout the project because change is expected. |
| Agile | An iterative software development approach, expressed in a variety of methodologies, which embraces incremental delivery, flexibility, cross-functional and self-organizing teams, direct customer-developer communication and collaboration, and frequent inspection and adaptation |
| Agile Life Cycles | A life cycle that can be iterative or incremental in nature. Commonly called change-driven and applied when there is a high degree of change expected, or uncertainty present. |
| Agile Manifesto | Declaration of values and principals for Agile development including prioritizing individuals over processes and working software over extensive documentation |
| Agile Project Management | A project management framework that applies iterative or incremental development approaches, with an emphasis on value delivery and empowering the team. |
| Agile Release Planning | The approach to determine the number of iterations or sprints needed to complete a release. Included are the features that will be in each iteration or sprint that come together to make up the release. |
| Backlog | An evolving list of customer-prioritized stories, tasks, and bugs that have not been completed and are not being worked on during the current iteration |
| Backlog Item | Any story, task, or bug that has not been completed and is not being worked on during the current iteration |
| Backlog Refinement (also referred to as Backlog Grooming or Backlog Maintenance) | Continuously updating the prioritized product backlog to reflect any changes, including adding new items, removing items that are no longer appropriate, reprioritizing existing items as necessary, and refining/cleaning user stories to get them ready for planning and execution |
| Burn Chart | A graphical representation of the product work in an iteration or the project. |
| Burndown Chart | A graphical representation of the work (represented by story points for a release and hours for an iteration) remaining over time |
| Burnup Chart | A graphical representation of the work that has been completed over time plotted against the total work |
| Business Value | An abstraction that includes tangible and intangible elements associated with project, program, and portfolio management that maximize the value to the organization |
| Crystal | A family of light software development methodologies |
| Crystal Clear | A light software development methodology for small (usually 6 or 8 colocated members) teams |
| Crystal Orange | A light software development methodology for medium (usually 10-40 members) teams |
| Cumulative Flow Diagram (CFD) | A chart that displays features completed over time, in various stages of development, and those in the backlog. |
| Daily Standup | Sometimes called the daily scrum. Team meeting held on a daily basis used to share the daily reality (what you have done since the last daily scrum, what you will do until the next daily scrum, and what impediments stand in your way) and to adapt to that reality, which usually involves an immediate replanning meeting and additional meetings (based on the availability of team members, what technical debt was revealed, and other information that impacts today’s work) |
| Definition of Done DOD) | A Scrum term representing the objective criteria used to determine if a story meets internal standards/constraints |
| Definition of Ready (DOR) | A checklist the team uses to establish they have everything needed to start work on the project or product. |
| Design-the-box | An exercise in which team members create a container for the product that articulates the product’s purpose and lists its key features |
| Development Approach | The method (predictive, iterative, incremental, agile, or hybrid) utilized during the project life cycle to produce and elaborate the product, service, or result of the project. |
| Development Approach and Life Cycle Performance Domain | The performance domain that focuses on activities and functions for the project development approach, cadence, and life cycle phases. |
| DevOps | An approach that focuses on a smooth flow of work completion from development to operations. |
| Elevator Statement | The synopsis of a concept, such as the purpose of a project, which can be expressed in thirty seconds or so |
| Epic | A large story, usually undeveloped, that needs to be decomposed into smaller stories |
| Fail Fast (aka Fast Failure) | A strategy that consists of attempting something, obtaining feedback as soon as possible, and then inspecting and adapting rapidly to determine if the attempt represents a good decision; if not, the attempt is immediately aborted so that time and resources are not wasted on its continuance |
| Feature Creep | The continual increase in or unrestrained changes to software functionality |
| Fibonacci Sequence | A series of numbers that begins with 0 and 1, and then is expanded by adding the two previous numbers together: 0, 1, 1, 2, 3, 5, 8, 13… |
| Fixed Duration | An activity where the duration does not change, regardless of the people or resources applied to the activity. |
| Function Point | An estimate of the amount of business functionality in an IT system. It can be used to calculate the functional size of an application. |
| High-level (Gross) Estimates | An estimate based on relative sizing |
| Hybrid Approach | A project approach that utilizes two or more agile and non-agile elements that results in a non-agile outcome. |
| Ideal Days/Hours | A unit of time (in days or hours) exclusively allocated to a given task, that is a unit of time where no other work is performed or interruptions occur |
| Ideal Time | A unit of time exclusively allocated to a given task, i.e., a unit of time where no other work is performed or interruptions occur |
| Impediment | Anything that prevents the team from working efficiently and effectively |
| Incremental Approach | An adaptive development approach where deliverables are created over time with functionality added until the functionality is determined complete. |
| Incremental Life Cycle | The progression of project phases characterized by an early determination of scope, the adjustment of time and cost estimates as the team learns more about the product, and an increase in functionality resulting from incremental delivery |
| Interdependent Stories | User stories that, considered together, solve a problem |
| Information Radiator | A wall in the common workspace that contains highly visible, graphic representations of progress |
| INVEST | An acronym that stands for the rules that define a user story (Independent, Negotiable, Valuable, Estimable, Small, and Testable) |
| Iteration | A timebox cycle to create a product or deliverable where all the work is completed. |
| Iteration 0 (Zero) | Iteration 0 sets the stage for Iteration 1 and beyond by ensuring that the vision statements for the project and release have been prepared, the features in the product backlog have been prioritized and estimated; the stories have been decomposed, the length of the iteration has been set; the team is adequately staffed, the team is co-located, the definition of done is established, the team environment is acceptable, and the architecture has been determined |
| Iteration Plan | The work plan for the current iteration. |
| Iteration Planning | A planning meeting that includes backlog items, acceptance criteria, and work estimates to complete the iteration. In scrum, commonly called a sprint planning meeting. |
| Iteration Review | A meeting held at the end of an iteration to review the work completed during that iteration. In scrum, called a retrospective. |
| Iterative Approach | A development approach that begins with a simple implementation, then expands by adding features until the final deliverable, or outcome is complete. |
| Iterative Life Cycle | The progression of project phases characterized by the development of scope details one iteration at a time, the adjustment of time and cost estimates as the team learns more about the product, and an increase in functionality resulting from iterative development |
| Joint application development (JAD) | A method that involves the product owner/customer or user in the design and development of the product |
| kanban | Signal cards used in manufacturing to assist flow; used to indicate when new work can be pulled into the flow and when there is a stoppage in flow |
| Kanban Board | A visual tool that shows work in progress to identify bottlenecks and overallocations, so that the team can optimize the workflow. |
| Kano Analysis | A model for customer satisfaction that categorizes features as Must Haves, Linear (the more, the better), Exciters/Delighters, or Dissatisfiers |
| Lean | A methodology that emphasizes the elimination of waste, producing only what is valuable to the customer |
| Lean Startup Canvas | A one-page template to communicate the business plan to key stakeholders as effectively as possible. |
| Life Cycle | The phases of a project associated with the work of the project, as opposed to being associated with its project management |
| Life Cycle Assessment (LCA) | An approach to assess the complete environmental impact of a product, process, or system. |
| Lost Iteration | An iteration that does not result in a deliverable |
| Nebulous Units of Time (NUTs) | An alternative term for story points |
| Pair Programming | An eXtreme programming practice that pairs two programmers at one station, typically with one programmer coding (driver) and one reviewing (navigator); an excellent cross-training device |
| Planning Poker | A game played with cards representing tasks that uses Delphi, a method where each team member estimates the size of a task and after a series of discussions, the team arrives at a consensus for task size estimation |
| Product Analysis | An approach used to convert a business-defined product into project deliverables; typically involves asking business representatives questions about the intended uses and characteristics of the product |
| Product Backlog | An evolving list of customer-prioritized features, bugs, technical work, and knowledge acquisition that have not been completed and are not being worked on during the current iteration |
| Product Box Exercise | A technique to help facilitate product requirements gathering and understanding by building a sample box with name, features, and other relevant details. |
| Product Breakdown Structure | A hierarchical structure that shows a product's components and deliverables. |
| Product Life Cycle | The phases of product development, typically defined as conception through delivery, expansion, maturity, and disengagement |
| Product Roadmap | The description of how the project will proceed from its current state to the state described in the vision statement |
| Progressive Elaboration | The iterative process of increasing the level of detail in accordance with the increase in information discovery and estimation accuracy |
| Project Vision Statement | A document that defines the goal of the project, typically referencing the target customer, the need or opportunity, and the key benefit; often includes the main alternative to the project and why the project goal is more desirable |
| Relative Estimation | Assessing the size and complexity of a story by comparing it to previously assessed stories |
| Release | A deployable software package that incorporates several iterations |
| Release Management | Activities performed to ensure that the software is ready for release to the customer |
| Release Plan | A plan that defines iterations, dates and features or outcomes to be delivered over multiple iterations. |
| Release Planning | Defining the prioritized and estimated stories from the product backlog that will be developed in the release and determining the date of the release |
| Roadmap | A document that contains the high-level plan of the features that will be developed during the next few releases; the product owner/customer owns and maintain the document |
| Rolling Wave Planning | Preparing in more detail as the project becomes clearer |
| Scrum | An Agile methodology that delivers finished increments of a product at the end of each Sprint (a timeboxed iteration with a duration of one to four weeks) |
| Scrum of Scrums | A planning forum used in multiple-team projects to coordinate resources and dependencies |
| Scrum Values | Openness, focus, commitment, courage, visibility, and humor |
| Spike | A short, timeboxed research effort that is necessary to estimate the size of a specific story, usually a technical story |
| Sprint | An abbreviated development cycle (typically 30 days) that results in potentially shippable product |
| Sprint Backlog | The list of stories scheduled for the current iteration |
| Sprint Planning | A meeting between the product owner and the team to prioritize and identify stories for the next Sprint |
| Sprint Retrospective Meeting | A meeting held at the end of each Sprint in which the ScrumMaster and the team discuss what went well and what could be improved during the next Sprint; part of the inspect and adapt philosophy |
| Sprint Review | An informal meeting at the end of the Sprint to demonstrate to the product owner what was accomplished during the Sprint |
| Story Map | A graphical model for the team to see all the features and functions with a product, so they know what they are building and why they are building it. |
| Story Point | A measurement that defines the size and complexity of a story/user story relative to a previously estimated story/user story |
| Storyboarding | A prototype method that uses graphics or images to show how a process or outcome should flow, and how the product, service, or application should work when complete. |
| Tailoring | The determination of the conglomeration of processes, inputs, tools, techniques, outputs, and life cycle phases appropriate to the management of a project. |
| Task (Agile) | A decomposed portion of a story/user story |
| Task board | A surface upon which tasks written on cards are grouped under their user stories and pinned in priority order; used to track the progress of the project |
| Technical Debt | An obligation incurred as a result of an opportunistic design or architectural approach which results in complexity and increased costs in the long term; can also refer to code that will be difficult to maintain as a result of ignoring the definition of done, writing poor code, or writing poor tests |
| Timebox | A fixed duration of time that cannot be expanded |
| User Story | A document describing a unit of functionality written in business language that is used as the basis of conversation between the product owner/customer and the team to elicit functionality details; a user story is independent, negotiable, valuable, estimable, small, and testable |
| Value Delivery System | Tasks associated with building, sustaining, and evolving an organization with project and product work. |
| Value Proposition | The reasoning behind why an organization does or should do something. |
| Velocity | The rate at which stories are completed during an iteration, typically measured in story points; also known as team velocity |
| Velocity Chart | A chart that shows the rate (typically in points) that deliverables are produced, tested, and accepted within a set time interval. |
| Vision Statement | A document that defines the goal of the project, typically referencing the target customer, the need or opportunity, and the key benefit; often includes the main alternative to the project and why the project goal is more desirable |
| Volatility | The potential for unpredictable and rapid change in a project or product environment. |
| Design-the-box | An exercise in which team members create a container for the product that articulates the product’s purpose and lists its key features |
| Elevator Statement | The synopsis of a concept, such as the purpose of a project, which can be expressed in thirty seconds or so |
| Epic | A large story, usually undeveloped, that needs to be decomposed into smaller stories |
| Fail Fast (aka Fast Failure) | A strategy that consists of attempting something, obtaining feedback as soon as possible, and then inspecting and adapting rapidly to determine if the attempt represents a good decision; if not, the attempt is immediately aborted so that time and resources are not wasted on its continuance |
| Feature Creep | The continual increase in or unrestrained changes to software functionality |
| Fibonacci Sequence | A series of numbers that begins with 0 and 1, and then is expanded by adding the two previous numbers together: 0, 1, 1, 2, 3, 5, 8, 13… |
| Fixed Duration | An activity where the duration does not change, regardless of the people or resources applied to the activity. |
| Function Point | An estimate of the amount of business functionality in an IT system. It can be used to calculate the functional size of an application. |
| High-level (Gross) Estimates | An estimate based on relative sizing |
| Interdependent Stories | User stories that, considered together, solve a problem |
| INVEST | An acronym that stands for the rules that define a user story (Independent, Negotiable, Valuable, Estimable, Small, and Testable) |
| Nebulous Units of Time (NUTs) | An alternative term for story points |
| Planning Poker | A game played with cards representing tasks that uses Delphi, a method where each team member estimates the size of a task and after a series of discussions, the team arrives at a consensus for task size estimation |
| Product Analysis | An approach used to convert a business-defined product into project deliverables; typically involves asking business representatives questions about the intended uses and characteristics of the product |
| Product Backlog | An evolving list of customer-prioritized features, bugs, technical work, and knowledge acquisition that have not been completed and are not being worked on during the current iteration |
| Product Box Exercise | A technique to help facilitate product requirements gathering and understanding by building a sample box with name, features, and other relevant details. |
| Product Breakdown Structure | A hierarchical structure that shows a product's components and deliverables. |
| Relative Estimation | Assessing the size and complexity of a story by comparing it to previously assessed stories |
| Spike | A short, timeboxed research effort that is necessary to estimate the size of a specific story, usually a technical story |
