login

SBOK Important Terms and Concepts

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.

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.

Approve, Estimate, and Commit User Stories

In this process the Product Owner approves User Stories for a Sprint. Then, the Scrum Master and Scrum Team estimate the effort required to develop the functionality described in each User Story. Finally, the Scrum Team commits to deliver the customer requirements in the form of Approved, Estimated, and Committed User Stories.

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.

Approved, Estimated, and Committed User Stories

The User Stories which are an input to this process have high level estimates from the Create Prioritized Product Backlog and Create User Stories processes. These estimates are used by the Product Owner to approve User Stories for the Sprint. Once approved, the User Stories are estimated by the team using various estimation techniques. After estimation, the team commits to a subset of approved and estimated User Stories that they believe they can complete in the next Sprint. These User Stories are Approved, Estimated, and Committed User Stories, which will become part of the Sprint Backlog.

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.

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.

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, 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.

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 Mission

The Company Mission provides a framework for formulating the strategies of a company or organization that guides their overall decision making.

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.

Convene Scrum of Scrums

In this process the Scrum Master(s) or Scrum Team representatives convene for the Scrum of Scrums Meetings at predetermined intervals, or whenever required to collaborate and track their respective progress, impediments, and dependencies across teams.

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 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.

Create Tasks

In this process, the Approved, Estimated, and Committed User Stories are broken down into specific tasks and compiled into a Task List. Often a Task Planning Meeting is held for this purpose.

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 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: 1. What did I complete yesterday? 2. What will I complete today? 3. What impediments or obstacles (if any) am I currently facing?

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 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.

Effort Estimated Task List

The Effort Estimated Task List is a list of tasks associated with the committed User Stories included in a Sprint. Estimated effort is expressed in terms of the estimation criteria agreed upon by the team. The Effort Estimated Task List is used by the Scrum Team during Sprint Planning Meetings to create the Sprint Backlog and the Sprint Burndown Chart.

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. The output of this process is an Effort Estimated 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.

Fist of Five

Fist of Five is a simple and quick mechanism to achieve consensus in a group and drive discussion. After initial discussion on a given proposal or pending decision, the Scrum Team members are each asked to vote on a scale of 1 to 5 using their fingers.

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. 1. What has my team been working on since the last meeting? 2. What will my team do until the next meeting? 3. What were other teams counting on our team to finish that remains undone? 4. What is our team planning on doing that might affect other teams?

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.

Groom Prioritized Product Backlog

Groom Prioritized Product Backlog is a process in which the Prioritized Product Backlog is continuously updated and maintained.

Identify Scrum Master and Stakeholder(s) process

In this process, the Scrum Master and the stakeholders are identified using specific Selection Criteria.

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 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.

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 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: 1. Exciters/Delighters 2. Satisfiers 3. Dissatisfiers 4. Indifferent

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.

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.

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 which are not mandatorily required for the Scrum project. They may include team members who are interested in the project, who have no formal role on the project team, 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 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 stakeholders.

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.

Points for Cost Estimating

Cost estimation can be accomplished through the use of relative units (e.g., effort estimates) rather than absolute units (i.e., actual costs incurred). In order to estimate the cost to implement a User Story, the Scrum Team can use story points. When this is done, the cost estimated for each task will be in the form of story points, rather than monetary units.

Portfolio

A portfolio is a group of related programs, 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.

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 Grooming Session) is a formal meeting during the Groom 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 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

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 Stakeholder(s), Program Product Owner, Program Scrum Master, and Chief Product Owner. It helps identify the business context, business requirements, and 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: 1. Quality planning 2. Quality control 3. Quality assurance

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.

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: 1. Eliminating repetitive and redundant code 2. Breaking methods and functions into smaller routines 3. Clearly defining variables and method names 4. Simplifying the code design 5. Making the code easier to understand and modify

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.

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 Stakeholder(s).

Release Prioritization Methods

Release Prioritization Methods are used to develop a Release Plan. These methods are industry and organization specific and are usually determined by senior management in an organization.

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.

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 Attitude

Essentially, the Risk Attitude of the Stakeholder(s) determines how much risk the Stakeholder(s) consider acceptable. This is a determining factor in when they will decide to take actions to mitigate potential adverse risks.

Risk Averse

Risk Averse is one of the categories of Utility Function. It refers to a 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 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 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 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 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 stakeholder or organization is more likely to accept the risk.

Risk tolerance

Risk tolerance indicates the degree, amount, or volume of risk the stakeholders will withstand.

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.

Risks

Risks include any uncertain or unplanned events that may affect the project positively or negatively.

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 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 of Scrums Meeting

The Scrum of Scrums (SoS) Meeting is an important meeting when scaling Scrum to large projects with representatives from all teams attending. This meeting is usually facilitated by the Chief Scrum Master and is intended to focus on areas of coordination and integration between the different Scrum Teams. This meeting is conducted at predetermined intervals or when required by the Scrum Teams.

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 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 believes that employees are self-motivated and seek to accept greater responsibility. Hence, they deliver much greater value when self-organized.

Servant Leader

Servant leaders employ listening, empathy, commitment, and insight while sharing power and authority with team members. Servant leaders are stewards who achieve results by focusing on the needs of the team. This style is the embodiment of the Scrum Master role.

Ship Deliverables

In this process, Accepted Deliverables are delivered or transitioned to the relevant 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 stakeholder to whom everyone is accountable in the end.

Sprint

A Sprint is a time-boxed iteration of one to six 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 Create 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(s)

Stakeholder(s) is a collective term that includes customers, users, and sponsor who frequently interface with the Product Owner, Scrum Master and Scrum Team to provide inputs and facilitate creation of the project’s product, service, or other results.

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.

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 stakeholders or users. The 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.

Task Planning Meeting

In a Task Planning Meeting, the Scrum Team gets together to plan the work to be done in the Sprint and the team reviews the committed User Stories at the top of the Prioritized Product Backlog. To help ensure that the group stays on topic, this meeting should be Time-boxed, with the standard length limited to two hours per week of Sprint duration.

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.

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.

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: 1. What did I complete yesterday? 2. What will I complete today? 3. What impediments or obstacles (if any) am I currently facing?

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.

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 grooming to incorporate changes and new requirements.

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 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 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 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 stakeholder risk preference or attitude toward risk. It defines the 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.

Share with your Friends

Search

Navigation

Archives

Meta

Our Contacts

Entire Contents itSM Solutions® LLC. All Rights Reserved.

[ITIL® PRINCE2® RESILIA™ is a registered trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved. The Swirl logo™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved

The APMG-International ISO/IEC 20000 and Swirl Device logo is a trade mark of The APM Group Limited.

COBIT® is a registered trademark of ISACA® registered in the United States and other countries