Question 1

Agile Manifesto

Accepted Answer

The Manifesto for Agile Software DevelopmentEstablished in 2001, also referred as Agile Manifesto comprises of four Values and twelve Principles that 17 manifesto authors agreed on to be essential to be adaptable for a team or an organization.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

That is, while there is value in the items on the right, we value the items on the left more.

Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Manifesto Authors: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

Refer: Manifesto for Agile Software Development

Question 2

Agile Mindset

Accepted Answer

Mindset is a reflection of our assumptions, biases, way of thinking, and beliefs that is visible in our choices, decisions and behavior.

An Agile mindset characterizes flexibility and willingness to adapt to changes and unforeseen circumstances.

A person / team having an Agile mindset is:

Curious to learn,
Continuously trying to improve,
Willing to experiment new ideas,
Not hesitant to take risks,
Not running away from challenges,
like growing a muscle,

so that when needs / circumstances change, they are ready to adapt to it.

An Agile Mindset underpins the work of successful agile teams.

On the other hand, someone having a Fixed Mindset would be relatively less flexible, thinks that they know it all, assumes there will be no changes, is not open to learning / feedback, avoid trying new ideas etc.

'Mindset' by Carol Dweck introduced a comparision between a Growth Mindset and a Fixed Mindset and how one can inculcate a Growth Mindset.

https://malcolm-en-gb.s3.eu-west-1.amazonaws.com/instances/iBXIwUgCog/resources/lwCXqAgZas/Mindsets.jpg (Mindsets.jpg)

Also Refer: Agile Mindset by Kamlesh Ravlani

Question 3

Sprint Goal Success Rate

Accepted Answer

The Sprint Goal Success Rate is the percentage of sprints in which the team successfully achieves all the goals they set at the beginning of each sprint. It is a measure of the team's ability to stay focused and complete the planned work during the sprint.

A high success rate indicates that the team consistently meets its goals, while a lower rate indicates they need to analyze their performance and adapt their Sprint Planning and Execution.

However, too much focus on achieving Sprint Goal, may result in team under committing during Sprint Planning and also not being flexible when the customer needs change.

Question 4

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 5

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 6

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 7

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 8

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 9

Story Points Estimation

Accepted Answer

Story Points Estimation technique is based on relative sizing where the team members assume the effort + complexity + Risks (unknowns, penalties, missed opportunity, etc.) to come up a story point number usually based on the Fibonacci series. ( 0, 1, 2, 3, 5, 8, 13, 21, .....)

Product Owner explains a product backlog item, the Developers offer story point estimation based on their current understanding of the work involved, they aggregate the story points offered by developers and based on consensus / average, define a stoy point number for each PBI.

Story Points Estimation technique was invented by Ron Jeffries around year 2000.

In 2019, Ron Jeffries updated his advice on the use of Story Points.

See also: Empiricism

Question 10

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 11

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 12

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 13

Burn Down Chart

Accepted Answer

A burn down chart is a graphical representation of the work left to do versus the time.

If a burn down chart is created at for a two week Sprint having 8 Product Backlog Items (work) in the Sprint Backlog, the X-Axis will have 0 - 10 days and the Y-Axis will show 0 - 8 PBIs.

As the days pass and the work remaining reduces, the graph from the top left will gradually trend (burn) down towards bottom right.

The developers may (choose to) create and update the Sprint burn-down chart to graphically track the progress during the sprint.

The Scrum Master should neither create, nor update the Burn-Down chart, to ensure that the Developers retain the ownership of tracking and monitoring the progress of their Sprint work.

Also see: Burn Up Chart, Cumulative Flow Diagram (CFD)

Question 14

Open Space

Accepted Answer

Open Space is a democratic way to facilitate and organize meetings, conferences, and organizational work involving a large number of people with diverse backgrounds and interest.

Participants opt in to create and manage the agenda of discussions as it emerges to achieve strategic and complex objectives.

Harrison Owen an Open Space Evangelist describes the Four Principles and One Law which guide behavior of participants in Open space.

**The principles are: **

Whoever comes is the right people, which reminds people in the small groups that getting something done is not a matter of having 100,000 people and the chairman of the board. The fundamental requirement is people who care to do something. And by showing up, that essential care is demonstrated.
Whatever happens is the only thing that could have, keeps people focused on the here and now, and eliminates all of the could-have-beens, should-have-beens or might-have-beens. What is is the only thing there is at the moment.
Whenever it starts is the right time, alerts people to the fact that inspired performance and genuine creativity rarely, if ever, pay attention to the clock. They happen (or not) when they happen.
Lastly When it’s over it’s over. In a word, don’t waste time. Do what you have to do, and when its done, move on to something more useful.

The Law of Two Feet, which states simply, if at any time you find yourself in any situation where you are neither learning nor contributing – use you two feet and move to some place more to you liking. Such a place might be another group, or even outside into the sunshine. No matter what, don’t sit there feeling miserable

Question 15

LeSS Framework

Accepted Answer

LeSS (Large-Scale Scrum) is a framework focused on applying the principles, elements, and purpose of Scrum in a large-scale context. Less is Scrum applied to multiple teams building a large product.

Like Scrum, LeSS hits the sweet spot between defined concrete elements and empirical process control.

LeSS offers:

Introduction to LeSS (Large-Scale Scrum) - Shana:

Less Complete Picture by Micheal James, Certified LeSS Trainer:

Question 16

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 17

Cost of Delay

Accepted Answer

Cost of Delay (COD) is a decision making / prioritization framework that helps a Product Owner quantify the economic value impact of building a feature or completing an initiative sooner as opposed to later.

The cost of delay is an efficient decision-making tool that can completely transform the mindset of an organization and resulting ROI. It does so by putting a value lens over the conversation of costs and deadlines, offering full-scenario visualizations of what the most critical tasks really are.

Question 18

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 19

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 20

Net Promoter Score (NPS)

Accepted Answer

Net Promoter Score is a customer loyalty metric used to gauge the likelihood of customers recommending a company's product or service to others.

Customers are asked to rate their willingness to refer the company or their product or service on a scale from 0 to 10.

Based on their responses, customers are classified into three categories: Promoters (score 9-10), Passives (score 7-8), and Detractors (score 0-6).

The NPS is calculated by subtracting the percentage of Detractors from the percentage of Promoters, yielding a score between -100 and 100.

Higher NPS score means the customers are very likely to spread positive word-of-mouth about the company's offerings to others and that can also lead to increased customer retention and business growth.

Agile Glossary

Most popular