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

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.

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.

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.

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.

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. Source: Feature Teams Primer by Craig Larman and Bas Vodde

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) a shorter sprint duration is recommended, b) work (PBIs) is divided in smaller slices, c) an emergent product backlog is used, d) a Work-In-Progress (WIP) limit is used during Sprint execution A Self-Managing and Cross-Functional Scrum Team further improves the ability to improve the rate of value delivery hence a shorter Lead Time.

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

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.

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

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.

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.

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)

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

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 Development Team and the Customer or the Product Owner to create a shared understanding of the user's needs. Further Reading: Writing Effective User Stories Becoming User Centric with User Stories

The maximum amount of Work-In-Process (WIP) that can be pulled in for processing / implementation within a workflow. This is a limit on the total amount of items that can be in process. The purpose of having a WIP Limit is to increase the focus on the flow of value. Due to the limits on WIP, the remaining work items can be either Waiting to be Picked up or Completed (Done). In a Scrum environment, to improve the flow of value delivery, it's recommended that the number of work items in progress may be lesser than the number of developers available to execute the work items.

Product Development - Agile and Scrum Glossary

Acceptance Criteria

Antipattern

Cost of Delay

Customer Persona

Design Thinking

Feature Teams

Incremental Development

Lead Time

Minimum Viable Product (MVP)

Pareto Principle

Product Backlog

Product Backlog Refinement (PBR)

Product Goal

Product Owner

Progressive Refinement

Release Planning

Story Mapping

Technical Debt

User Story

WIP Limit