Question 1

Cycle Time

Accepted Answer

Cycle Time in Scrum refers to the time it takes for a Product Backlog Item or a task to be completed from the moment work starts on it until it's considered done. It provides valuable insights into the Scrum team's efficiency in delivering work items. A shorter cycle time generally indicates better efficiency and faster delivery.

A shorter cycle time means the team is working more swiftly and getting things done quickly, while a longer cycle time might indicate potential bottlenecks or areas for improvement.

Slicing the PBIs thinner usually helps keep the Cycle Time low. If your team is consistently able to sliced the PBIs to a point where most PBIs can be completed within a day, in such cases there would be usually no benefit of measuring Cycle Time.

Question 2

Cynefin

Accepted Answer

The Cynefin Framework is a decision making framework, that recognizes the casual differences between systems and proposes new approaches to decision making in complex environemtn.

Cynefin is a sense-making model not a categorization model.

If the question is How do we make sense of the world, so we can act in it.

In nature, there are 3 basic systems: Ordered Systems, Choatic Systems and Complicated Systems. Once people know in which domain / system they are in, they can choose the domain specific response.

Question 3

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 4

Defect Density

Accepted Answer

Defect Density is a metric used to assess the quality of the software produced by the team. It represents the number of defects or bugs discovered in the product relative to its size or complexity.

Defect Density = Number of Defects / 1000 Lines of Code (KLOC)

A lower defect density indicates better development practices resulting in the team delivering higher software quality and better user experience.

Defect Density acts as a risk indicator for the software. A higher density suggests that the product might be more prone to errors, adding new features would become more difficult, transparency would reduce and could lead to user dissatisfaction.

In Manufacturing industry, the Defect Density is calculated as the number of defective units of a product produced against the total number of units manufactured.

Question 5

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 6

Definition of Ready

Accepted Answer

The Definition of Ready isn't a practice defined in the Scrum Guide. However, some teams have created a checklist while refining the PBIs, to ensure that the PBIs entering the Sprint Planning are well refined, clear and free from dependencies.

Caution must be excercised to avoid the definition of ready from becoming an extensive list that eventually hinders the emergence of right details later.

The Scrum Guide hints about readiness of PBIs, however doesn't prescribe any such DOR criteria:

Question 7

Design Thinking

Accepted Answer

Design Thinking is a human-centered approach to solving complex problems. Design Thinking consists of five key steps to creating better solutions:

Emphathize: Understand needs of the end user
Define: Define end user / customer persona(s)
Ideate: Brainstorm ideas, narrow down possible solutions
Prototype: A visual-interactive mock-up of an idea, created to test an early stage idea, and gather user's feedback.
Test: Invite feedback, insights and analyze the effectiveness of the chosen prototype.

Question 8

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 9

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 10

Empiricism

Accepted Answer

Empiricism asserts that knowledge comes from experience and making decisions based on what is observed (Most recent, Factual, Information).

Scrum is founded on the three pillars of Empiricism: Transparency, Inspection and Adaptation.

Transparency: Scrum artifacts create transparency of needed information. Transparency enables Inspection. Inspection without transparency is misleading and wasteful.

Inspection: Four formal Scrum events enable opportunities for inspection and adaptation. Inspection of the information enables to know if the actual resutls match or deviate from the desired results.

Adaptation: Four formal Scrum events enable opportunities for inspection and adaptation. If during the inspection, the actual resutls is found to deviate from the desired results, we can adapt the input, so the desired results can be achieved.

Benefits: Empirical evidence, grounded in factual data from observations and what has already happened, guides teams towards objective and informed decision-making. It minimizes the impact of personal biases and opinions, enhancing the Transparency, Speed and Effectiveness of the decision making process.

Examples: Decisions where empiricism can be used:

a) How many Product Backlog Items should the team pick in the next sprint?

Question 11

Estimation

Accepted Answer

Estimation in product development is used to guess how much work can be completed and by when.

Various estimation techniques such as: Story Points, Planning Poker, T-Shirt Sizes, etc.. allow a team to relatively size the effort required to complete an item.

Estimation involves assumptions of the impact of various variables to complete an item such as:

Effort needed by the team (various functional experts) to complete an item
Complexity of the task
Unkonwns involved
and so on.....

While, Estimation may help to create a shared understanding about the work at hand among the developers, Product Owner and stakholders (optional), it usually takes away disproportional amount of time which is a big waste.

Assumptions based approaches are weak ideas at their best.

A much better and effective approach to forward looking decision making in complex environment is decision making based on Empiricism.

See also: Empiricism

Question 12

Evidence Based Management

Accepted Answer

Evidence-based Management refers to a decision-making approach that relies on objective and verifiable evidence, data, and research to inform and guide managerial actions and choices within an organization.

By using rigorous analysis and empirical evidence, this approach seeks to minimize biases and subjectivity, leading to more informed and effective decision-making.

It emphasizes the integration of scientific findings and real-world factual data to optimize organizational processes, enhance performance, and achieve desired outcomes.

Also see: Empiricism

Question 13

Extreme Programming (XP)

Accepted Answer

Extreme Programming (XP) is a light weight framework intended to improve software quality, responsiveness to changing customer needs and achieve higher quality of life for the team.

Aligned with the Values and Principles of the Manifesto for Agile Software Development, XP advocates frequent releases in short development cycles, intended to improve productivity and introduce regular checkpoints to adopt to the changing customer needs.

XP improves a software solutions in five essential ways:

Communication: XP favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback.
Simplicity: Simple system design with very simple code could be easily understood by most programmers in the team. XP starts with the simplest solution useful to the customers today. Extra functionality can then be added later.
Feedback: Short Feedback cycles from the System: ( by writing unit tests, or running periodic integration tests), Feedback from the Customer (Acceptance tests gets concrete feedback about the current state), and Feedback from the Team (team directly gives an estimation of the time that it will take to implement customer needs) help with communication and maintain simplicity.
Respect: Respect is a key value for programmers, which includes respect for others and self. Committing changes that break compilation, or delay the work of peers is not a sign of respect towards others. Members can show respect for their own work by striving for high quality and actively seeking feedback.
Courage: Courage enables developers to feel comfortable with designing solutions for what's important today and refactoring their code when necessary. Courage is to remove source code that is obsolete. Courage also means persistence to solve complex problem.

The original twelve practices are listed below:

The Planning Game
Small Releases
Metaphor
Simple Design
Testing
Refactoring
Pair Programming
Collective Ownership
Continuous Integration
40-hour week
On-site Customer
Coding Standard

Question 14

Facilitation

Accepted Answer

Facilitation is an intervention through which a group improves the way it communicates, examines and addresses problems, and makes decisions.

A neutral and unbiased facilitator would create the environment, design the structure and may use various facilitation techniques to help a group improve it's effectiveness.

Question 15

Feature Teams

Accepted Answer

A feature team, is a cross-functional, cross-component team dedicated to building end-to-end customer features one by one.

A feature team usually consists of members from all areas of a system, such as: business, development, operations, product, and technology.

Building a feature team requires that team members are empowered to work on all the components of the system that avoids depending on other teams. This speeds up the development work and avoids waiting, delays and hand-offs significantly increasing the value throughput.

Feature teams will benefit from having Full stack engineers / generalizing specialists in the team. However, it's not expected that every team member knows every skill.

https://malcolm-en-gb.s3.eu-west-1.amazonaws.com/instances/iBXIwUgCog/resources/5nVvAvL5Oj/Feature%20Teams.png (Feature Teams)

Source: Feature Teams Primer by Craig Larman and Bas Vodde

Question 16

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 17

Framework

Accepted Answer

A framework could be a collection of guidelines, rules and elements that provide a structure and boundary but not the prescription to achieve something.

For Example: The game of Chess (a framework) offers:

The chess board (8x8 squares)
The chess pieces (Material)
The rules about how each piece is placed, how each piece moves across the board

A chess player gets to decide their strategy, which piece they move and where, how they secure their king and how they use their queen. The game of the Chess doesn't prescribe any of this.

Question 18

Impediment

Accepted Answer

An Impediment is anything that prevents a team from moving forward, and from getting work Done. Also knowns as a Blocker.

Impediments add delay and overprocessing (form of waste) to a team's work.

Impediments could be intra team, inter team and organizational.

Impediments can be effectively addressed when team members facing an impediments quickly announce it and create transparency about it.

Question 19

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 20

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 21

Information Radiators

Accepted Answer

Any tools / means that radiate out the information by making it visible and transparent to other team members, stakeholders and relevant parties. Usually Big Visible Charts, Large Displays, WhiteBoards, etc. may be used to make information visible.

Information such as: Product Backlog, Sprint Backlog, Defects Open, Impediments, Status of Build etc. may be made available through information radiators so that the team members can regularly inspect and adapt as needed.

Question 22

Kaizen

Accepted Answer

Kaizen is a Japanese terms referring to incrementally achieving excellence through the relentless and endless pursuit of perfection.

In a business context Kaizen is continuous improvement of processes, operations and functions involving all employees.

Kaizen is Change for the Better.

Also see: Lean Thinking, Lean Waste, A3 Problem Solving, Lean Product Development, Value Stream Mapping.

Question 23

Kanban

Accepted Answer

Kanban is a lean method, a framework to visualize work and improve the flow of value through the system.

Initiated by Toyota as part of the Toyota Production System, Kanban (in Japanese) is a visual card used as a scheduling system, showcasing the essential information and progress of the work through the product development system.

Following four essential practices help optimize the flow of value:

Visualize the workflow
Limit work in progress
Manage flow
Make process policies explicit

Through pull based movement of the work, Kanban helps achieve evolutionary improvements in process and product.

Question 24

Key Performance Indicators (KPI)

Accepted Answer

A performance indicator is a quantifiable measure of performance over time for a specific strategic objective.

Key Performance Indicators (KPIs) are performance indicators most critical to an organization.

KPIs provide goals for teams to work towards, milestones to gauge progress, and insights that help employees across the organization make effective decisions. From sales and marketing to finance and HR, KPIs help every area of the business move forward at the strategic and operational level.

Question 25

Lead Time

Accepted Answer

Lead Time is the time it takes from identifying a need (could be a customer problem, feature request, defect raised, technical enhancement etc.) to making a solution available to customers.

Having a shorter the lead time equates to more responsiveness.

To reduce the lead time in Scrum:

A Self-Managing and Cross-Functional Scrum Team further improves the ability to improve the rate of value delivery hence a shorter Lead Time.