(Take printouts and Fold at the center to make Flashcards for quick reference
Terms | Definition |
---|---|
Acceptance Criteria | The product characteristics, specified by the Product Owner, that need to be satisfied before they are accepted by the user, customer, or other authorized entity. These are used as standards to measure and compare the characteristics of the final product with specified characteristics. |
Acceptance Test | These tests are run from a business and customer point of view. These tests check the requested and implemented feature and determine whether these features match the business and the customer requirements |
Acceptance-Test-Driven Development (ATTD) | A system or product development method in which the acceptance criteria are discussed extensively by the participants, through the use of examples and well-designed acceptance tests on the basis of the these criteria before development begins. |
Accuracy | The degree by which the measured value is very close to the true value (PMI). |
Acquire Project Team | It is the process of confirming and securing the team necessary to complete the a project. Skill, experience and availability of resources are important parameters considered while acquiring project team. |
Adaptability | Desirable characteristic in a person, team, process or system measured in the ability/capability to adapt or being adapted. In organizational context, it refers to the ability to change something or oneself to fit to occurring changes. |
Adaptation | Modification in the product being developed or in the process of product development. Variations in the actual value and true value trigger the need for control and modification of the product or process. |
Adaptive planning | Agile methodologies reduce waste by cutting back on work that does not add value. Planning a project does not directly add business value. Therefore, planning at any stage of a Scrum project should be as efficient as possible. Planning ahead for the whole project is considered waste, because Agile projects are prone to a high rate of change. Therefore, planning is done Just in Time (JIT). |
Adaptive Project Management | Adaptive Project Management is a structured, iterative process of management which focuses on less up-front planning, unlike Waterfall methods. This creates a fairly adaptable environment for teams where they focus on only the immediate tasks at hand, complete them, and then move to the next tasks. If there are any changes in requirements, then they are incorporated into the next Sprint. This ensures you to be on track with the quick changing market and technology scenario, enabling you to deliver the greatest value in the shortest time to your customers. |
Additional Risk Response Planning | This is done to take care of risks that were not initially identified or when the impact of a risk on objectives is greater than expected. The existing risk response planning may not be enough to control the risk. |
Agile | Agile is a group of iterative and incremental software development methods. It encourages flexibility and speed in responding to change. It requires collaboration between self-organized, cross-functional teams to generate requirements and solutions. |
Agile Unified Process | Agile Unified Process (AUP) is a refinement of the "IBM Rational Unified Process (RUP)" first described by Craig Larman in 2001. Agile concepts and techniques are used to select elements from RUP. Iterations are classified into two types: Development and Release. |
All-Before-Any | A sequential development process in which the output from the previous step is used as input for the next step in the process using a batch size of 100%. |
Approach | The method used, or steps taken in, setting about a task or problem by the Scrum team. The approach differs from team to team. |
Artifact | Any concrete by-product formed during the development cycle. Example of artifacts includes the Product Backlog and the Sprint Backlog. |
Assumptions | Factors which, for planning purposes, are considered to be true, real or certain. |
Assumptions Analysis | A project management exercise that explores the validity of assumptions that were made at the beginning of the project to identify any potential project risk conceived and developed because of the inaccuracy of any assumption. It also identifies risks because of any instability, inconsistency, or incompleteness of assumptions. |
Basic Unified Process (BUP) | BUP is a simpler variation of Rational Unified Process (RUP) developed in 2005. It was optimized for small projects by IBM. |
Behavior Driven Development | Behavior driven development (or BDD) is a software development process which involves collaboration between non-technical or business participants and people with technical insight like developers, QA etc. |
Brainstorming | A group activity or creativity technique that can be used to generate and analyze ideas or to identify issues, risks, or even to determine solutions to problems. |
Burn down Chart | A graphical representation of the amount of work completed/done versus the elapsed time period. It is used to estimate the time needed to complete the project. The vertical axis represents the planned work, and the horizontal work axis represents the time. The general trend in the graph is to "burn down" to a point where no work remains. |
Burn up Chart | A graphical representation of the amount of work completed against planned over a period of time. The graphical trend line moves upward toward the goal line, hence called "burn up" in contrast to "burn down." It is used to estimate the time needed to complete the project. |
Buyer-Seller relationship | In a commercial project environment, a seller could be any entity (subcontractor, vendor, or supplier) who manages the work of the project or delivers the product of the project and the buyer is the customer who outsources the work to the seller. |
Cadence | Cadence is the approach to achieving commitment and reliability with a system. It is a measure of balance and the rhythmic flow of the process. Sprints of regular time interval or duration establish a cadence for a development effort. |
Capability Maturity Model Integration (CMMI) | CMMI is a process improvement product suite. It was developed by the CMMI project as a collaborative industry, government, and academic effort, which combined best practices for software development. It is very effective for projects involving defined processes. |
Capacity | Capacity is defined by the amount of work that can be accomplished within the available resources. |
Ceremony | A formal act or set of acts performed as prescribed by ritual or custom. Core Scrum activities like spring planning, daily scrum, sprint review, and sprint retrospective are referred to as ceremony by the Scrum team. |
Chaotic Domain | The state of crisis that needs to be immediately addressed to prevent further harm or loss and re-establish the order. It calls for quick response. |
Chickens and Pigs | A fable used in the Agile Project Management to define the type of role an attendee can play in Scrum. It derives from the fable of a chicken and a pig that planned to open a restaurant together. Both of them are involved but only the pigs are committed. Pigs have to get the project completed according to the requirements. |
Chief Product Owner | The person responsible for the overall Product Backlog in product development with multiple Scrum Teams. |
Chrysler Comprehensive Compensation System Project (C3) | C3 was a project to have a single payroll system for everyone in Chrysler. This project ran from 1993 until DaimlerChrysler (after Chrysler was bought out) stopped the C3 project on February 1, 2000. Many Agile software development techniques were developed during this project; chief among them was Extreme Programming (XP). |
Code Refactoring | A technique used in software development for restructuring/redesigning an existing body of code without changing its behavior. The purpose of re-factoring is to improve non-functional attributes of the software, e.g., managing technical debt or making coding faster. |
Collect Requirements | Process of defining and documenting stakeholder's needs to meet the project objectives. |
Collective accountability | In a Scrum Project environment, the whole team is collectively responsible for ensuring that the work agreed on for a Sprint is completed in a timely manner. |
Commitment | Commitment means a conscious choice to do something. To bind or obligate oneself to a cause, person, or action, as by pledge or assurance. |
Communications Technology | Technologies or methods to transfer information among project stakeholders. |
Complex Adaptive System | Numerous entities governed by common simple localized rules, which interact with each other in various ways and receive constant feedback. |
Complex Domain | A domain in the Cynefin framework wherein the situation is unpredictable and the correctness of the answer is only known in hindsight. |
Component Team | Component teams are specialized teams organized around the architecture of the product under development. A team that focuses on the creation of one or more components of a larger product that a customer would purchase. Component teams create assets or components that are then reused by other teams to assemble customer-valuable solutions. |
Conditions of Satisfaction | Conditions of satisfaction are the acceptance criteria specified by the product owner, which determine the desired behavior of the product that to be accepted. These are the conditions under which the product owner is satisfied with the outcome of each product backlog item. |
Continuous Delivery | Delivering the product or each product feature to its users immediately after it is integrated and tested by the developer. |
Continuous Deployment | Delivering the product or each product feature to its users immediately after it is integrated and tested by the developer. |
Continuous Improvement | On most traditional projects, lessons learned are compiled at the end of the project so they can be applied to future projects. However, applying lessons to future projects does not add value to the current project. Future projects may not be similar to past projects. Therefore, Agile aims to continuously learn during each project and apply lessons learned within the current project. Several tools, techniques, knowledge sets, and skills can continuously improve Agile projects - e.g. retrospective meetings, knowledge sharing etc. |
Cost of Delay | Monetary loss incurred due to delay in work, process, or achieving production targets. This concept emphasizes that the time associated with project has a financial cost. |
Cross Functional Team | A project team that has expertise from the different fields, like designers, developers, and testers who have skills required to complete the work effectively and efficiently. |
Crystal | The Crystal family of methodologies was developed by Alistair Cockburn in the mid-1990s. The methodologies are named after colors and/or gemstones to indicate the "weight" of methodology needed (as per the team attributes or strategic needs). The most famous is also the lightest, called "Crystal Clear," used for small teams with co-located members working on noncritical tasks. The family focuses on efficiency and habitability as constituents of project safety. |
Daily Stand-Up | The daily standup meeting, or Scrum meeting, is a daily team meeting in the Scrum Framework. The name comes from the practice of the attendees standing up. This encourages the members to keep the meeting short. It gives the team a regular opportunity to monitor progress along the sprint plan. |
Defined Process | A well-defined process that produces the same output for the same input every time (minus the minor variations within the range). The inputs, outputs and the steps involved are clearly stated in such process. |
Defined Process Control | A process control approach used for defined processes. This model primarily involves creating and maintaining processes that produce expected output. |
Definition of Ready | Conditions that need to be satisfied by the product backlog item before it is considered ready to pull into a sprint during sprint planning. |
Delphi Method | The Delphi Method is an estimation/surveying method in which estimates and opinions are collected anonymously from a panel. This reduces the bias that may arise due to the power/influence of certain panel members. |
Development Team | A development team is formed with members from different areas of functional expertise. It has to be self-organized, and it must drive toward a single goal. This team is collectively responsible developing of an acceptable product. |
Disorder Domain | This is one of the domains in the Cynefin framework. This is a dangerous stage, and the priority should be to come out of this domain because we either don't understand or can't make sense of the situation we are in. |
Dot Voting | This technique is used for identifying items with higher priority. Participants have to cast their vote by placing a colored dot against one item among the listed, and the item with most dots is considered an item of higher priority. This technique is frequently used during the sprint retrospective. |
Economic Filter | Economic filter is used as a decision-making criterion by the organization to evaluate the economic benefits of the project under consideration and whether to fund it or not. |
Empirical Process Control | A process control approach used when processes are incompletely defined and the output is unique. This model leverages frequent inspection, adaptation and transparency. Scrum enables empirical process control for project management. |
End Uncertainty | End uncertainty is the uncertainty surrounding the properties of the final deliverable of a project or process. |
Epic | An epic is a large user story, typically one that is too big to fit in a single sprint. Epics need to be broken down into smaller user stories at some point before implementation as part of a sprint. |
Essential Unified Process | An Agile Method sourced from Rational Unified Process (RUP), Capability Maturity Model Integration (CMMI) and Agile processes. Used primarily for software development, it was developed by Ivar Jacobson, one of the original contributors to RUP, as an improvement on the Rational Unified Process. It is practice centric rather than focused on processes/roles. It relies on Separation of Concerns, a principle of separating the product into separate sections, each addressing a separate concern. |
Estimation | A rough calculation of the number, quantity, or size of product backlog items, portfolio backlog item, and sprint backlog task. |
Event Timeline | A technique used during sprint retrospective, which involves chronological depiction of events that occurred over a period of time. |
Expert Judgment | Judgment provided by expert (s) in specific area on matters or activities being performed in that area. Expert could be a person or group with specialized training or education, knowledge and skill. The expertise could also be acquired with time and experience. |
Forecasting | Estimating or predicting future project status and progress based on knowledge and information available at the time of forecasting. |
Functional Test | Functional Testing usually describes what the system does. Here functions are tested by feeding input and examining the output. It is type of 'Black Box Testing' where we do not consider the internal program structure and mostly compare the actual and expected outputs. |
Genchi Genbutsu | In Japanese, this means "go and see for yourself." It is the conviction that real time experience is more useful than theory. One must see the problem to understand the problem rather than hear about a problem from someone else. This will help in making an informed decision about the solution. |
Group Decision Making Techniques | Used to generate, classify, and prioritize product requirements. Some methods used to reach group decisions are: unanimity, majority, plurality, and dictatorship. |
Impediment | A factor that's causing a hindrance or blockage from performing scrum in an effective manner in a team or organization. |
Impediment Log | Impediment log captures or records impediments, description of the impediments, impacts of the impediments, the solution, if any and status of the impediments. The format may vary. It is recommended that the Scrum Master update the log after each Daily Stand-up. |
Incremental Funding | Funding a part of the product development without committing to funding all of it. With incremental funding, only a small part of the development effort is funded, after which the funding decision is critically valued to see what is being paid to get from this small part. |
Information Radiator | A visual display that presents sufficiently detailed, up-to-date, and important information to passersby in an easy self-interpretative format. |
Innovation Accounting | A mathematically intense process of defining, measuring, and communicating improvements in innovation. This framework tries to identify the reasons for differences in innovative output between teams are different time periods. Commonly used as a metric to measure progress of startups. |
Innovation Waste | The opportunity lost to create an innovative solution. Usually occurs when a prescribed solution is provided with a product backlog item. |
Integration | The combination of various components of a product to form a coherent, larger-scope work product that can be validated to function correctly as a whole. |
Internal Stakeholders | The stakeholders who are internal to the organization, i.e., those who are involved in product development. For example, senior executives, managers and internal users. |
Interviews | A formal or informal approach to obtain information from stakeholders by talking to them directly |
Iterative Product Development | In iterative product development, the final product is developed over a few iterations and delivered to the customer. |
Kanban | This term means "signboard" in Japanese. Taiichi Ohno adapted the word used for shop signboards to depict the following philosophy: A down steam process must go and fetch what it needs--similar to how we go and fetch what we need from a shop/store. |
Kano Model | Named after Noriaki Kano, a Japanese professor Kano Model is used to map what is valued by the customer by classifying the product attributes into basic, performance, and excitement categories. It can be used to determine the minimally viable product that a customer will feel satisfies his or her basic requirements. |
Known Technical Debt | A status category for technical debt that represents the debt that is known to the development team and has been made visible for future consideration. Contrast with "happened-upon technical debt" and "targeted technical debt." See also "technical debt." |
Lean | Lean Manufacturing or simply Lean focuses on the removal of waste from the production. It is a practice for delivering more or same value with less resource by eliminating waste across organizations and business processes. Lean considers an element or activity as 'Waste' if the same is used for purposes other than creating value to the customers. |
Lean Product Development (LPD) | LPD is the application of Lean Principles to product development. It is one of the initial Agile methods. |
Lifecycle Profits | 1. The total profit potential for a product over its lifetime. 2. The total profit potential of the entire portfolio rather than a single product. |
Means Uncertainty | Means uncertainty is the uncertainty surrounding the means through which a deliverable will be created. |
Minimum Marketable Features (MMFs) | The smallest or minimum set of functionality related to a feature that must be delivered for the customer to perceive value (for it to be marketable). Contrast with "minimum releasable features." |
Minimum Viable Product (MVP) | A product with just those minimal features that allow it to be deployed, and no more. Usually, MVP is the result of the first sprint. |
MoSCoW | A technique used to categorize the importance of different attributes in a product from Customer point of view to enable the development team to place importance on the delivery of each requirement. This teaching is useful in defining the 'Acceptance Criteria' of a product by specifying 'Must Have, Should Have, Could Have, and Won't Have' requirements. |
Muda | This is a Japanese term used to refer to any wasteful activity that has no value. Muda is an essential factor in Kanban. In order to run a business, an organization has to produce goods or provide services for the customer to buy or pay for. This requires a process, and this process makes use of resources. The waste factor comes into the picture when resources are consumed unnecessarily. The Kanban approach increases awareness of wasteful resource consumption and helps identify waste and unexploited prospects and opportunities. |
Mura | In Japanese, this term means unevenness or inconsistency in physical matter or human spiritual condition. In Kanban, Mura is reduced by equipping the process with the exact part, at the exact time, in the exact amount. |
Muri | This Japanese word is used for overburden, unreasonableness or absurdity. Kanban avoids Muri through standardized work. First, a standard output is defined so that there can be an effective judgment of quality. Then, the elements in each process are simplified for examination and recombination. The process is then standardized to get a standard condition. |
Must-have Features | The set of features that must be present in the upcoming release for the release to be viable. |
Nice-to-have Features | These are the features that are targeted as "would be nice to have" in an upcoming release but can be left out if there is a shortage of funds to complete the project. |
Objective Definition | Objective Definition is part of a Sprint Planning Meeting, wherein the Product Owner explains the prioritized items in the Product Backlog and the team commits to the Product Backlog items to be completed during the Sprint. |
Open Unified Process | An open source process framework developed by the Eclipse Foundation from Basic Unified Process (BUP) of IBM. The Core principles are: iterative life cycle, collaboration, Management of requirements and Cognizance of architecture. |
Organization Chart | Charts that are used to show positions and relationships in a graphical format. |
Pair Programming | Pair programming is a programming technique in which two programmers working together on a single system. This practice has been around since the 1950s. Many studies have shown that pair programmers are more than twice as efficient; in code production and especially in freedom from bugs, than one single programmer on a single system. |
Plan Risk Management | Process of defining how to conduct risk management activities for a project. |
Planning Poker | An Agile estimation practice which is a variation of the wideband Delphi method of consensus based estimation. It is used to estimate effort or relative size of user stories by assigning story points to each user story. This technique can also be used for meetings where the team estimates risk in different modules. |
Point Inflation | The unfortunate phenomena of inflating the value of product backlog size estimates in an attempt to conform to or optimize an unwisely conceived measure (such as achieving a target velocity). |
Portfolio Backlog | Highest level of backlog in Agile framework; it is composed of products, programs, projects, or high-level epics. See also "portfolio planning." |
Practice | Sessions scheduled for the purpose of rehearsing and performance improvement are called practice. For example, the principle of demonstrating progress is supported by the sprint review Scrum practice. |
Precision | Degree by which the values of repeated measurements are clustered and have little scatter [PMI]. |
Prevention vs. Inspections | Prevention is an activity that can reduce the probability of negative consequences associated with project risks whereas inspection measures to verify whether an activity, component, product, or service conforms to specified requirements. The cost of preventing mistakes is much less than the cost of correcting the mistakes found during inspection. |
Principle of Least Astonishment | Acting or developing work products in a way that is least likely to astonish the users. |
Prioritization | The process of ordering a list according to a given attribute. |
Prioritized Delivery | Scrum believes in delivering the greatest amount of value in the least amount of time. This requires prioritized delivery in which "what will be done" has to be chosen from "what has to be done" according to business value. |
Product Backlog | A prioritized list of work to be performed in a project. In the Scrum framework, this evolves with the business need and the environment . |
Product Backlog Grooming | The filtering of tasks on the product backlog based on their importance as per criteria set by the product owner. |
Product Backlog Item (PBI) | An item such as a feature or benefit that is valuable to the process of product development. |
Product Description | Documents the characteristics of the product, or deliverable which the project is undertaken to create. |
Product Development Effort | The entire scope of the effort put in to create or enhance a product or service. |
Product Owner | The leader of the product development team. The voice of the stakeholder community to the scrum team. The product owner defines what to do and in what order to do it |
Product Owner Proxy | A person authorized by the product owner to act on his behalf in particular situations. See also "product owner." |
Product Roadmap | A product road map is a high-level plan that shows when in the future new products are expected to be developed or introduced by the organization/team. The requests to edit the road map (usually by adding new products) come from the sales force or senior management in the company when the marketing strategy is made. |
Product Scope | Features or services that characterize a product, result, or service |
Product Vision | A statement describing the desired future state that would be achieved by developing and deploying a product. A good product vision is simple, easy to understand statement and provides a coherent direction to the people who are asked to realize it. |
Progressive Refinement | Breaking-down, in an organized manner, large lightly detailed product backlog items into a set of smaller, more detailed items. |
Project Chartering | The set of up-front work needed to define a project at particular level of detail so that a funding decision can be made. |
Project Closeout | Processes and procedures developed for the closing or canceling of projects. |
Project Records | It can include correspondence, memos, meeting minutes, and documents describing the project. |
Quality | The degree to which a set of inherent characteristics fulfill requirements (fit for purpose). |
Quality Metrics | Describes in specific terms a project or product attribute and how it is measured by the quality control process. |
Queue | A term adapted from Lean Manufacturing. An inventory of items that wait for the next action in the work stream. |
Rapid Application Development | A software development process first named and introduced in 1991. It prioritizes faster development and application maintenance facilitation over functionality and performance. |
Rational Unified Process | It is a combination of software development models created in 1996 in the Rational Software Corporation. It is a process framework; where individual building blocks could be chosen and adapted to suit the project at hand. It was aimed to give the advantages of both waterfall and rapid application development models. |
Recruitment Practices | The policies, guidelines, or procedures that govern the recruitment of staff. |
Release Planning | A term borrowed from Lean Manufacturing. The function of release planning is to synchronize projected range of potential delivery dates in the future with tasks to be done today. |
Release Train | A technique of planning product releases on regular or cyclic time period. Made famous by Cisco for its IOS software platform, each release is then decomposed into several projects for Multiple Products. |
Risk Avoidance | One of the planned risk responses in which we try to avoid the risk entirely by changing some aspect of the project. |
Role | A well-defined set of responsibilities that may be fulfilled by one or more people and for which they are accountable. The three Scrum roles are product owner, Scrum Master, and development team. |
Rule | A common practice or generally prescribed method of action in a particular situation. A rule may be broken when the need of a situation dictate that a deviation from the normal course of action is needed. The Scrum framework includes rules. |
Scrum | A methodology originally refined in 1995 by Ken Schwaber and Jeff Sutherland from work done by Hirotaka Takeuchi and Ikujiro Nonaka. Named after the SCRUM in Rugby, this is the most recognized Agile framework. It is an iterative methodology that treats major portions of development as a controlled black box. Iterations called sprints are used to evolve the product which is ready to ship after each sprint [Schwaber, Ken "SCRUM Development Process"]. |
Scrum Board | Scrum board is used to plan and track progress during a Sprint which usually contains three columns to indicate the progress of the estimated tasks for the Sprint: a To Do column for the tasks not yet started, a Work in Progress column for the tasks started but not completed, and a Done column for the tasks completed. Scrum board also contains the Sprint burn down chart and space for unexpected items. |
Scrum Framework | A set of principles, values, practices and rules that form the base for Scrum-based development. |
Scrum Master | The Scrum Master is one of the three Core/Pig roles on a Scrum team. Scrum Master facilitates Scrum and is responsible for removing obstacles; thus enabling the team to deliver the sprint goal/deliverable. |
Scrum of Scrum | Scrum of Scrums is analogous to the Daily Scrum. This meeting is facilitated by the Chief Scrum Master and usually conducted in large projects where multiple Scrum teams to work in sync to ensure project progress. |
Scrum Roles | There are three core roles in Scrum: The Product Owner, The Scrum Master, and the Scrum team (also called the development team). These are the people responsible for completing the project objectives. |
Scrum Team | A Scrum team is composed of a product owner, Scrum Master, and development team, responsible for the high-quality and timely delivery of sprint commitments. |
Self-Organized | A team or a group of people that manage themselves, their time and resources is said to be self-organized. |
Sprint Demo | A sprint review activity where the product backlog items that are completed will be demonstrated. The intention is to encourage an information-rich discussion between the Scrum team and other sprint review participants. |
Sprint Goal | The sprint goal is what is to be accomplished by the end of the sprint. Its a summary of the activities/results elaborated by the product backlog items that the Product Owner would like to accomplish during the sprint. |
Sprint Planning Meeting | The sprint planning meeting takes place at the beginning of each sprint. The purpose of the meeting is to define the objectives and tasks. |
Sprint Retrospective | Its the review and analysis done at the end of every sprint. The aim is to improve the performance of the Scrum team and adopt better practices. |
Sprint Review | The sprint review meeting takes place at the end of each sprint. The delivery team shows what they accomplished during the sprint. Activity attributes are reviewed, modified, and reconciled at every sprint review meeting. |
Staffing Pool | Characteristics of those prospective staff that is available to join a team. |
Staffing Requirements | Defines what kinds of competencies are required from what kind of individuals or groups and in what time frames. |
Stakeholder | Any person or entity who can affect an endeavor / project, or be affected by it, or be perceived itself to be affected is a stakeholder. |
Statistical Sampling | Sampling which involves choosing part of a population of interest for inspection. |
Status Review Meetings | Meetings that are regularly scheduled to exchange and analyze information about the project status and its performance. |
Story Point | The abstract measure of effort to implement a story is called a story point. Typically determined by engaging in planning poker. |
Sustainable Pace | The appropriately aggressive pace at which a team works so that it produces a good flow of business value over an extended period of time without getting burned out. |
Synchronization | Synchronization is the coordination of events to operate a system in unison. Frequently used to ensure that multiple Scrum teams work together in a coordinated way by starting and ending their sprints on the same days. |
System or Process Charts | Graphical representation of a process showing the relationships among various process steps. During quality planning, flowcharts would assist the project team in anticipating quality problems that might occur. Commonly used in waterfall methods. |
Task Board | A chart/board that depicts all the work the team is doing during a sprint. There are 5 columns: "Story," "To do," "In progress," and "done." |
Task Estimation | The team breaks down the selected Product Backlog items into tasks and then the tasks are estimated by the team members according to their complexity, risk involved, potential time required, and so on using team exercises. |
Team Building Activities | Activities specifically taken by management and team members to help individual team members work together effectively, thereby improving team performance |
Technique | A technique is a procedure used to accomplish a specific activity or task. Its a defined procedure that is used to perform some or all of an activity or support an approach. |
Time Box | A fixed duration of time during which an activity is performed. In Scrum, sprints are time boxed iterations. |
Tolerances vs. Control limits | Tolerances indicate specified range of acceptable results. Control Limits are the thresholds, which indicate whether the process is out of control. |
Transparency | One of the key principles of Scrum is transparency, wherein the customer is constantly aware of the product progress, and the team members are aware of their roles and responsibilities. |
Trend Analysis | A mathematical technique to forecast future outcomes based on historical results. This is performed using run charts. |
Triggers | Also called symptoms or warning signs, they are indications that an event has occurred or is about to occur. Commonly used in Risk Management. |
User Stories | A User Story is a statement (or a group of statements) that expresses the desired end user functionality. User Stories are generally simple, short, and easy to implement. Longer User Stories are further broken down into multiple User Stories. |
Voice of Customer(VOC) | The Product Owner (PO) represents the stakeholders and is responsible for ensuring that the team delivers value. The PO is responsible for ensuring clear communication of product functionalities to the Scrum team and, therefore, is commonly called the Voice of Customer. |
Wideband Delphi Method | The wideband Delphi method is a variation of the Delphi method. Here, after a round of response collection, the panel members are shown the gathered data and the originators of responses far from the mean are asked to justify their survey response/estimate. This is then followed by another round of response collection. |
Won't-have Features | A set of features/options that are specifically declared to not be available in the forthcoming release. |
Work In Progress | Refers to work that has been undertaken but not yet completed. If large segments of the project are WIP, it can pose several problems. Identifying bottlenecks in the project becomes difficult when several tasks are WIP at the same time. Each WIP requires capital and does not contribute to ROI until it becomes a completed, usable product. Kanban boards are effective in placing limits on WIP. |