Question 1

Lean Product Development

Accepted Answer

Lean product development a method for developing products that focuses on increasing visibility through small batches, shortening feedback loops, reducing waste, and continuous improvement. It results in speeding up delivery, reducing lead time and increasing customer value.

Some of the Principles of Lean product development are:

Eliminate waste.
Amplify Learning.
Build change capacity
Fast Feedback through rapid development
Empower the team
Build integrity in
See the whole

Also see: Lean Thinking, Lean Waste

Question 2

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 3

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)

See also: Self-Managing Teams

Question 4

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).

Question 5

Story Mapping

Accepted Answer

User Story Mapping is a holistic visual representation of how all the user stories fit into the overall user experience.

A 2-Dimensional story map can help understand the sequence of activities of a system, identify gaps in the product backlog, and plan releases that deliver customer value.

The goal is not to create a raodmap, rather, change people’s mindset from gathering and writing detailed requirements to building shared understanding.

A sample User Story Map: (Source: Jeff Patton)

Question 6

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 7

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 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

Minimum Viable Product (MVP)

Accepted Answer

Minimum Viable Product is a version of a new product with just enough (minimum) features to be usable by early customers. If early adoptors can use our product to solve their core need, then they can provide feedback for future product development of the product.

MVP aims to validate key assumptions / hypothesis about the product idea and achieve most validated learning possible for the least amount of effort / investment.

The purpose of releasing an MVP could be:

MVP doesn't have to be dud. It can be Exceptional as well.

After validation of the idea through MVP, the Product is supposed to be improved incrementaly based on customer's feedback - each increment being more valuable than the previous verisons.

Question 10

Coaching

Accepted Answer

Coaching is a form of development intervention in which a coach, supports a learner or a coachee in achieving a specific personal or professional goal.

The coach provides a structure, accountability and space within which the coachee's wisdom emerges and capability grows to:

clarify a problem they like to solve/address,
identify possible solutions to try, and
take action to address the matter.

Providing answers, opinions, and telling others what to do is NOT coaching.

Unlike a mentor, a coach doesn't need to be an expert in the field in which a coachee aims to excel.

See also: The Scrum Master as a Coach

Question 11

Spike

Accepted Answer

Spike (concept originating from Extreme Programming) may be considered a type of a Product Backlog Item that is usually focused on research, exploration and investivation activity.

The purpose of a spike may be to explore the technical feasibility or create a quick proof of concept to gain better understanding about a particular requirement.

Since a Spike does not directly deliver stakeholder value, and due to unknown nature of the work involved, a spike should be subjected to a time-box.

The knowledge gained during this time-box (effort spent) should be presented at the Sprint Review and based on it the Product Owner may decide whether to puruse this feature / technology further or not. If the Product Owner decides to pursue it further, they may write a fresh Product Backlog Item and add it to the Product Backlog.

Also see: Product Backlog Item, User Story, Product Backlog Refinement

Question 12

Splitting User Stories

Accepted Answer

When a big Product Backlog Item (or a User Story) can not be implemented within one Sprint, it's best to split it in to multiple smaller (thin) slices. Then the team can pick up these smaller items one by one for implementation over number of Sprints.

Smaller Product Backlog Items are easier to implement, require less effort, less investment and allow to get early feedback, reducing risk and maximizing learning.

For Example: A brand new ecommerce portal requires ways to accept online payments. The Accept Online Payments Product Backlog Item is pretty big in itself. It can be splitted (sliced) in few ways as below:

"Accept Online Payments" can be split in to four pieces as below:

1a. "Accept Visa" can be split in to pieces further:

The PBI 1aa. can be further split based on APIs available from Visa.

Also see:

User Story, Product Backlog Item

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

Antifragile

Accepted Answer

When exposed to volatility and shocks, Fragile things break, Robust things resist it, Antifragile things benefit from it.

Antifragile systems thrive and grow when exposed to volatility, randomness, disorder, risk and uncertainty instead of breaking under their pressure.

In his book Antifragile, author Nassim Nicholas Taleb describes Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better.

Nassim proposes rules for moving from the fragile toward the antifragile, through reduction of fragility or harnessing antifragility.

Antifragility (and fragility) can almost always be detected using a simple test of asymmetry: anything that has more upside than downside from random events (or certain shocks) is antifragile; the reverse is fragile.

Lessons to be antifragile:

Fragile items break under stress, antifragile items get better from it.
In order for a system to be antifragile, most of its parts must be fragile.
Antifragile systems work, because they build extra capacity when put under stress.

Question 15

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 16

Return on Investment (ROI)

Accepted Answer

Return on Investment (ROI) is a ratio of the gains from an investment over the investment.

ROI = Gains / Investment

For Example: Implementing a set of features required an investment of $100K, and after implementing those features, the product generated additional $300K in profitability.

In this case the ROI = ($3,00,000 / $1,00,000) = 3.

Question 17

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.

Question 18

Tools

Accepted Answer

The purpose of using any tool in a Scrum implementation is to create transparency.

Which tool is used by a team / org does not matter, as long as it's simple and serves the team's purpose.

From surveys, the most teams (83%) use MS Excel or Google Sheets.

Here is a list of some of the tools used:

MS Excel / Google Sheets
Jira
Trello
Digital.ai
MS Azure DevOps
Rally
IBM Rational

there are about a million tools out there etc.

As long as one knows how to use Excel well, one should be able to use the tool used by their organization.