Terms

Definition The Product characteristics, specified by the product owner which needs to be satisfied before it is accepted by the user, customer, or other authorized entity. These are used as standard to measure and compare the characteristics of the final product with specified characteristics. The assessment carried out to determine whether the product satisfies the acceptance criteria. This assessment helps the user, customer or the authorized entity decide whether to accept the product/system or not. It helps to identify the areas of improvement. A system or product development method in which the acceptance criteria are discussed extensively by the participants, using examples, and then by well designing acceptance tests on the basis of the criteria before development begins. Measure of degree of proximity of result to its actual or true value. Action taken or task performed by the scrum team. It has four characteristics: (1) definite duration, (2) logic relationships with other activities in the project, (3) resource consumption, and (4) an associated cost. Modification in the product being developed or 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. 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. AUP describes a simple approach to develop business application software using Agile techniques and concepts yet remaining true to the Rational Unified Process. The AUP applies Agile techniques including testdriven development (TDD), Agile Modeling, Agile change management, and database refactoring to improve productivity. Carrying out or performing all the tasks in a single iteration simultaneously. 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%. The method used or steps taken in setting about a task or problem by the scrum team. The approach differs from team to team. Any concrete by product formed during the development cycle. Example of artifacts - Product Backlog, Sprint Backlog A thing that is accepted as true or as certain to happen, without proof A system or product development method in which the acceptance criteria are discussed extensively by the participants, using examples, and then by well designing acceptance tests on the basis of the these criteria before development begins. The maximum number of input items that can be processed at a time. 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. A graphical representation of the amount of work completed against planned over a period of time. The graphical trend line moves upward towards the goal line and hence called burnup, contrast to burndown. It is uses to estimate the time needed to complete the project. 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. Is defined by the amount of work that can be accomplished within the available resources . 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 as ceremony by the scrum team.

Acceptance criteria

Acceptance test Acceptance-testdriven development (ATTD) Accuracy Activity Adaptation

Agile

Agile Unified Process

All-at-once product development All-before-any Approach Artifact Assumption

ATTD

batch size

Burndown chart

Burnup Chart

Cadence

Capacity Ceremony

Chaotic domain

The state of crisis which need to be immediately addressed to prevent further harm or loss and reestablish the order. It calls for quick response. An analogy used in the Scrum software development model to define the type of role an attendee can play at a daily scrum meeting i.e. their involvement but not their commitment. If an attendee is a chicken, he may be somewhat involved in the task at hand but is not the person whose "bacon is on the line" if the task doesn't get completed on time. Generally for large projects, a Chief Product Owner (generally a VP level person) is effectively the Product Owner of the whole product. The Chief Product Owner sets the product vision, monitors the strategic objectives, and is responsible for resource allocation. The Chief Product Owner is responsible for the success or failure of the whole product and owns the overall Product Backlog. Chief Scrum Master facilitates Scrum of Scrums and addresses the issues concerned to more than one team. His area of operations and decisions affect more than one Scrum team. Commitment means a conscious choice to do something. To bind or obligate, as by pledge or assurance. Numerous entities governed by common simple localized rules, which interact with each other in various ways and receive constant feedback. A domain in the Cynefin framework wherein the situation is unpredictable and the correctness of the answer is only known in hindsight One of the domains in Cynefin framework in which there might be multiple right answers but diagnosis by the expert is required to figure them out. 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 are the acceptance criteria specified by the product owner, which determine the desired behavior of the product to be accepted. These are the conditions under which the product owner is satisfied with the outcome of each product backlog item. Delivering the product or each product feature to its users immediately after it is integrated and tested by the developer. Delivering the product or each product feature to its users immediately after it is integrated and tested by the developer. Continuous integration (CI) is a software development practice in which isolated changes are immediately tested and reported on when they are added to a larger code base. The objective of CI is to provide rapid feedback about the success or defects in the system so that corrective actions can be taken to rectify the errors. Monetary loss incurred due to delay in work, process, or achieving production targets. This concept emphasizes that time associated with project has a financial cost. A project team which has expertise from the different fields, like designers, developers, testers who have skills required to complete the work effectively and efficiently. The Crystal family of methodologies focuses on efficiency and habitability as components of project safety. Crystal Clear is agile and requires the following properties: Frequent delivery of usable code to users, Reflective improvement, and Osmotic communication. A sense-making framework that helps us understand the situation in which we have to operate and decide on a situation-appropriate approach (Snowden and Boone 2007). "The Daily Scrum meeting is a short timeboxed meeting (generally 15 minutes) for the Team members to communicate their work status and their plan for the next 24 hours to the team. Each team member answers the following questions: 1) What did I do yesterday? 2) What will I do today? 3) What's in my way? The daily standup meeting or scrum meeting presents the team with a regular opportunity to synchronize development activities with the iteration plan and to check and reflect on the progress of the teams commitments towards the iteration goal. Acronym which stands for Detailed appropriately, Emergent, Estimated, and Prioritized. It is coined by Roman Pichler and Mike Cohn. It helps to remember the criteria used to validate the quality of a product backlog.

Chickens

Chief product owner

Chief Scrum Master Commitment Complex adaptive system Complex domain Complicated domain

Component team

Conditions of satisfaction Continuous Delivery Continuous deployment Continuous Integration

Cost of delay Cross functional team

Crystal

Cynefin

Daily scrum

Daily stand-up

DEEP

Defination of Done

A checklist of criteria specified, which need to be met by the development team, before it declares that the product is ready for shipment. A bare-minimum definition of done should yield a complete slice of product functionality, one that has been designed, built, integrated, tested, and documented and will deliver validated customer value. 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. Conditions that need to be satisfied by the product backlog item before it is considered ready to pull into a sprint during sprint planning. Development team is formed with members from different areas of functional expertise. It has to be selforganized, and drive towards single goal. This team is collectively responsible for the development of acceptable product. This is one of the domains in the Cynefin framework. This is dangerous stage and priority should be to come out of this domain, because we really don't understand or can't make sense of the situation we are in. This technique is used for identifying items with higher priority. Participants have to put their vote by placing a colored dot against one item among the listed, and the item with more dots is considered as an item of higher priority. This technique is frequently used during the sprint retrospective. DSDM is an iterative and incremental approach that embraces principles of Agile development, including continuous user/customer involvement. DSDM fixes cost, quality, and time at the outset and uses the MoSCoW prioritization of scope into must, should, could, and won't haves to adjust the project deliverable to meet the stated time constraint. Economic filter is used as a decision making criteria by the organization, to evaluate the economic benefits of the project under consideration and whether to fund it or not. An opportunity that was previously unknown or ignored or was considered not financially benefiting and therefore not worth spending money on at that time. Graphical representation of emotional trends of the scrum team members over the course of a sprint. This is used during sprint retrospective. A style of work that leverages the principles of inspection, adaptation, and transparency. Uncertainty about the final output of the project or the process. An Epic is a large User Story, typically one that is too big to fit in a single Sprint. Epics need to be disaggregated into smaller User Stories at some point before implementation. Scrum essentials are the values, principles and practices combined with rules and proven approaches applied to scrum practices. EssUP identifies practices, such as use cases, iterative development, architecture-driven development, team practices, and process practices, which are borrowed from RUP, CMMI, and Agile development. The idea is that you can pick the practices that are applicable to your situation and combine them with your own process. Rough calculation of the number, quantity or the size of product backlog items, portfolio backlog item, and sprint backlog task. A technique used during sprint retrospective which involves chronological depiction of events that occurred over a period of time. An agile development approach that is complementary to Scrum. Extreme Programming specifies important technical practices that development teams use to manage the flow of task-level work during sprint execution. Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent "releases" in short development cycles (time boxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted. XP attempts to reduce the cost of changes in requirements by having multiple short development cycles, rather than a long one. In this doctrine, changes are a natural, inescapable and desirable aspect of software-development projects, and should be planned for, instead of attempting to define a stable set of requirements. FDD is a model-driven, short-iteration agile process that consists of five basic activities: Develop Overall Model, Build Feature List, Plan by Feature, Design by Feature, and Build by Feature.

Defined process Definition of ready

Development team

Disorder domain

Dot voting

Dynamic Systems Development Method

Economic filter Emergent opportunity Emotions seismograph Empirical process control End uncertainty Epic Essential Scrum Essential Unified Process Estimation Event timeline Extreme Programming (XP)

Extreme Programming (XP)

Feature Driven Development

Group Happened-upon technical debt Idle work Idle workers Impediment Implementable story In-process product Incremental development

A collection of people who share a common name (the group name) but have not yet formed a team whose members work together and trust each other. During the normal course of performing work on a product,a debt which occurs that the development team was unaware of previously.This usually falls under the category of technical debt. Work that is not actively being used as it sits in some queue. Workers who are not fully utilized and can do more work. A factor thats causing a hindrance or blockage from performing scrum in an effective manner in a team or organization. A user story that is small enough to fit conveniently in a sprint A product that is currently being sold, in live production or under development. Developing a product based on the principle of building some before building all. 2. A staging strategy in which parts of the product are developed and delivered to users at different intravels of time, with the in the intention to adapt to external feedback Funding a part of the product development without committing to fund 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. A visual display that presents sufficiently detailed,up-to-date and important information to passerby in an easy self-interpretative format An accounting system that uses actionable metrics to evaluate how fast we are learning as a critical measure of progress toward converging on a profitable result in business. The opportunity lost to create an innovative solution.Usually occurs when a prescribed solution is provided with a product backlog item. 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. The stakeholdes who are internal to the organisation,i.e those who are involved in product development.For example,senior executives,managers and internal users An acronym coined by Bill Wake for remembering a set of criteria used to evaluate the quality of user stories. The criteria are Independent, Negotiable, Valuable, Estimable, Sized correctly (small), and Testable. The act of repeating a process usually with the aim of approaching a desired goal or target or result. Each repetition of the process is also called an "iteration," and the results of one iteration are used as the starting point for the next iteration. Just in time (JIT) is a production strategy that strives to improve a business return on investment by reducing in-process inventory and associated carrying costs. "According to its creator, Taiichi Ohno, kanban is one means through which JIT is achieved. Kanban is not an inventory control system; it is a scheduling system that helps determine what to produce, when to produce it, and how much to produce. " 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, targeted technical debt. See also technical debt. A strategy of holding on to a decision to be made, but instead delaying commitment and keeping important and irreversible decisions open until the cost of not making a decision becomes greater than the cost of making a decision. LPD is the application of lean principles to product development, a cross-functional activity that seeks to uncover product knowledge hidden within the end-to-end production flow, typically in the hand-over points between functional units. 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.

Incremental funding

Information radiator Innovation accounting Innovation waste Integration Internal stakeholders Invest

Iteration

Just in time (JIT)

Kanban

Known technical debt

Last responsible moment (LRM) Lean product development Lifecycle profits

Means uncertainty Minimum marketable features (MMFs) Minimum releasable features (MRFs) Minimum viable product (MVP) Musketeer attitude Must-have features Naive technical debt Nice-to-have features

Uncertainity sorrounding how something will be built. 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. 1. The minimum amount of features that must be present in a release to make it viableuseful enough to end customers such that they want it and would be willing to pay for it. 2. Features composed from a collection of minimum marketable features. Synonymous with must-have features. See also minimum marketable features A product that has just those features that allow the product to be deployed, and no more. 1. All for one and one for all. 2. The attitude among all members of a team that they are all in the same boat and that they will win or lose together as a team The set of features that must be present in the upcoming release for the release to be viable. The technical debt that occurs due to the immature practices and irresponsible behaiour of the people involved in the project These are the feautures that are targeted to have in an upcoming release but can be avoided if there is a shortage of funds to complete the project. "OpenUP preserves the essential characteristics of RUP / Unified Process, which include iterative development, use cases and scenarios driving development, risk management, and architecture-centric approach. Most optional parts of RUP have been excluded, and many elements have been merged. The result is a much simpler process that is still true to RUP principles. OpenUP targets small and collocated teams interested in agile and iterative development. Small projects constitute teams of 3 to 6 people and involve 3 to 6 months of development effort." Planning Poker, also called Scrum poker, is a consensus-based technique for estimating, mostly used to estimate effort or relative size of user stories in software development. It is a variation of the Wideband Delphi method. It is most commonly used in agile software development, in particular the Extreme Programming methodology. 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). A backlog composed of products, programs, projects, or high-level epics. See also portfolio planning. The process of determining which products (or projects) to work on, in which order, and for how long. Sometimes referred to as portfolio management. When a product is completed to a high degree of confidence and represent work of good quality that is potentially shippable to end customers at the end of a sprint. Being potentially shippable does not mean the results will actually be delivered to customers. Shipping is a business decision; potentially shippable is a state of confidence. 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. How exact an estimate is. For example,saying the project will be completed on March 5, 2016 rather than saying March,2016 A principle is a law or rule that has to be, or usually is to be followed, or can be desirably followed, or is an inevitable consequence. Acting or developing work products in a way that is least likely to astonish those around you. " An item that ideally satisfies a market's want or need. 2. a deliverable or set of deliverables that contribute to a business solution." An important inventory of yet-to-be-worked on product backlog items. The filtering of product backlog items based on their importance. An item such as a feature or benefit that is valuable to the process of product development.

Open Unified Process

Planning Poker

Point Inflation Portfolio Backlog Portfolio Planning

Potentially shippable product increment

Practice Precision Principle Principle of least astonishmen Product Product backlog Product backlog grooming Product backlog item (PBI)

Product development effort Product owner Product owner proxy

The entire scope of the effort put in to create or enhance a product or service. 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 A person authorised by the product owner to act on his behalf in particular situations. See also product owner. A product roadmap is a plan that matches short-term and long-term goals with specific solutions to help meet those goals.[1] It is a plan that applies to a new product or process, or to an emerging project, with the important factors that drive each individual release. 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. Breaking-down,in an organised manner, large lightly detailed product backlog items into a set of smaller, more detailed items. 1. A temporary endeavor undertaken to create a unique product, service, or result (PMI).2.A collaborative enterprise, frequently involving research, that is carefully planned to achieve a particular aim.3. Projects are temporary rather than permanent social systems that are constituted by teams within or across organizations to accomplish particular tasks under time constraints. The set of up-front work needed to define a project at particular level of detail,so that a funding decision could be made. See project chartering. See project chartering. An inventory of items that wait for the next action in the work stream. A technique for restructuring an existing body of code by improving/simplifying its internal structure (design) without changing its external behavior. Refactoring is one of the principal techniques for managing technical debt. See also technical debt, technical practices. A Longer-term planning that would answer questions such as When will this be done? or Which features can I get by the end of the year? or How much will this cost?. The function of release planning is to use averaged velocity to project a range of potential delivery dates into the future. Release train is a form of release schedule in which a number of distinct series of versioned releases for multiple products are released as a number of different "trains" on a regular, pre-planned schedule.Its an approach to aligning the vision, planning, and inter dependencies of many teams by providing cross-team synchronization based on a common cadence. A release train focuses on fast, flexible flow at the level of a larger product. Risk is associated with uncertainty pertaining to future event(s).It is the potential that a chosen action or activity would lead to undesirable consequences. Risk is measured by both the probability of the event and the seriousness of the consequences. 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. 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 is a framework originally developed in 1995 by Ken Schwaber and Jeff Sutherland. Scrum is a framework for the iterative development of complex products, particularly software. Scrum is the most widely recognized Agile framework, and is compatible with other Agile practices like Extreme Programming(XP). Scrum is comprised of a series of short iterations called sprints, each of which ends with the delivery of an increment of working software. A set of principles, values, practices and rules that form the base for Scrum-based development. The Scrum Master is one of the three roles on a Scrum team. Scrum is facilitated by a Scrum Master who is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables. The key role of a Scrum Master is to protect the Development Team and keep it focused on the tasks at hand.

Product roadmap

Product vision Progressive refinement

Project

Project chartering Project Inception Project initiation Queue

Refactoring

Release planning

Release train

Risk

Role

Rule

Scrum

Scrum framework

Scrum Master

Scrum Poker Scrum Team

Its is a consensus-based method for estimating, used to estimate effort or relative size of User Stories. 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. 1.Self-organization is a property of the development team, which organizes itself over time, without being ordered by an external source. 2.Reflects the management philosophy whereby operational decisions are delegated as much as possible to those who have the most detailed knowledge of the consequences and practicalities associated with those decisions. A product or a service that results from a development effort. The Scrum term for iteration. The sprint starts with a sprint planning meeting. At the end of the sprint there is a sprint review meeting, followed by a sprint retrospective meeting. The sprint backlog is the list of work the Development Team must address during the next sprint. The list is derived by selecting stories/features from the top of the product backlog until the Development Team feels it has enough work to fill the sprint. A Sprint Review activity where the product backlog items that are completed will be demonstrated. The intention is to encourage a information-rich discussion between the Scrum team and other sprint review participants. 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 which the product owner would like to accomplish during the sprint. The Sprint Planning meeting takes place at the beginning of each Sprint. The purpose of the meeting is to define the objectives and tasks. 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. "A meeting held at the end of each sprint in which the delivery team shows what they accomplished during the sprint; typically this takes the form of a demo of the new features. The sprint review meeting is intentionally kept very informal. " The abstract measure of effort to implement a story is called a story point. Typically determined by engaging in Planning Poker 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. A behavior whereby team members with available capacity and appropriate skills collectively work (swarm) on an item that has already been started to finish before moving ahead to begin work on new items. 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. T-shaped skills is a metaphor used in job recruitment to describe the abilities of persons in the workforce. The vertical bar on the T represents the depth of related skills and expertise in a single field, whereas the horizontal bar is the ability to collaborate across disciplines with experts in other areas and to apply knowledge in areas of expertise other than one's own. Tacit Knowledge is the kind of knowledge that cannot be easily transferred to another person by means of writing it down or verbalizing it. Tasks are descriptions of actual work that an individual or pair does in order to complete a story. Most tasks are defined to be small, representing no more than a few hours to a day or so of work. A chart that depicts Story, "to do", "in progress", and "done" columns for organizing a team's work. An obligation arised on the part of a software organization when it chooses a design or construction approach that is expedient in the short term but that increases complexity and is more costly in the long term. Stories describe work that must be done to create and deliver a feature for a product. 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.

Self organisation

Solution Sprint

Sprint backlog

Sprint demo

Sprint goal Sprint Planning Meeting Sprint retrospective

Sprint review

Story point Sustainable pace Swarming

Synchronization

T-shaped skills

Tacit knowledge Task Task board Technical debt Technical stories Technique

Test-driven development (TDD)

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test and finally refactors the new code to acceptable standards. A fixed duration of time during which an activity is performed. In Scrum, sprints are time boxed iterations. Time boxing is used as a project planning technique. The schedule is divided into a number of separate time periods (time boxes), with each part having its own deliverables, deadline and budget. Time boxing can be a favorable type of contracting for projects in which the deadline is the most critical aspect and when not all requirements are completely specified up front. A state of having limited knowledge where it is impossible to exactly describe the existing state, a future outcome, or more than one possible outcome. Often considered synonymous with risk but is actually broader in scope because uncertainty includes both risks (negative outcomes) and opportunities (positive outcomes) The things that we are unaware that we dont know. Stories describe work that must be done to create and deliver a feature for a product. The principle of validated learning is defined as a process, where one learns by trying out an initial idea and then measure it to validate what the effect was. From each iteration of trying something is learnt and the next try will succeed better Velocity is a capacity planning tool sometimes used in Agile software development. Velocity tracking is the act of measuring said velocity. The velocity is calculated by counting the number of units of work completed in a certain interval, determined at the start of the project. The main idea behind velocity is to help teams estimate how much work they can complete in a given time period based on how quickly similar work was previously completed. Any activity that consumes resources and produces no added value to the product or service that a customer receives. The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation, and Maintenance. An economically optimal algorithm for scheduling work in an environment where both the cost of delay and the duration vary among the work items. A set of features/options that are specifically declared to not be available in the forthcoming release. Work that has entered the production/development process but is yet to be completed and available to a customer or user. Refers to all assets or work products of a product or service that are currently in the pipeline.

Time box

Time boxing

Uncertainty

Unknown unknowns User story

Validated learning

Velocity

Waste

Waterfall Weighted shortest job first (WSJF) Wont-have features Work in process (WIP)