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

Antipattern

Accepted Answer

An antipattern is solution applied to a particular problem that is considered harmful or undesirable, but is used on a regular basis.

An antipattern can be applied to a process, product design, company policy of an org, etc. A key characteristic of antipatterns is that they are used in situations where other, better, alternatives exist.

Antipatterns can include such practices as over-engineering, reinventing the wheel, establishing too many dependencies, overcomplicating the situation and adding more complexity to a situation.

Question 3

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 4

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.

Question 5

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 6

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

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 9

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 10

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.

Question 11

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 12

North Star Metric

Accepted Answer

The North Star Metric (created by Sean Ellis):

Centers on customer value from your product.
It's a single metric, helps create focus.
Clear and simple, it unifies communication.
Aims for lasting value, often through habit formation.
Aligns with and encourages progress towards your vision/mission.
Based on data, not opinions.
Drives action in response to its fluctuations.
Can help forecast long-term business success.

In the context of Scrum, many Product Owners identify their Product Goal as a North Start Goal to achieve.

Here are few Real-World examples:

https://malcolm-en-gb.s3.eu-west-1.amazonaws.com/instances/iBXIwUgCog/resources/uePs40CHnb/North%20Start%20Metric.jpeg (North Start Metric)

[Credits: Unknown]

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

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 15

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 16

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 17

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 18

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 19

Product Vision

Accepted Answer

Product Vision is a high-level, aspirational statement that articulates the long-term direction and purpose of a product. It provides a clear and inspiring picture of what the product is meant to accomplish, who it is intended for, and benefits it provides to the customers.

A well-defined product vision helps build a shared understanding, align teams, and provide clarity on the desired outcomes for the product.

The importance of Product Vision lies in its ability to inspire, motivate, and guide the product team throughout the product development cycle. It serves as a North Star, helping to keep the team focused on what truly matters and ensuring that everyone is working towards the same goals. It also helps to align stakeholders and customers around a shared vision for the product, which can improve communication, reduce conflicts, and increase the chances of success.

The Product Goal is a specific, relatively short-term, and measurable objective that helps the team make progress towards that vision. It guides the team to focus on delivering incremental value.

Examples of Product Vision:

The Amazon Kindle: "To provide customers with the best possible reading experience on a digital device." The Kindle's product vision is centered around delivering a superior reading experience that replicates the experience of reading a physical book as closely as possible, with features like a glare-free display, long battery life, and access to a vast library of e-books.
Google Maps: "To organize the world's geographic information and make it universally accessible and useful." Google Maps' product vision reflects its mission to provide users with accurate and detailed maps that help them navigate the world around them, with features like turn-by-turn directions, real-time traffic updates, and user-generated reviews.
Netflix: "To become the world's leading internet television network, offering a wide range of TV shows and movies to our members." Netflix's product vision centers around providing users with a vast library of high-quality streaming content that they can access anytime, anywhere, with features like personalized recommendations, ad-free viewing, and offline downloads.
Tesla Model S: "To accelerate the world's transition to sustainable energy by creating the safest, most compelling car ever produced." The Model S's product vision reflects Tesla's commitment to promoting clean energy and reducing carbon emissions, with features like a high-performance electric drivetrain, advanced safety features, and a sleek, futuristic design.

Question 20

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 21

Release Planning

Accepted Answer

Release Planning is the process of planning a product release, identifying the capabilities that need to be released, stakeholders and team members involved, budget and timelines.

In Scrum, every Sprint enables inspection and adaptation of progress toward a Product Goal. Every Sprint begins with Sprint Planning and results in at least one increment that is usable to customers.

Some teams release increments multiple times a sprint, other teams group features from more than a sprint before releasing to the customers.

Those releasing at least once a sprint, do not need seperate release planning besides the Sprint Planning that already exists.

Question 22

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 23

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 24

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 25

Technical Debt

Accepted Answer

Technical debt is the incomplete work that must be addressed to bring the product to the expected quality and functionality.

Technical Debt could be intentional as well as unintentional.

Intentional Tech Debt is a result of decisions made during product development that emphasize speed over the product quality.

When developers are rushed, they may cut corners and pay less attention to quality - the resulting product may have incomplete work / activities.

For example: lack of refactoring, not fixing known issues / defects, incomplete or ignored unit testing, etc.

Unintentional Tech Debt is a result of slopiness, lack of technical competence, bad design decisions, etc.

Having Technical Debt lowers the User Experience and also increase the cost of ownership.

Also see: Living Without Tech Debt