Question 1

Acceptance Criteria

Accepted Answer

Acceptance criteria (AC) is the set of criteria that define / limit the functional scope of a Product Backlog Item. It guides how a particular feature may be used from an end user’s perspective. If the implementation of a functionality meets the Acceptance Criteria the Product Backlog Item (PBI) or a User Story would be accepted by the user, the customer, or the Product Owner.

Acceptance critieria for each PBI would be different and unique as it relates to the functional scope of that PBI.

Acceptance criteria is different from Definition of Done which focuses on Quality and Completeness. DoD is common across the PBIs and is consistent for the Product.

Refer for More: Tips to Write Effective Acceptance Criteria

Question 2

Collective Ownership

Accepted Answer

The practice of Collective Ownership of a Product / Code / Solution means the entire team collectively owns building of the solution / product and that every member has a responsibility to contribute to it.

It taps in to collective intelligence of the team members and reduces risk.

In Scrum the developers have collective ownership of the product being built.

Question 3

Cross-Functional Team

Accepted Answer

A Cross-Functional team comprises of people with all the needed functional skills needed to translate the work planned for a sprint in to a Done Increment without being dependent on people outside this team.

While experts at their primary skill, members of a cross-functional team may also develop competence at a secondary skill (not necessarily all the skills) to become more valuable for the team.

Also Refer: Scrum Team

Question 4

Cumulative Flow Diagram (CFD)

Accepted Answer

A Cumulative Flow Diagram (CFD) is a graph to visualize the flow of value through a system. A CFD is a valuable tool to Inspect - visually, the value delivered, work in progress and the amount of work in the backlog.

The X-axis represents Time / Timeline.

The Y-axis could represent multiple variables simultanously such as - Number of Work Items Completed, Work-In-Progress and the amount of work in the backlog.

These different variables are represented using different colors in a graph that either goes up or stays stable throughout the duration for which the graph is plotted.

It helps to visually 'inspect' inconsistencies in the workflow / process, built up of work in the backlog, and to help adapt processes.

The CFD helps identify the:

Cycle time
Throughput and
Work in Progress.

The CFD may also be used as a complimentary practice for Scrum Teams to reveal their planning, execution and value delivery cadence.

Also see: Burn Down Chart, Burn Up Chart

Question 5

Daily Scrum

Accepted Answer

The Daily Scrum is a 15-minute time-boxed event for the Developers of the Scrum Team. During the Daily Scrum, the developers inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

It is held at the same time every working day of the Sprint.

Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.

The Scrum Master and the Product Owner are not required (participants) at the Daily Scrum. While they can observe, they do not interrupt or interfere.

Question 6

Definition of Done

Accepted Answer

The Definition of Done (DoD) is a set of criteria for quality and completeness of the increment, against which the increment is evaluated.

DoD creates transparency and shared understanding of what work was completed as part of the Increment.

The Definition of Done is common across Product Backlog Items and consistent for a Product.

The DoD is established before the work begins and is expanded (as needed) over the period.

The Definition of Done is different from the Acceptance Criteria (AC). The AC is focused on functional scope of one PBI where as the DoD is focused on quality scope of the entire product.

See also: Increment, Acceptance Criteria

Question 7

Developers

Accepted Answer

Developers are cross-functionally skilled people in the Scrum Team who contribute to develop a usable Increment each Sprint.

The Developers are accountable for:

Planning the Sprint work;
Execution and adapting their plan each day toward the Sprint Goal;
Creating a quality Increment that adhers to their Definition of Done;
Holding each other accountable as professionals.

Question 8

Done

Accepted Answer

When a Product Backlog Item meets the Definition of Done an Increment is recognized as Done.

See more: Definition of Done

Question 9

Forecast

Accepted Answer

Forecast is selecting how much work can be completed within a Sprint. Developers use empirical information to forecast their Sprint scope during Sprint Planning. Forecast is not a guarantee.

Also see: Sprint Planning

Question 10

Increment

Accepted Answer

The increment is the sum of all the Product Backlog items completed during a Sprint and the increments from previous Sprint.

Increment creates transparency of the value created to date.

Example: If a Scrum team is writing a book, a chapter of the book could be an increment. Another example could be iPhone 14 as an increment.

Also see: Incremental Development

Question 11

Incremental Development

Accepted Answer

Incremental Development is a software development approach that focuses on delivering value (even if small portion of the overall product) early to seek customer's feedback. Based on the customer feedback, builds additional features on earlier versions of the product. Each increment adds up in value and is more valuable from the previous increment.

Also see: Increment

Question 12

Lean Thinking

Accepted Answer

Lean thinking is an organizational approach, based on the view that non-value-added activities (waste) in products and services impedes customer value creation. It focuses on ways to organize human activities to effectively deliver value while reducing muda (waste), mura (unevenness) and muri (overburden).

Lean Thinking ideas emerged from studying Toyota Production System (TPS). It was found that if every employee is trained to identify wasted effort, steps and time in their own work and to work together as a team to improve processes by eliminating such waste, the resulting culture (basic thinking, mindset & assumptions) will deliver more value effectively while improving team work, their capability, and motivation.

Also see: Lean Waste, Lean Product Development, Kaizen, PDCA

Question 13

Product Backlog

Accepted Answer

The Product Backlog is one of the Scrum Artifacts.

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.

The Product Backlog is an emergent artifact and is never complete. It is constantly changing to reflect the ever-changing needs of the stakeholders.

The Product Backlog is owned by the Product Owner.

The Product Backlog is ordered by value, with the most valuable items at the top of the list. The Product Owner is responsible for ordering the Product Backlog, but may do so with input from the Development Team and other stakeholders.

Key benefits of a Product Backlog include:

Transparency of product requirements (upcoming work) for all stakeholders
The ability to constantly adapt the product to changing needs
Improved communication between the Product Owner and the Development Team
A clear order of product requirements based on value.

Question 14

Product Backlog Item (PBI)

Accepted Answer

Items in the Product Backlog are called Product Backlog Items (PBIs) in Scrum.

A PBI may represent any need such as: Business Functionality, Technical Enhancement, Change request, Defect, Support ticket, etc.

Scrum does not prescribe any specific way to write PBIs. Many teams find lightly written User Stories (a practice from XP Engineering Practices) to be a useful practice.

Suggested Reading:

Also see:User Story, Spike, Technical Debt, Product Backlog Refinement

Question 15

Product Backlog Refinement (PBR)

Accepted Answer

Product Backlog Refinement (PBR) is the act of breaking down, adding details (such as: description, order and size) and further defining Product Backlog items into smaller more clearer items.

Product Backlog Items may be added, deleted and reordered.

The Product Backlog Refinement is a joint effort between the Product Owner and the Developers. The Product Owner is Accountable for the PBR.

PBR is not a prescribed scrum event, rather an ongoing activity.

PBR used to be called Product Backlog Grooming in older Scrum Guides.

Question 16

Product Goal

Accepted Answer

"The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against." - Scrum Guide 2020.

Crafted and Communicated by the Product Owner, the Product Goal is the long-term objective, a specific and measurable benefit or outcome a product should create.

The Scrum Team is focused on one product goal at a time. They must fulfill (or abandon) one product goal before taking on the next.

Question 17

Product Owner

Accepted Answer

The Product Owner is accountable for maximizing the value of the product/service being built.

The Product Owner owns the decisions related to funds, works with the stakeholders and steers the direction of the product to optimize the outcomes and impact for the customers.

Question 18

Progressive Refinement

Accepted Answer

In Scrum, the product is built incrementally and iteratively. As the product is used in the market, as new needs are identified, the Product Backlog emerges to adapt to the new needs.

Instead of refining the Product Backlog all at once at the begining, the Product Backlog is progressively refined over the period of development to accomodate the emerging needs.

Question 19

Scrum Artifacts

Accepted Answer

A Scrum team needs access to shared information in order to effectively perform its activities and Inspect the information.

Scrum Artifacts are designed to maximize transparency of key information. Thus, everyone inspecting them has the same basis for adaptation.

The three Scrum Artifacts represent work or value:

Product Backlog
Sprint Backlog
Increment

Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured.

Question 20

Scrum Events

Accepted Answer

Scrum combines four formal events within a containing event, the Sprint. (That makes total 5 Scrum Events)

Four formal Scrum Events are:

Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective

Scrum Events are a formal opportunity to inspect and adapt the Scrum artifacts. Missing any event(s) results in lost opportunities to inspect and adapt.

Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.

Scrum events are designed to provoke change

Question 21

Scrum Framework

Accepted Answer

Scrum is a light weight framework that helps people generate value through adaptive solutions for complex problems.

Scrum Framework is built on empiricism and lean thinking.

Scrum employs an iterative, incremental approach to optimize predictability and to control risk.

As a framework, Scrum is not prescriptive, but only offers few elements and the rules associated with these elements.

Further Reading: A short summary of the Scrum Framework

Question 22

Scrum Master

Accepted Answer

The Scrum Master is responsible for promoting and supporting Scrum. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

Scrum Master is not a new name for the traditional (Project) Manager. Rather, the Scrum Master is a true leader who leads through serving.

The Scrum Master Educates, Coaches, Mentors and Facilitates to higher performance and agility.

The Scrum Master serves the Developers, the Product Owner and the Organization.

Also see: Scrum Master as a Coach, Scrum Master as a Leader

Question 23

Scrum Team

Accepted Answer

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

The Scrum Team consists of one Scrum Master, one Product Owner, and Developers.

Scrum Teams are cross-functional, self-managing, small (10 members or less).

Also Refer: Self-Managing Team, Cross-Functional Team, Feature Teams

Question 24

Self-Management

Accepted Answer

When a team is empowered to decide who does what, when, and how - it can be termed as a Self-Managing Team. The self-managing team is responsible and accountable for all or most aspects / decisions of planning, producing and delivering value.

To enable people or teams in an organization to self-manage, the structure of the organization /and the team must be relatively flat. The team must be shielded from hierarchy. People must have the needed empowerement to make necessary decisions related to their work.

Some of the well known large-scale Organizations that are successfully operating and growing based on the principles of Self-Management:

Morning Star (Tomato Processor, USA)
Buurtzorg (Healthcare, The Netherlands, Worldwide)
Semco Group (Manufacturing, Brazil)
Patagonia (Outdoor Apparel, USA)
Haier Group (Consumer Durables, Appliances, China)