Knowledge Is a Currency Of The Universe

Coinstants




Scrum is a framework for agile project management that is used to develop and deliver high-quality products. It is a lightweight and adaptable process framework that enables teams to work together to develop and deliver software or other complex products.

Scrum is based on the following principles:

  1. Empirical Process Control: Scrum uses an empirical approach to process control, meaning that it is based on experience, observation, and experimentation rather than on pre-defined processes.

  2. Self-Organizing Teams: Scrum teams are self-organizing and self-managing. Team members are cross-functional and work together to achieve the project's objectives.

  3. Iterative and Incremental: Scrum projects are executed in iterative and incremental cycles called Sprints. Each Sprint is a time-boxed period of 1-4 weeks, during which a working product increment is delivered.

  4. Time-Boxing: Scrum events, including Sprints, Daily Scrum, Sprint Review, and Sprint Retrospective, are time-boxed. This means that each event has a maximum duration, which helps ensure that the team stays focused and makes progress.

  5. Continuous Improvement: Scrum encourages continuous improvement through the Sprint Retrospective event. The team reflects on the previous Sprint, identifies areas for improvement, and develops a plan for implementing those improvements in the next Sprint.

Scrum also includes three primary roles:

  1. Product Owner: The Product Owner is responsible for defining the product backlog, prioritizing the work to be done, and ensuring that the team delivers value to the customer.

  2. Scrum Master: The Scrum Master is responsible for ensuring that the Scrum framework is understood and followed, and for facilitating the team's progress and removing any obstacles to their success.

  3. Development Team: The Development Team is responsible for delivering the product increment at the end of each Sprint. The team is self-organizing and cross-functional, with members who have the necessary skills to deliver the work.

In summary, Scrum is a flexible and adaptable framework for agile project management that enables teams to work together to deliver high-quality products. It is based on empirical process control, self-organizing teams, iterative and incremental development, time-boxing, and continuous improvement.


Some of the definitions that you should know about scrum is right here:

Agile Estimation:

Agile estimation is a process of agreeing on a size measurement for the stories in a product backlog. Agile estimation is done by the team, usually using Planning Poker.

The Agile Manifesto:

The Agile Manifesto was developed by a group fourteen leading figures in the software industry, and reflects their

experience of what approaches do and do not work for software development.

• Individuals and interactions over processes and tools.

• Working software over comprehensive documentation.

• Customer collaboration over contract negotiation.

• Responding to change over following a plan.

Agile Methodology:

Agile Methodology is an umbrella term for several iterative and incremental software development methodologies. The most popular agile methodologies include: extreme programming (XP), Scrum, Crystal, Dynamic Systems Development (DSDM), Lean Development, and Feature Driven Development (FDD). All Agile methods share a common vision and core values of the Agile Manifesto.

Agile Methods:

Some well-known agile software development methods include:

• Agile modeling

• Agile Unified Process (AUP)

• Dynamic Systems Development Method (DSDM)

• Essential Unified Process (EssUP)

• Feature Driven Development (FDD)

• Open Unified Process (Open UP)

• Scrum

• Velocity Tracking

Agile Modeling:

Agile Modeling is a practice-based methodology for Modeling and documentation of software-based systems. It

is intended to be a collection of values, principles, and practices for Modeling software that can be applied on a

software development project in a more flexible manner than traditional Modeling methods.

Agile Planning Basics:

The four basics of Agile planning are: Product Backlog, Estimates, Priorities and Velocity.

Agile Planning - Estimates:

Estimates answer the question: “How long will it take or how many can we do by a given date?”

Agile Planning – Priorities:

Priorities answer the question: “Which capabilities are most important?”

Agile Planning - Product Backlog:

The Product Backlog answers the question: “What capabilities are needs for financial success?”

Agile Planning – Velocity:

Velocity answers the question: “How much can the team complete in a Sprint?”

Agile Software development:

Agile software development is a group of software development methodologies based on interative and incremental development, where requirements and solutions evolve through collaboration between self organizing team,

cross functional teams.

Burndown Chart:

A Burn down chart is a chart showing how much work remaining in a sprint. Calculated in hours remaining and

maintained by the Scrum Master daily. Business Value: Each user story in the Product Backlog should have a

corresponding business value assigned. Typically assign (L,M,H) Low, Medium, High. Product Owner prioritizes

Backlog items by highest value.

Capacity:

Capacity is the Number of Teammates (Productive Hours x Sprint Days). Example: Team size is 4, Productive

hours are 5, Sprint length is 30 days. Capacity = 4(5x30) = 600 hours.

Chickens:

Chickens are the people that are not committed to the project and are not accountable for deliverables.

Daily Scrum Meeting:

The Daily Scrum Meeting is a minimalist status meeting, time-boxed to fifteen minutes. Its purpose is to ensure

that questions are answered quickly, that issues are identified and addressed quickly, and to provide Team members with a common understanding of how the Sprint is progressing. The ScrumMaster facilitates this meeting.

Three questions asked: “What have you done since last daily scrum?” “What will you do before the next daily

scrum?” “What obstacles are impeding your work?”

Defect:

A defect is a failure or bug of the product to behave in the expected fashion. Defects are stored in a bug-tracking

system, which may or may not be physically the same system used to store the Product Backlog. If not, then

someone (usually the Product Owner) must enter each Defect into the Product Backlog, for sequencing and

scheduling.

Done:

The term Done is used to describe a product increment that is considered releasable; it means that all design,

coding, testing and documentation have been completed and the increment is fully integrated into the system.

Epic:

An Epic is a very large user story that is eventually broken down into smaller stories; epics are often used as place

holders for new ideas that have not been thought out fully. Impediment: Anything that prevents the team from

meeting their potential. If organizational, it is the Scrum Master’s responsibility to eliminate it. If it is internal to

the team, then they themselves should deal with it.

INVEST criteria for User Stories:

INVEST: Independent, Negotiable, Valuable, Estimatible, Small, Testable.

Pigs:

Pigs are the people who are accountable for project’s success.

Planning Poker:

Planning poker is a game used to apply estimates to stories. It uses a voting approach designed to avoid influence

bias.

• How it Works:

1. Each estimator selects a set of cards.

2. Facilitator reads item to be estimated, and moderates a brief discussion to clarify details.

3. Facilitator calls for estimates. Each estimator places estimate face down, hiding the value.

4. Facilitator calls for vote, and all estimators turn over cards at the same time.

5. If all cards agree, their value is recorded as the estimate.

6. Otherwise, facilitator asks high and low estimators to explain their reasoning, and moderates a brief discussion to clarify issues.

7. Repeat 3-6 until estimates converge.

Product Backlog:

The Product Backlog is the set of all un-implemented Product Backlog Items (requirements, in the form of

Stories and Defects) that have not been assigned to the current Sprint. Unlike the Sprint Backlog, there is no

requirement that all PBIs be assigned a rank.

Product Owner:

The Product Owner is the keeper of the requirements. He provides the “single source of truth” for the Team

regarding requirements and their planned order of implementation.

In practice, the Product Owner is the interface between the business, the customers, and their product related

needs on one side, and the Team on the other. He buffers the Team from feature and bug-fix requests that come

from many sources, and is the single point of contact for all questions about product requirements. He works

closely with the team to define the user-facing and technical requirements, to document the requirements as

needed, and to determine the order of their implementation. He maintains the Product Backlog (which is the repository for all of this information), keeping it up to date and at the level of detail and quality the Team requires.

The Product Owner also sets the schedule for releasing completed work to customers, and makes the final call as

to whether implementations have the features and quality required for release.

Release Backlog:

The Release Backlog is the same as the product backlog. May involve one or more sprints dependent on determined release date.

Retrospective Meeting:

The Retrospective meeting is held after the Sprint Review meeting. Its purpose is to provide the Team an opportunity to learn, and therefore improve, from the experience of the just-concluded Sprint. It answers the following

questions:

• “What worked well, that we should do again?”

• “What didn’t work well?”

• “What changes we should make for next time?”

Scrum = Visibility + Flexibility.

Scrum Artifacts:

The three Scrum Artifacts are the Sprint Backlog, the Product backlog, and the Burndown chart.

Scrum Development:

Scrum Meetings:

The three Scrum meetings are the Sprint planning meeting, the Daily Scrum Meeting, Sprint Review meeting,

and the Retrospective meeting. Each time box has a specified start and duration, and work is not allowed to

extend beyond the duration.

Scrum Process:

Sprint planning --> Product backlog --> Sprint Backlog --> Daily Scrum --> Sprint --> Shippable Product -->

Sprint Retrospective --> Product Backlog… etc

Scrum:

Scrum is a lightweight process framework for agile development, and the most widely-used one.

ScrumMaster:

The Scrum Master is the keeper of the process. He/she is responsible for making the process run smoothly, for

removing obstacles that impact productivity, and for organizing and facilitating the critical meetings.

Self-Organizing:

Teams are self-organized meaning they have both responsibility & authority. They are all motivated by a common goal.

Single Wringable Neck:

This is the Product Owner.

Sprint Backlog:

The Sprint Backlog is the set of Product Backlog Items, or PBIs (Stories and Defects) planned for implementation in a Sprint. The items in the Sprint Backlog must be ranked in the desired order of implementation (a

Product Owner responsibility). The ranking reflects both the urgency (value) of the item, and any dependencies

that exist between items.

Sprint Planning Meeting:

The ScrumMaster facilitates the Sprint Planning Meeting, which kicks off the Sprint, and which is attended by

the team members and the Product Owner. The purpose of this meeting is to select from the Product Backlog

those Product Backlog Items (PBI’s) the Team intends to implement in this Sprint.

Sprint Review Meeting:

The Spring Review meeting (also called Sprint Demo) held at the end of the Sprint. The team demonstrates the

Sprint’s completed Product Backlog, to the Product Owner and other interested parties. This meeting gives the

Product Owner a final chance to make a go/no-go release decision, and gives the Team members a chance to

show off their work.

Sprint Task:

A Sprint Task is a single small item of work that helps one particular story reach completion.

Sprint:

the basic development cycle for a project. Most often a sprint is 2-4 weeks, however, different organizations and

projects select Sprint lengths that best meet their needs.

Stakeholders:

Anyone who needs something from the team or anyone who the team needs something from. Examples: Executives, Auditors, Security specialists, Enterprise Architects, Support engineers etc.

Story points:

A Story Point is a simple way to initially estimate level of effort expected to develop. Story points are a relative

measure of feature difficulty. Usually scored on a scale of 1-10. 1=very easy through 10=very difficult. Example:

“Send to a Friend” = 2, “Shopping Cart”=9

Story Template:

A Story Template looks like this: “As a “user” I want “function” so that “result”. Example: As a user, I want to

print a recipe so that I can cook it.

Task Board:

A task board is a white board containing the teams Sprint goals, backlog items, tasks, tasks in progress, “DONE”

items and the daily Sprint Burndown Chart. The Scrum meeting is best held around task board & visible to

everyone.

Team:

The Team is a self-organized and cross functional group of people who do the hands-on work of developing and

testing the product. They are responsible for producing the product, it must also have the authority to make

decisions about how to perform the work. Team is 7+/-2 members.

Technical Story:

Technical stories are the requirements that do not represent user-facing features, but do represent significant

work that may support user-facing features.

Three Scrum Roles:

The three Scrum roles are the ScrumMaster, the Product Owner & the Team.

Time box:

A Time box is a span of time of fixed duration, dedicated to a particular purpose, whose boundaries are strictly

enforced. Scrum defines several “official” time boxes, such as the Sprint and critical meetings, but the concept of

a time box is an important theme that permeates scrum projects.

User Story:

A User story describes a desired feature (functional requirement) in narrative form. It is usually contains a name,

description, screen and external documents, and information about how the implementation will be tested. User

stories are usually written by the Product Owner, and are the Product Owner’s responsibility.

Velocity:

Velocity is the rate at which team converts items to “DONE” in a single Sprint. – Usually calculated in Story

Points.



Second part in detail:


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.


No comments:

Post a Comment

Popular Posts