Question 1

Burn Up Chart

Accepted Answer

A Burn Up Chart is a graphical representation used to track how much work has been completed against the time passed.

The graph starts at 0-0 at the beginning of the Sprint and will tend (Burn) up towards Right as the days pass and top as the work is completed.

A Burn Down Chart is a more effective tracking approach compared to the Burn Up Chart.

Also see: Burn Down Chart, Comulative Flow Diagram (CFD)

Question 2

Agile Coaching

Accepted Answer

A coaching intervention that is focused on helping teams, leaders and organizations to improve their ability to gracefully change / adapt to changing needs, may be identified as Agile Coaching.

Question 3

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 4

Business Agility

Accepted Answer

Business agility is the capability to quickly change or adapt to changes in a business. Building Business Agility is an ongoing process and not a one-time event. Business agility can also be referred to as organizational agility, or adaptive business.

Business agility is the ability of a company to adjust to changes quickly. In business, agility involves the ability to change one’s strategy, operational model, and operating processes in response to internal and external changes.

This changes can be external, such as changing market conditions or government regulations. Internal changes can also have a big impact on business agility, such as disrupting the company culture or stakeholder loyalties, swiftly reacting to customer demands and quickly launching new products.

Organizations that have a high level of business agility will be better suited to take advantage of emerging opportunities, that will allow them to grow and overcome competition.

Question 5

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 6

Agile Software Development

Accepted Answer

The [Agile Manifesto] (https://agilemanifesto.org) first coined the term 'Agile Software Development'. It refers to the way of developing Software (or Products / Services / Value) that is responsive to the customer's changing needs.

It is also referred as 'Agile Development' to refer to much broader applications outside the field of Software Development.

Question 7

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 8

Complex System

Accepted Answer

A complex system is a collection of interdependent parts, modules, and/or variables. A perfect understanding of individual parts does not automatically convey a perfect understanding of the whole system's behaviour.

The state of a complex system can't be predicted due to the reason that it's parts dynamically change and every change influences the state of other parts and the overall system.

Is your work environment Obvious, Complicated, Complex or Chaotic?

Please analyze your current work environment, and identify which of these variables change in your work environment?

Customer Needs
Technology
Talent/People
Competition
Organizational Goals
Marketplace
Government Regulation
All of the Above

If you answered All of the above (or many of the above) your work environment is Complex.

Question 9

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 10

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 11

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 12

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 13

Pareto Principle

Accepted Answer

The Pareto Principle states, for many events, roughly 80% of results (effects) come from 20% of the inputs (causes). Hence also knowns as 80/20 rule.

While the actual % would change based on situation and context, it is almost always true that:

a small proportion of the efforts (inputs) towards certain areas generate a larger proportion of results (outputs).

The Pareto Principle provides a useful framework for understanding complex systems and identifying key areas for focus / improvement.

When correctly used by the Scrum Teams, it can help order Product Backlog Items (PBIs) that would yield most value, identify which retrospective improvement idea to pursue among many, optimize resources, and improve overall ROI.

PP

https://malcolm-en-gb.s3.eu-west-1.amazonaws.com/instances/iBXIwUgCog/resources/wcEQPCNkBu/PP.png (PP)

Image source: Interaction Design Foundation

This 80-20 rule can be applied to many areas such as business, learning, finance, sales, marketing, customer service etc.

The Pareto Principle is named after Italian economist Vilfredo Pareto (1848-1923).

Question 14

Sprint Retrospective

Accepted Answer

The Sprint Retrospective is one of the prescribed Scrum Event - an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The Team may inspect their processes, communication and interactions among people, and tools used to identify opportunities to simplify processes, automate steps, reduce any waste, reduce hand-offs etc.

The result of the Sprint Retrospective is improved effectiveness of the Scrum Team and better quality product/solutions.

The end of the retrospective marks the end of the Sprint.

Question 15

User Story

Accepted Answer

A User Story is a story told by the user (of the product) of her/his challenges, or opportunities.

The original intent of the User Story has been that a User Story is to be told not written.

A User Story card is a promise for further communication. Communication that should happen between the Developers and the Customer or Stakeholders to create a shared understanding of the user's needs.

Further Reading:

Writing Effective User Stories Becoming User Centric with User Stories

Also see:

Product Backlog Item, Spike, Technical Debt, Splitting User Stories

Question 16

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 17

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 18

Blocker

Accepted Answer

Blocker is anything that blocks the team from making progress.

Please also see Impediment.

Question 19

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 20

Customer Persona

Accepted Answer

A customer persona is a semi-fictional representation of your ideal prospect (or customer) based on market research and actual data about your present customers. It includes demographic data, behavior patterns, motivations, life-style, behaviors, pain points and objectives.

Customer personas are used to segment your customers into groups, identify their different needs, and tailor your product features or service to each group.

Organizations create customer personas for their product / business to make their offering relevant to their customer needs.