The SBOK® Guide is now available for download in English, Spanish, Portuguese, Deutsch, French, Italian, Chinese, Japanese & Arabic!
Global Accreditation Body for Scrum and Agile Certifications
SBOK® Guide - Important Terms and Concepts
| Terms | Definition |
|---|---|
| 100-Point Method | The 100-Point Method was developed by Dean Leffingwell and Don Widrig (2003). It involves giving the customer 100 points they can use to vote for the features that they feel are most important. |
| Accepted Deliverables | Deliverables which meet the User Story Acceptance Criteria are accepted by the Product Owner. These are considered Accepted Deliverables that may be released to the customer if they so desire. |
| Actionable Escalations | The Scrum Guidance Body may determine that some company policies do not allow teams to get the maximum benefits from the application of Scrum. In such a case, an escalation needs to be triggered in order to get approval for a policy change. |
| Adaptation | Adaptation happens as the Scrum Core Team and Stakeholder(s) learn through transparency and inspection and then adapt by making improvements in the work they do. |
| Affinity Estimation | Affinity Estimation is a technique used to quickly estimate a large number of User Stories using categories. The categories can be small, medium, or large, or they may be numbered using story point values to indicate relative size. Some key benefits of this approach are that the process is very transparent, visible to everyone, and is easy to conduct. |
| Agreed Actionable Improvements | Agreed Actionable Improvements are the primary output of the Retrospect Sprint process. They are the list of actionable items that the team has come up with to address problems and improve processes in order to enhance their performance in future Sprints. |
| Approved Change Requests | Approved Change Requests are changes that have been approved to be included in the Prioritized Product Backlog. At times, Approved Change Requests may originate from the program or portfolio managers and would be inputs to be added to the list of approved project changes for implementation in future Sprints. |
| Assertive Leader | Assertive leaders confront issues and display confidence to establish authority with respect. |
| Assessments/Benchmarking Results | Assessment/benchmarking help set a minimum standard when creating a product or service and lead to changed Done Criteria. Sometimes they may also provide impetus for a Program or Portfolio Product Owner to develop new User Stories to implement the best practices. |
| Assigned Action Items and Due Dates | Once the Agreed Actionable Improvements have been elaborated and refined, action items to implement the improvements may be considered by the Scrum Team. Each action item will have a defined due date for completion. |
| Autocratic Leader | Autocratic leaders make decisions on their own, allowing team members little, if any involvement or discussion before a decision is made. This leadership style should only be used on rare occasions. |
| Automated Software Tools | Automated Software Tools are software tools used for scheduling, information collection, and distribution. |
| Better Team Coordination | The Scrum of Scrums Meeting facilitates coordination of work across multiple Scrum Teams. This is especially important when there are tasks involving inter-team dependencies. Incompatibilities and discrepancies between the work and deliverables of different teams are quickly exposed. This forum also gives teams the opportunity to showcase their achievements and give feedback to other teams. |
| Benchmarking | An enterprise should benchmark its own practices against other companies regularly in order to keep up with the competition. Benchmarking is the process of comparing an organization’s business processes and performance metrics to those of leading companies in the same or other industries. |
| Brainstorming | Sessions where relevant stakeholders and members of the Scrum Core Team openly share ideas through discussions and knowledge sharing sessions, which are normally conducted by a facilitator. |
| Business Justification | Business Justification demonstrates the reasons for undertaking a project. It answers the question "Why is this project needed?" Business justification drives all decision making related to a project. |
| Business Needs | Business needs are those business outcomes that the project is expected to fulfill, as documented in the Project Vision Statement. |
| Business Requirements | Business Requirements define what must be delivered to fulfill business needs and provide value to stakeholders. The sum of all the insights gained through various tools such as user or customer interviews, questionnaires, JAD sessions, Gap Analysis, SWOT Analysis, and other meetings, helps get a better perspective about the business requirements and helps in creating the Prioritized Product Backlog. |
| Business Stakeholders | Business stakeholders are considered as non-core roles in a Scrum project. Business stakeholders include sponsors, users, and customers. |
| Change Request(s) | Request for changes are usually submitted as Change Requests. Change Requests remain in an unapproved status until they are formally approved. |
| Chief Product Owner | In the case of large projects, the Chief Product Owner prepares and maintains the overall Prioritized Product Backlog for the project. He or she coordinates work among the Product Owners of the Scrum Teams. The Product Owners, in turn, manage their respective parts of the Prioritized Product Backlog. |
| Chief Scrum Master | In case of large projects, the Chief Scrum Master is responsible for moderating the Scrum of Scrums (SoS) Meeting and removing impediments that affect multiple teams. |
| Coaching/Supportive Leader | Coaching and supportive leaders issue instructions and then support and monitor team members through listening, assisting, encouraging, and presenting a positive outlook during times of uncertainty. |
| Collaboration | Collaboration in Scrum refers to the Scrum Core Team working together and interfacing with the stakeholders to create and validate the deliverables of the project to meet the goals outlined in the Project Vision. Collaboration occurs when a team works together to play off each other's contributions to produce something greater. |
| Collaboration Plan | Collaboration is an extremely important element in Scrum and the Collaboration Plan outlines how the various decision makers, Business stakeholders and team members engage and collaborate with each other. |
| Colocation | Colocation is having all Scrum Core Team members located in the same work place leveraging the advantages of better coordination, problem-solving, knowledge sharing, and learning. |
| Commit User Stories | In this process, the Scrum Team commits to deliver User Stories approved by the Product Owner for a Sprint. The result of this process would be Committed User Stories. |
| Communication Plan | This plan specifies the records that must be created and maintained throughout the project. A variety of methods are used to convey important project information to stakeholders. The Communication Plan defines these methods as well as who is responsible for the various communication activities. |
| Company Human Resource Plan | The company Human Resource Plan provides general information on when particular personnel will be available for various projects, programs, and portfolios. The plan also provides information about the skills and capabilities available inside the company and on plans for hiring personnel required for future efforts. |
| Company Mission | The Company Mission provides a framework for formulating the strategies of a company or organization that guides their overall decision making. |
| Company Policies | Company policies are a set of principles, rules, and guidelines formulated or adopted by an organization. Changing company policies would affect created User Stories as they have been created following existing policies. |
| Company Vision | Understanding the Company Vision helps the project keep its focus on the organization's objectives and the future potential of the company. The Product Owner can take guidance and direction from the Company Vision to create the Project Vision Statement. |
| Conduct Daily Standup | Conduct Daily Standup is a process in which a highly focused, Time-boxed meeting is conducted every day. This meeting is referred to as a Daily Standup Meeting, which is a forum for the Scrum Team to update each other on their progress and any impediments they may be facing. |
| Conduct Release Planning | In this process, the Scrum Core Team reviews the high-level User Stories in the Prioritized Product Backlog to develop a Release Planning Schedule, which is essentially a phased deployment schedule that can be shared with the Stakeholder(s). The Length of Sprints is also determined in this process. |
| Conflict Management | Conflict Management techniques are used by team members to manage any conflicts that arise during a Scrum project. Sources of conflict often include schedules, priorities, resources, reporting hierarchy, technical issues, procedures, personality, and costs. |
| Continuous Improvement | Continuous Improvement is a Scrum approach in which the team learns from experience and stakeholder engagement to constantly keep the Prioritized Product Backlog updated with any changes in requirements. |
| Continuous Value Justification | Continuous Value Justification refers to assessment of business value regularly to determine whether the justification or viability of executing the project continues to exist. |
| Core Role(s) | Core Roles are those roles which are mandatorily required for producing the product of the project, are committed to the project, and ultimately are responsible for the success of each Sprint within the project and of the project as a whole. |
| Create Deliverables | Create Deliverables is the process in which the Scrum Team works on the tasks in the Sprint Backlog to create Sprint Deliverables. |
| Create Prioritized Product Backlog | In this process, Epic(s) are refined and elaborated, then prioritized to create a Prioritized Product Backlog for the project. The Done Criteria are also established at this point. |
| Create Project Vision | In this process, the Project Business Case is reviewed to create a Project Vision Statement that will serve as the inspiration and provide focus for the entire project. The Product Owner is identified in this process. |
| Create User Stories | In this process, User Stories and their related User Story Acceptance Criteria are created. User Stories are usually written by the Product Owner and are designed to ensure that the customer's requirements are clearly depicted and can be fully understood by all Business stakeholders. |
| Cumulative Flow Diagram (CFD) | A Cumulative Flow Diagram (CFD) is a useful tool for reporting and tracking project performance. It provides a simple, visual representation of project progress at a particular point in time. It is usually used to provide a higher level status of the overall project and not daily updates for individual Sprints. |
| Customer | The Customer is an individual or the organization that acquires the project's product, service, or other result. For any organization, depending on the project, there can be both internal customers (i.e., within the same organization) or external customers (i.e., outside of the organization). |
| Customer Value-based Prioritization | Customer Value-based Prioritization places primary importance on the customer and strives to implement User Stories with the highest value first. Such high value User Stories are identified and moved to the top of the Prioritized Product Backlog. |
| Daily Standup Meeting |
The Daily Standup Meeting is a short daily meeting, Time-boxed to 15 minutes. The team members gather to report their progress by answering the following three questions:
|
| Decomposition | Decomposition is a tool whereby high-level tasks are broken down into lower level, more detailed tasks. The User Stories are decomposed into tasks by members of the Scrum Team. Prioritized Product Backlog User Stories should be sufficiently decomposed to a level that provides the Scrum Team adequate information to create deliverables from the Tasks mentioned in the Task List. |
| Delegating Leader | Delegating Leaders are involved in the majority of decision making; however, they delegate some planning and decision-making responsibilities to team members, particularly if they are competent to handle tasks. This leadership style is appropriate in situations where the leader is in tune with specific project details and when time is limited. |
| Demonstrate and Validate Sprint | In this process, the Scrum Team demonstrates the Sprint Deliverables to the Product Owner and relevant stakeholders in a Sprint Review Meeting. |
| Dependency Determination | Once the Scrum Team has selected User Stories for a given Sprint, they should then consider any dependencies, including those related to the availability of people as well as any technical dependencies. Properly documenting dependencies helps the Scrum Teams determine the relative order in which tasks should be executed to create the Sprint Deliverables. Dependencies also highlight the relationship and interaction between tasks both within the Scrum Team working on a given Sprint and with other Scrum Teams in the project. |
| Design Patterns | Design Patterns provide a formal way of recording a resolution to a design problem in a specific field of expertise. These patterns record both the process used and the actual resolution, which can later be reused to improve decision making and productivity. Develop Epic(s) "In this process, the Project Vision Statement serves as the basis for developing large, high-level, unrefined User Stories referred to as Epics. User Group Meetings may be held to Develop Epic(s)." |
| Development in Phases Contract | This contract makes funding available each month or each quarter after a release is successfully completed. It gives incentive to both customer and supplier and ensures that the monetary risk of the customer is limited to that particular time period since unsuccessful releases are not funded. |
| Directing Leader | Directing Leaders instruct team members regarding what tasks are required and when and how they should be performed. |
| Discretionary Dependencies | Discretionary Dependencies are dependencies that are placed into the workflow by choice. Typically, discretionary dependencies are determined by the Scrum Team based on past experiences or best practices in a particular field or domain. |
| Done Criteria | Done Criteria are a set of rules that are applicable to all User Stories. A clear definition of Done is critical, because it removes ambiguity from requirements and helps the team adhere to mandatory quality norms. This clear definition is used to create the Done criteria that are an output of the Create Prioritized Product Backlog process. A User Story is considered done when it is demonstrated to and approved by the Product Owner who judges it on the basis of the Done Criteria and the User Story Acceptance Criteria. |
| Earned Value Analysis | Earned Value Analysis analyzes actual project performance against planned performance at a given point in time. It measures current variances in the project's schedule and cost performance and forecasts the final cost based on the determined current performance. |
| Empirical Process Control | An Empirical Process Control model helps make decisions based on observation and experimentation rather than on detailed upfront planning. It relies on the three main ideas of transparency, inspection, and adaptation. |
| Epic(s) | Epic(s) are written in the initial stages of the project when most User Stories are high-level functionalities or product descriptions and requirements are broadly defined. They are large, unrefined User Stories in the Prioritized Product Backlog. |
| Estimate Range | Estimates for projects should be presented in ranges. Precise figures may give an impression of being highly accurate when in fact they may not be. In fact, estimates by definition are understood not to be precisely accurate. Estimate ranges should be based on the level of confidence the team has in each estimate. |
| Estimate Tasks process | In this process, the Scrum Core Team, in a Task Estimation Workshop, estimates the effort required to accomplish each task in the Task List. |
| Estimation Criteria | The primary objective of using Estimation Criteria is to maintain relative estimation sizes and minimize the need for re-estimation. Estimation Criteria can be expressed in numerous ways, with two common examples being story points and ideal time. |
| Expected Monetary Value | This is a risk assessment technique where the potential financial impact of a risk is determined based on its Expected Monetary Value (EMV). EMV is calculated by multiplying the monetary impact by the risk's probability, as approximated by the customer. |
| Explorer-Shopper-Vacationer-Prisoner (ESVP) | This is an exercise that can be conducted at the start of the Retrospect Sprint Meeting to understand the mind-set of the participants and set the tone for the meeting. Attendees are asked to anonymously indicate which best represents their outlook in the meeting. |
| External dependencies | External dependencies are those related to tasks, activities, or products that are outside the scope of the work to be executed by the Scrum Team, but are needed to complete a project task or create a project deliverable. External dependencies are usually outside the Scrum Team's control. |
| Focus Group Meetings | Focus groups assemble individuals in a guided session to provide their opinions, perceptions, or ratings of a product, service, or desired result. Focus group members have the freedom to ask questions to each other and to get clarifications on particular subjects or concepts. Through questioning, constructive criticism, and feedback, focus groups lead to a better quality product and thereby contribute to meeting the expectations of the users. |
| Form Scrum Team | The Scrum Team members are identified during this process. Normally the Product Owner has the primary responsibility of selecting team members, but he or she often does so in collaboration with the Scrum Master. |
| Forming Stage | Forming Stage is the first stage of team formation, often considered a fun stage because everything is new and the team has not yet encountered any difficulties with the project. |
| Four Questions per Team |
A set of questions asked in each Scrum of Scrums (SoS) Meeting. Each Scrum Team representative will provide updates from his or her team which are usually provided in the form of answers to four specific questions.
|
| Gap Analysis | Gap Analysis is a technique used to compare the current, actual state with some desired state and to determine how to bridge the gap between them. |
| Identify Environment | Identifying the number and types of environments needed because numerous Scrum Teams that will be starting and ending their Sprints on the same day. |
| Identify Scrum Master and Stakeholder(s) process | In this process, the Scrum Master and the stakeholders are identified using specific Selection Criteria. |
| Identify Tasks | In this process, the Committed User Stories are broken down into specific tasks and compiled into a Task List. This is done as part of the Sprint Planning Meeting. |
| Industry Standards | New industry standards or changes to existing standards need to be implemented in order to maintain a viable product or service. Therefore, related User Stories need to be included in the Prioritized Program and/or Portfolio Backlog and prioritized accordingly. |
| Impediment | An impediment is any hindrance or hurdle that reduces the productivity of the Scrum Team. |
| Implement Phase | The Implement Phase includes processes related to the execution of the tasks and activities to create a project's product. |
| Incentive and Penalty Contract | This contract is based on the agreement that the supplier will be rewarded with a financial incentive, if the project's products are delivered on time, but will incur financial penalties, if the delivery is late. |
| Incremental Delivery Contract | This contract includes inspection points at regular intervals. It helps the customer or other Business stakeholders make decisions regarding product development periodically throughout the project at each inspection point. The customer can either accept the development of the product, decide to stop the development of the product, or request product modifications. |
| Index Cards | Index cards, often described as Story Cards, are used to track the User Stories throughout the project. This increases visibility and transparency and facilitates early discovery of any problems that may arise. |
| Initiate phase | This phase is composed of the processes related to initiation of a project: Create Project Vision, Identify Scrum Master and Stakeholder(s), Form Scrum Team, Develop Epic(s), Create Prioritized Product Backlog, and Conduct Release Planning. |
| Inspection | Inspection refers to the monitoring required to follow empirical process control, to ensure that the project deliverables conforms to the requirements. |
| Internal Dependencies | Internal dependencies are those dependencies between tasks, products, or activities that are under the control of the Scrum Team and within the scope of the work to be executed by the Scrum Team. |
| Internal Rate of Return (IRR) | Internal Rate of Return (IRR) is a discount rate on an investment in which the present value of cash inflows is made equal to the present value of cash outflows for assessing a project's rate of return. When comparing projects, one with a higher IRR is typically better. |
| Issues | Issues are generally well-defined certainties that are currently happening on the project, so there is no need for conducting a probability assessment as we would for a risk. |
| Iterative Delivery | Iterative delivery is the phased delivery of value to the customer. |
| JAD Sessions | A Joint Application Design (JAD) session is a requirements gathering technique. It is a highly structured facilitated workshop which hastens the Create Project Vision process as it enables the Business Stakeholder(s) and other decision makers to come to a consensus on the scope, objectives, and other specifications of the project. |
| Joint Venture Contract | This contract is generally used when two or more parties partner to accomplish the work of a project. The parties involved in the project will both achieve some Return on Investment because the revenues or benefits generated will be shared between the parties. |
| Kano Analysis |
Kano Analysis was developed by Noriaki Kano (1984) and involves classifying features or requirements into four categories based on customer preferences:
|
| Laissez Faire Leader | A leadership style, where the team is left largely unsupervised and the leader does not interfere with their daily work activities. This often leads to a state of anarchy. |
| Large Core Team | The Large Core Team comprises the Chief Product Owner, Chief Scrum Master, Scrum Masters, Product Owners, and selected members of the Scrum Teams working on the large project |
| Length of Sprint | Based on the various inputs including business requirements and the Release Planning Schedule, the Product Owner and the Scrum Team decide on the length of the Sprints for the project. Once determined, the length of the Sprint is usually fixed for the project. Length of Sprint is the duration of the Sprints determined for a project. |
| Mandatory Dependencies | These dependencies are either inherent in the nature of the work, like a physical limitation, or may be due to contractual obligations or legal requirements. |
| Market Study | Market Study refers to the organized research, gathering, collation, and analysis of data related to customer's preferences for products. It often includes extensive data on market trends, market segmentation, and marketing processes. |
| Members Selection Criteria | Members Selection Criteria are created by business stakeholders to define the Scrum Guidance Body members, their roles and responsibilities, the number of members, and their required skills and expertise. |
| Minimum Acceptance Criteria | Minimum Acceptance Criteria are declared by the business unit. They then become part of the Acceptance Criteria for any User Story for that business unit. Any functionality defined by the business unit must satisfy these Minimum Acceptance Criteria, if it is to be accepted by the respective Product Owner. |
| Mitigated Risks | Mitigated Risks refer to the risks that are successfully addressed or mitigated by the Scrum Team during the project. |
| Monopoly Money | Monopoly Money is a technique that involves giving the customer "monopoly money" or "false money" equal to the amount of the project budget and asking them to distribute it among the User Stories under consideration. In this way, the customer prioritizes based on what they are willing to pay for each User Story. |
| MoSCoW Prioritization | The MoSCoW Prioritization scheme derives its name from the first letters of the phrases "Must have," "Should have," "Could have," and "Won't have". The labels are in decreasing order of priority with "Must have" features being those without which the product will have no value and "Won't have" features being those that, although they would be nice to have, are not necessary to be included. |
| Net Present Value (NPV) | Net Present Value (NPV) is a method used to determine the current net value of a future financial benefit, given an assumed inflation or interest rate. |
| Non-core role | "Non-core roles are those roles that are not mandatorily required for the Scrum project. They may include team members who are interested in the project but have no formal role on the project team. These individuals may interface with the team but may not be responsible for the success of the project." |
| Norming stage | The third stage of team formation when the team begins to mature, sort out their internal differences, and find solutions to work together. It is considered a period of adjustment. |
| Number of Stories | Number of Stories refers to the number of User Stories that are delivered as part of a single Sprint. It can be expressed in terms of simple count or weighted count. |
| Opportunities | Risks that are likely to have a positive impact on the project are referred to as opportunities. |
| Opportunity Cost | Opportunity cost refers to the value of the next best business option or project that was discarded in favor of the chosen project. |
| Organizational Deployment Methods | The deployment mechanisms of each organization tend to be different based on industry, target users, and positioning. Depending on the product being delivered, deployment can take place remotely or may involve the physical shipping or transition of an item. |
| Organizational Resource Matrix | The Organizational Resource Matrix is a hierarchical depiction of a combination of a functional organizational structure and a project organizational structure. Matrix organizations bring together team members for a project from different functional departments such as information technology, finance, marketing, sales, manufacturing, and other departments - and create cross-functional teams. |
| Paired Comparison | Paired Comparison is a technique where a list of all the User Stories in the Prioritized Product Backlog is prepared. Next, each User Story is taken individually and compared with the other User Stories in the list, one at a time. Each time two User Stories are compared, a decision is made regarding which of the two is more important. Through this process, a prioritized list of User Stories can be generated. |
| Pareto Analysis | This technique of assessing risk involves ranking risks by magnitude. It helps the Scrum Team address the risks in order of their potential impacts on the project. |
| PDCA/PDSA cycle | The Plan-Do-Check-Act Cycle-also known as the Deming or Shewhart Cycle-was developed by Dr. W. Edwards Deming, considered the father of modern quality control and Dr. Walter A. Shewhart. Deming later modified Plan-Do-Check-Act to Plan-Do-Study-Act (PDSA) because he felt the term "Study" emphasized analysis rather than simply inspection, as implied by the term "Check." Both Scrum and the Deming/Shewhart/PDCA Cycle are iterative methods that focus on continuous improvement. |
| Performing stage | The final stage of team formation when the team becomes its most cohesive and operates at its highest level in terms of performance. The members have evolved into an efficient team of peer professionals who are consistently productive. |
| Personas | Personas are highly detailed fictional characters, representative of the majority of users as well as other Business stakeholders who may not directly use the end product. Personas are created to identify the needs of the target user base. |
| Piloting Plan | A Piloting Plan can be used to map out a pilot deployment in detail. The scope and objectives of the deployment, the target deployment user base, a deployment schedule, transition plans, required user preparation, evaluation criteria for the deployment, and other key elements related to the deployment are specified in the Pilot Plan and shared with Business stakeholders. |
| Plan and Estimate phase | The Plan and Estimate phase consists of processes related to planning and estimating tasks, which include Create User Stories; Approve, Estimate, and Commit User Stories; Create Tasks; Estimate Tasks; and Update Sprint Backlog. |
| Planning for value | Planning for Value refers to justifying and confirming the project value. The onus for determining how value is created falls on the stakeholders (sponsor, customers, and/or users), while the Scrum Team concentrates on what is to be developed. |
| Planning Poker | Planning Poker, also called Estimation Poker, is an estimation technique which balances group thinking and individual thinking to estimate relative sizes of User Stories or the effort required to develop them. |
| Portfolio | A portfolio is a group of related programs and/or projects, with the objective to deliver business outcomes as defined in the Portfolio Vision Statement. The Prioritized Portfolio Backlog incorporates the Prioritized Program Backlogs for all the programs in the portfolio. |
| Portfolio Product Owner | The Portfolio Product Owner defines the strategic objectives and priorities for the portfolio. Portfolio Scrum Master The Portfolio Scrum Master solves problems, removes impediments, facilitates, and conducts meetings for the portfolio. |
| Portfolio Scrum Master | The Portfolio Scrum Master solves problems, removes impediments, facilitates, and conducts meetings for the portfolio. |
| Potentially Shippable Deliverables from Projects | Potentially Shippable Deliverables from projects are valuable inputs for coordination at the program or portfolio level. At the end of Sprints in projects, product increments or deliverables are completed. The User Stories included in these increments meet the Definition of Done criteria as well as their respective Acceptance Criteria. |
| Prioritization | Prioritizing can be defined as determining the order of things and separating what will be done now, from what can be done later. |
| Prioritized Product Backlog | The Prioritized Product Backlog is a single requirements document that defines the project scope by providing a prioritized list of features of the product or service to be delivered by the project. |
| Prioritized Product Backlog Review Meeting | A Product Backlog Review Meeting (also referred to as a Prioritized Product Backlog Refining Session) is a formal meeting during the Refining Prioritized Product Backlog process, which helps the Scrum Team review and gain consensus about the Prioritized Product Backlog. |
| Probability Impact Grid | A grid where Risks are assessed for probability of occurrence and for potential impact on project objectives. Generally, a numerical rating is assigned for both probability and impact independently. The two values are then multiplied to derive a risk severity score, which can be used to prioritize risks. |
| Probability Trees | Potential events are represented in a diagram with a branch for each possible outcome of the events. The probability of each outcome is indicated on the appropriate branch, and these values can be used to calculate the overall impact of risk occurrence in a project. |
| Product | The term "product" in the SBOK® Guide may refer to a product, service, or other deliverable that provides value to the customer. |
| Product Owners Collaboration Plan | The Product Owners Collaboration Plan should define how multiple Product Owners collaborate with the Chief Product Owner. |
| Prioritized Program or Portfolio Backlog Review Meetings | At the program or portfolio level, there is representation from each project in the program or from each program in the portfolio. To streamline the meeting, it is generally recommended to have only one representative from each project or program attend at the program or portfolio level. |
| Product Owner | The Product Owner is the person responsible for maximizing business value for the project. He or she is responsible for articulating customer requirements and maintaining business justification for the project. |
| Program | A program is a group of related projects, with the objective to deliver business outcomes as defined in the Program Vision Statement. The Prioritized Program Backlog incorporates the Prioritized Product Backlogs for all the projects in the program. |
| Program and Portfolio Risks | Risks related to a portfolio or program that will also impact projects that are part of the respective portfolio or program. |
| Program Product Owner | The Program Product Owner defines the strategic objectives and priorities for the program. |
| Program Scrum Master | The Program Scrum Master solves problems, removes impediments, facilitates, and conducts meetings for the program. |
| Project | A project is a collaborative enterprise to either create new products or services or to deliver results as defined in the Project Vision Statement. Projects are usually impacted by constraints of time, cost, scope, quality, people and organizational capabilities. |
| Project Benefits | Project benefits include all measurable improvements in a product, service or result which could be provided through successful completion of a project. |
| Project Budget | The project budget is a financial document which includes the cost of people, materials, and other related expenses in a project. The project budget is typically signed off by the sponsor(s) to ensure that sufficient funds are available. |
| Project Charter | A project charter is an official statement of the desired objectives and outcomes of the project. In many organizations, the project charter is the document that officially and formally authorizes the project, providing the team with written authority to begin project work. |
| Project Costs | Project costs are investment and other development costs for a project |
| Project Reasoning | "Project reasoning includes all factors which support or contribute to the need for the project, whether positive or negative, chosen or not (e.g., inadequate capacity to meet existing and forecasted demand, decrease in customer satisfaction, low profits, and legal requirements)." |
| Project Timescales | Timescales reflect the length or duration of a project. Timescales related to the business case also include the time over which the project's benefits will be realized. |
| Project Vision Meeting | A Project Vision Meeting is a meeting with the Program Business Stakeholder(s), Program Product Owner, Program Scrum Master, and Chief Product Owner. It helps identify the business context, business requirements, and Business stakeholder expectations in order to develop an effective Project Vision Statement. |
| Project Vision Statement | The key output of the Create Project Vision process is a well-structured Project Vision Statement. A good Project Vision explains the business need and what the project is intended to meet rather than how it will meet the need. |
| Proposed Non-Functional Items for Product Backlog | Non-functional requirements may not be fully defined in the early stages of the project and can surface during the Sprint Review or Retrospect Sprint Meetings. These items should be added to the Prioritized Product Backlog as they are discovered. |
| Quality | Quality is defined as the ability of the completed product or Deliverables to meet the Acceptance Criteria and achieve the business value expected by the customer. |
| Quality Assurance | Quality assurance refers to the evaluation of processes and standards that govern quality management in a project to ensure that they continue to be relevant. Quality assurance activities are carried out as part of the work. |
| Quality Control | Quality control refers to the execution of the planned quality activities by the Scrum Team in the process of creating deliverables that are potentially shippable. It also includes learning from each set of completed activities in order to achieve continuous improvement. |
| Quality Management |
Quality management in Scrum enables customers to become aware of any problems in the project early and helps them recognize if a project is going to work for them or not. Quality management in Scrum is facilitated through three interrelated activities:
|
| Quality Planning | Quality Planning refers to identification and definition of the product required from a Sprint and the project along with the Acceptance Criteria, any development methods to be followed, and the key responsibilities of Scrum Team members in regards to quality. |
| Recommended Scrum Guidance Body Improvements | As a result of planning for the large project, suggestions may be made to revise or enhance the Scrum Guidance Body Recommendations. If the Guidance Body accepts these suggestions, they will be incorporated as updates to the Scrum Guidance Body documentation. |
| Refactoring |
Refactoring is a tool specific to software projects. The aim of this technique is to improve the maintainability of the existing code and make it simpler, more concise, and more flexible. Refactoring means improving the design of the present code without changing how the code behaves. It involves the following:
|
| Refine Prioritized Product Backlog | Refine Prioritized Product Backlog is a process in which the Prioritized Product Backlog is continuously updated and maintained. Regulations Regulations include any Federal, Local, State, or industry regulations that the program or portfolio must adhere to. Sometimes, Scrum Guidance Body recommendations may need to be updated to reflect new regulations. |
| Rejected Deliverables | Rejected Deliverables are the deliverables that do not meet the defined Acceptance Criteria. A list of Rejected Deliverables is maintained and updated after each Sprint Review Meeting with any deliverables that were not accepted. |
| Rejected Updates to the Scrum Guidance Body Recommendations | Recommended Scrum Guidance Body Improvements may not always be accepted. If the recommended improvement is rejected by the Scrum Guidance Body members, feedback that shares the reason for that rejection is provided to the relevant party. |
| Relative Prioritization Ranking | Relative Prioritization Ranking is a simple listing of User Stories in order of priority. It is an effective method for determining the desired User Stories for each iteration or release of the product or service. |
| Relative Sizing/Story Points | In addition to being used for estimating cost, Story Points may also be used for estimating the overall size of a User Story or feature. This approach assigns a story point value based on an overall assessment of the size of a User Story with consideration given to risk, amount of effort required, and level of complexity. |
| Release Content | This consists of essential information about the deliverables that can assist the Customer Support Team. |
| Release Notes | Release Notes should include external or market facing shipping criteria for the product to be delivered. |
| Release Planning Schedule | A Release Planning Schedule is one of the key outputs of the Conduct Release Planning process. A Release Planning Schedule states which deliverables are to be released to the customers, along with planned intervals, and dates for releases. There may not be a release scheduled at the end of every Sprint iteration. |
| Release Planning Sessions | The major objective of Release Planning Sessions is to create a Release Plan Schedule and enable the Scrum Team to have an overview of the releases and delivery schedule for the product they are developing, so that they can align with the expectations of the Product Owner and relevant Business Stakeholder(s). |
| Release Preparation Methods | Release preparation methods are the methods used to execute the tasks identified in the Release Readiness Plan in order to get the deliverables ready to be shipped/released. |
| Release Prioritization Methods | "Release Prioritization Methods are used to develop a Release Planning Schedule. These methods are usually industry- and/or organization-specific and are usually determined by senior management in an organization." |
| Release Readiness Plan | It details the steps to be taken by relevant Scrum Teams and any other individuals to confirm that the minimum requirements for release have been met, and the product or product increment is ready for release. |
| Release Readiness Sprint | If there is a need for specific tasks to be performed to get ready for a Release and to confirm that the minimum requirements for release have been met, these tasks are performed in a Release Readiness Sprint. A Release Readiness Sprint, if required, is only done once per Release as the last Sprint prior to the Release. |
| Resolved Issues | In Scrum of Scrums Meetings, Scrum Team members have the opportunity to transparently discuss issues impacting their project. This timely discussion and resolution of issues in the Scrum of Scrums Meeting greatly improves coordination between different Scrum Teams and also reduces the need for redesign and rework. |
| Retrospect Program or Portfolio Meeting | The Retrospect Program or Portfolio Meeting is similar to the Retrospect Release Meeting but is carried out at the program or portfolio level. The major difference is that the frequency of Retrospect Program and Portfolio Meetings is much lower than that of the Retrospect Release Meetings |
| Retrospect Release | In this process, which completes the project, organizational business stakeholders and Scrum Core Team members assemble to retrospect the project and identify, document, and internalize lessons learned. Often, these lessons lead to the documentation of agreed actionable improvements, to be implemented in future projects. |
| Retrospect Release Meeting | The Retrospect Release Meeting is a meeting to determine ways in which team collaboration and effectiveness can be improved in future projects. Positives, negatives, and potential opportunities for improvement are also discussed. This meeting is not Time-boxed and may be conducted in person or in a virtual format |
| Retrospect Sprint | In this process, the Scrum Master and Scrum Team meet to discuss the lessons learned throughout the Sprint. The lessons learned are documented and can be applied to future Sprints. |
| Retrospect Sprint Log(s) | The Retrospect Sprint Log is a record of the opinions, discussions, and actionable items raised in a Retrospect Sprint Meeting. The Scrum Master may facilitate creation of this log with inputs form Scrum Core Team members |
| Retrospect Sprint Meeting | The Retrospect Sprint Meeting is Time-boxed to 4 hours for a one-month Sprint and conducted as part of the Retrospect Sprint process. The length may be scaled up or down relative to the length of the Sprint. During this meeting, the Scrum Team gets together to review and reflect on the previous Sprint in terms of the processes followed, tools employed, collaboration and communication mechanisms, and other aspects relevant to the project. |
| Return on Investment (ROI) | Return on Investment (ROI), when used for project justification, assesses the expected net income to be gained from a project. It is calculated by deducting the expected costs or investment in a project from its expected revenue and then dividing this (net profit) by the expected costs in order to get a return rate. |
| Risk | Risk is defined as an uncertain event or set of events that can affect the objectives of a project and may contribute to its success or failure. |
| Risk Assessment | Risk assessment refers to evaluating and estimating identified risks. |
| Risk Attitude | Essentially, the Risk Attitude of the Business Stakeholder(s) determines how much risk the Business Stakeholder(s) consider acceptable. This is a determining factor in when they will decide to take actions to mitigate potential adverse risks. |
| Risk Appetite | Risk appetite refers to how much uncertainty a business stakeholder or organization is willing to take on. |
| Risk Averse | Risk Averse is one of the categories of Utility Function. It refers to the Business Stakeholder being unwilling to accept a risk no matter what the anticipated benefit or opportunity. |
| Risk Breakdown Structure | In this structure, risks are grouped based on their categories or commonalities. For example, risks may be categorized as financial, technical, or safety related. |
| Risk Burndown Chart | A chart that depicts cumulative project risk severity over time. The likelihood of the various risks are plotted on top of each other to show cumulative risk on the y-axis. The initial identification and evaluation of risks and the creation of the Risk Burndown Chart are done early in the project. |
| Risk Checklists | Risk Checklists include key points to be considered while identifying risks, common risks encountered in Scrum projects, or even categories of risks that should be addressed by the team. |
| Risk communication | Risk Communication involves communicating the findings from the first four steps of Risk Management to the appropriate Business Stakeholder(s) and determining their perception regarding the uncertain events. |
| Risk Identification | Risk Identification is an important step in Risk Management which involves using various techniques to identify all potential risks. |
| Risk Meeting | Risks can be more easily prioritized by the Product Owner by calling a meeting of the Scrum Core Team and optionally inviting relevant Business Stakeholders to the meeting. |
| Risk Mitigation | Risk Mitigation is an important step in Risk Management that involves developing an appropriate strategy to deal with a risk. |
| Risk Neutral | Risk Neutral is one of the categories of Utility Function that refers to a Business stakeholder being neither risk averse nor risk seeking; any given decision is not affected by the level of uncertainty of the outcome. When two possible scenarios carry the same level of benefit, the risk neutral stakeholder will not be concerned if one scenario is riskier than the other. |
| Risk Prioritization | Risk Prioritization is an important step in Risk Management that involves prioritizing risks to be included for specific action in the Prioritized Product Backlog. |
| Risk Prompt Lists | Risk Prompt Lists are used in stimulating thoughts regarding the source from which risks may originate. Risk Prompt Lists for various industries and project types are available publicly. |
| Risk Seeking | Risk Seeking is one of the categories of Utility Function that refers to a Business stakeholder being willing to accept risk even if it delivers a marginal increase in return or benefit to the project. |
| Risk threshold | Risk Threshold refers to the level at which a risk is acceptable to the stakeholder's organization. A risk will fall above or below the risk threshold. If it is below, the Business stakeholder or organization is more likely to accept the risk. |
| Risk-Based Spike | Risk-Based Spikes are basically experiments that involve research or prototyping to better understand potential risks. In a spike, an intense two to three-day exercise is conducted (preferably at the beginning of a project before the Develop Epic(s) or Create Prioritized Product Backlog processes) to help the team determine the uncertainties that could affect the project. |
| Scope | The scope of a project is the total sum of all the product increments and the work required for developing the final product. |
| Scrum Guidance Body | The Scrum Guidance Body (SGB) is an optional role. It generally consists of a group of documents and/or a group of experts who are typically involved with defining objectives related to quality, government regulations, security, and other key organizational parameters. |
| Scrum Guidance Body Expertise | Scrum Guidance Body Expertise relates to documented rules and regulations, development guidelines, or standards, and best practices. |
| Scrum Guidance Body Meetings | The Scrum Guidance Body meets regularly to discuss the potential need for an update of the Scrum Guidance Body Recommendations (e.g., recommended improvements from Retrospectives and other processes, updated regulations, etc.). The frequency of the meetings is decided by the Scrum Guidance Body based on the specific needs of the enterprise. |
| Scrum Guidance Body Members | The Scrum Guidance Body (SGB) members can include Scrum experts, selected Scrum Masters, Product Owners and team members (on all levels). However, there should be a limit on the number of members that a SGB can have in order to ensure that it remains relevant and does not become prescriptive in nature. |
| Scrum Master | The Scrum Master is one of the Scrum Core Team roles. He or she facilitates creation of the project's deliverables, manages risks, changes, and impediments during the Conduct Daily Standup, Retrospect Sprint, and other Scrum processes. |
| Scrum Masters/Scrum Teams Collaboration Plan | The Scrum Masters/Scrum Teams Collaboration Plan defines how the numerous Scrum Masters and Scrum Teams collaborate with each other to provide highest value in the shortest possible time. |
| Scrum of Scrums Meeting | A Scrum of Scrums Meeting is an important element when scaling Scrum to large projects. Typically, there is one representative in the meeting from each Scrum Team—usually the Scrum Master—but it is also common for anyone from the Scrum Team to attend the meeting if required. This meeting is usually facilitated by the ChiefScrum Master and is intended to focus on areas of coordination and integration between the different ScrumTeams. |
| Scrum Team | The Scrum Team is one the Scrum Core Team roles. The Scrum Team works on creating the deliverables of the project and contributes to realizing business value for all Business stakeholders and the project. |
| Scrum Team Lessons Learned | The self-organizing and empowered Scrum Team is expected to learn from mistakes made during a Sprint and these lessons learned help the teams improve their performance in future Sprints. |
| Scrum Team Representatives | A representative nominated by the team to represent them in the Scrum of Scrums (SoS) Meetings based on who can best fulfill the role depending on current issues and circumstances. |
| Scrumboard | Scrumboard is a tool used by the Scrum Team to plan and track progress during each Sprint. The Scrumboard contains four columns to indicate the progress of the estimated tasks for the Sprint: a To Do column for tasks not yet started, an In Progress column for the tasks started but not yet completed, a Testing column for tasks completed but in the process of being tested, and a Done column for the tasks that have been completed and successfully tested. |
| Self-organization | Scrum practices encourage the idea that employees are self-motivated and seek to accept greater responsibility. Hence, they deliver much greater value when self-organized. |
| Shared Resources | Shared resources can include people, environment, and equipment that are needed by all or some of the Scrum Teams working on the project. In a large project, the shared resources may be limited and are needed by all or some of the Scrum Teams at the same time. |
| Ship Deliverables | In this process, Accepted Deliverables are delivered or transitioned to the relevant Business Stakeholder(s). A formal Working Deliverables Agreement documents the successful completion of the Sprint. |
| Simple Schemes | Simple Schemes involve labeling items as Priority "1", "2", "3" or "High", "Medium" and "Low" and so on. Although this is a simple and straightforward approach, it can become problematic because there is often a tendency to label everything as Priority "1" or "High". |
| Skills Requirement Matrix | The skills requirement matrix, also known as a competency framework, is used to assess skill gaps and training requirements for team members. A skills matrix maps the skills, capabilities, and interest level of team members in using those skills and capabilities on a project. Using this matrix, the organization can assess any skill gaps in team members and identify the employees who will need further training in a particular area or competency. |
| Speed Boat | Speed Boat is a technique that can be used to conduct the Retrospect Sprint Meeting. Team members play the role of the crew on a Speed Boat. The boat must reach an island, which is symbolic of the Project Vision. Sticky notes are used by the attendees to record engines and anchors. Engines are things which help them reach the island, while anchors are things that are hindering them from reaching the island. This exercise is time-boxed to a few minutes. |
| Sponsor | The sponsor is the individual or the organization that provides resources and support for the project. The sponsor is also the Business stakeholder to whom everyone is accountable to. The sponsor may be one or more individuals or an organizational group. |
| Sprint | A Sprint is a Time-boxed iteration of one to four weeks in duration during which the Scrum Team works on and creates the Sprint Deliverables. |
| Sprint Backlog | Sprint Backlog is a list of the tasks to be executed by the Scrum Team in the upcoming Sprint. |
| Sprint Burndown Chart | Sprint Burndown Chart is a graph that depicts the amount of work remaining in the ongoing Sprint. |
| Sprint Deliverables | Sprint Deliverables refer to product increments or deliverables that are completed at the end of each Sprint. |
| Sprint Planning Meeting | Sprint Planning Meeting is conducted at the beginning of a Sprint as part of the Update Sprint Backlog process. It is Time-boxed to eight hours for a one-month Sprint and is divided into two parts - Objective Definition and Task Estimation. |
| Sprint Review Meeting | The Sprint Review Meeting is time-boxed to four hours for a one-month Sprint and can be scaled according to the length of the Sprint. During the Sprint Review Meeting, the Scrum Team presents the deliverables of the current Sprint to the Product Owner, who may accept or reject the deliverables. |
| Sprint Tracking Tools | Sprint Tracking Tools are used to track the progress of a Sprint and to know where the Scrum Team stands in terms of completing the tasks in the Sprint Backlog. A variety of tools can be used to track the work in a Sprint, but one of the most common is a Scrumboard, also known as a task board or progress chart. |
| Sprint Velocity | Sprint Velocity is the rate at which the team can complete the work in a Sprint. It is usually expressed in the same units as those used for estimating, normally story points or ideal time. |
| Stakeholder Analysis | A standard stakeholder analysis is used to identify the business stakeholders on program and portfolio levels. Further details related to program or portfolio business stakeholders may be identified as personas in the Create and Refine Program or Portfolio Backlog process. |
| Storming stage | The second stage of team formation where the team begins trying to accomplish the work. However, power struggles may occur and there is often chaos or confusion among team members. |
| Story Mapping | Story Mapping is a technique to provide a visual outline of the product and its key components. Story Mapping, first formulated by Jeff Patton (2005), is commonly used to illustrate product roadmaps. Story maps depict the sequence of product development iterations and map out which features will be included in the first, second, third, and subsequent releases. |
| Supporting Leader | Supporting leaders employ listening, empathy, commitment, and insight while sharing power and authority with team members. Supporting leaders are stewards who achieve results by focusing on the needs of the team. This style is the embodiment of the Scrum Master role. |
| Sustainable Pace | Sustainable Pace is the pace at which the team can work and comfortably maintain. It translates to increased employee satisfaction, stability, and increased estimation accuracy, all of which ultimately leads to increased customer satisfaction. |
| SWOT Analysis | SWOT is a structured approach to project planning that helps evaluate the strengths, weaknesses, opportunities, and threats related to a project. This type of analysis helps identify both the internal and the external factors that could impact the project. |
| Target Customers for Release | Not every release will target all business stakeholders or users. The Business Stakeholders may choose to limit certain releases to a subset of users. The Release Plan specifies the Target Customers for the Release. |
| Task Estimation Workshop | Task Estimation Workshop enable the Scrum Team to estimate the effort required to complete a task or set of tasks and to estimate the people effort and other resources required to carry out the tasks within a given Sprint. |
| Task List | This is a comprehensive list that contains all the tasks to which the Scrum Team has committed to for the current Sprint. It contains descriptions of each task, and may also contact task estimates. |
| Task-Oriented Leader | Task-Oriented Leaders enforce task completion and adherence to deadlines. |
| Team Building Plan | Since a Scrum Team is cross-functional, each member needs to participate actively in all aspects of the project. The Scrum Master should identify potential issues that could crop up with team members and try to address them diligently in the Team Building Plan in order to maintain an effective team. |
| Team Calendar | A Team Calendar contains information regarding availability of team members including information related to employee vacation, leaves, important events, and holidays. |
| Team Expertise | Team Expertise refers to the expertise of the Scrum Team members to understand the User Stories and Tasks in the Sprint Backlog in order to create the final deliverables. Team Expertise is used to assess the inputs needed to execute the planned work of the project. |
| Team Specialization | In a large project, Team Specialization may be required. There are three dimensions of Team Specialization. The first dimension is the need for accomplishing specific tasks. The second dimension is the need for special skills of single team members. The third dimension is that there may be limitations in team flexibility. |
| Technical Debt | Technical Debt (also referred to as design debt or code debt) refers to the work that teams prioritize lower, omit, or do not complete as they work towards creating the primary deliverables associated with the project's product. Technical Debt accrues and must be paid in the future. |
| Theory X | Theory X leaders assume that employees are inherently unmotivated and will avoid work if possible, warranting an authoritarian style of management. |
| Theory Y | Theory Y leaders assume that employees are self-motivated and seek to accept greater responsibility. Theory Y involves a more participative management style. |
| Theory Z | Theory Z leaders assume that employees will focus on self-actualization when their basic necessities are met. Theory Z also involves a more participative management style. |
| Threats | Threats are risks that could affect the project in a negative manner. |
| Three Daily Questions |
Three Daily Questions used in Daily Standup Meetings which are facilitated by the Scrum Master, where each Scrum Team member provides information in the form of answers to three specific questions:
|
| Time-boxing | Time-boxing refers to setting short periods of time for work to be done. If the work undertaken remains incomplete at the end of the Time-box, it is moved into a subsequent Time-box. Time-boxes provide the structure needed for Scrum projects, which have an element of uncertainty, are dynamic in nature, and are prone to frequent changes. |
| Transparency | Transparency allows all facets of any Scrum process to be observed by anyone. Sharing all information leads to a high trust environment.s |
| Unapproved Change Requests | Request for changes are usually submitted as Change Requests. Change Requests remain unapproved until they get formally approved. |
| Updated Program Product Backlog | A Program Product Backlog that undergoes periodic refining to incorporate changes and new requirements. |
| Updated Scrum Guidance Body Membership | As a result of assessing the Scrum Guidance Body membership, new members may be included in the Scrum Guidance Body and existing members may be removed or leave the Scrum Guidance Body |
| Update Sprint Backlog | In this process, the Scrum Core Team holds Sprint Planning Meetings where the group creates a Sprint Backlog containing all tasks to be completed in the Sprint. |
| Updated Implementation Deadlines for Projects | Implementation deadlines for projects may be updated to reflect the impact of new or changed User Stories that need to modify or introduce new requirements. |
| Updated Prioritized Program or Portfolio Backlog | The Prioritized Program or Portfolio Backlog may be updated with new User Stories, new Change Requests, new identified risks, updated User Stories, or reprioritization of existing User Stories |
| User | Users are the individuals or the organization that directly uses the project's product, service, or other results. Like customers, for any organization, there can be both internal and external users. In some cases, customers and users may be the same. |
| User Group Meetings | User Group Meetings involve relevant Business Stakeholder(s), primarily users or customers of the product. They provide the Scrum Core Team with first-hand information about user expectations. This helps in formulating the Acceptance Criteria for the product and provides valuable insights for developing Epics. |
| User Stories | User Stories adhere to a specific, predefined structure and are a simplistic way of documenting the requirements and desired end-user functionality. The requirements expressed in User Stories are short, simple, and easy-to-understand statements resulting in enhanced communication among the Business stakeholders and better estimations by the team. |
| User Story Acceptance Criteria | Every User Story has associated Acceptance Criteria. User Stories are subjective, so the Acceptance Criteria provide the objectivity required for the User Story to be considered as Done or not Done during the Sprint Review providing clarity to the team on what is expected of a User Story. |
| User Story Workshops | User Story Workshops are held as part of the Develop Epic(s) process. The Scrum Master facilitates these sessions. The entire Scrum Core Team is involved and at times it is desirable to include other Business Stakeholder(s). |
| User Story Writing Expertise | The Product Owner, based on his or her interaction with the stakeholders, own business knowledge and expertise, and inputs from the team, develops User Stories that forms the initial Prioritized Product Backlog for the project. |
| Utility Function | Utility Function is a model used for measuring Business stakeholder risk preference or attitude toward risk. It defines the Business Stakeholder(s)' level or willingness to accept risk. |
| Value Stream Mapping | Value Stream Mapping uses flowcharts to illustrate the flow of information needed to complete a process and may be used to streamline a process by helping to determine non-value-adding elements. |
| Vendor | Vendors include external individuals or organizations that provide products and services that are not within the core competencies of the project organization. |
| Voice of the Customer (VOC) | The Voice of the Customer (VOC) can be referred to as the explicit and implicit requirements of the customer, which must be understood prior to the designing of a product or service. The Product Owner represents the Voice of the Customer. |
| War Room | War Room is the commonly used term to describe the location where all Scrum Team members working are located. Normally, it is designed in such a way that team members can move around freely, work, and communicate easily because they are located in close proximity to each other. |
| Wideband Delphi Technique | Wideband Delphi is a group-based estimation technique for determining how much work is involved and how long it will take to complete. Individuals within a team anonymously provide estimations for each feature and the initial estimates are then plotted on a chart. The team then discusses the factors that influenced their estimates and proceed to a second round of estimation. This process is repeated until the estimates of individuals are close to each other and a consensus for the final estimate can be reached. |
| Working Deliverables | This output is the final shippable deliverable for which the project was sanctioned. |
| Working Deliverables Agreement | Deliverables that meet the Acceptance Criteria receive formal business sign-off and approval by the customer or the sponsor. |
