The Complete Agile Glossary

“Knowing is the first step to wisdom; applying is the next.”

This timeless adage holds especially true in the world of Agile. The journey to mastering Agile practices and principles begins with understanding the language that shapes it.

Whether you’re preparing for the PMI-ACP exam or striving to enhance your knowledge as an Agile practitioner, having a firm grasp of key terms, metrics, principles, and frameworks is the foundation for success.

Agile is more than just a methodology; it’s a mindset, a way of thinking and approaching work that prioritizes collaboration, adaptability, and delivering value. But to truly embrace this mindset, one must first be fluent in its vocabulary.

In this guide, I’ve compiled over 350+ essential Agile terms, covering everything from basic concepts to advanced practices. These terms will not only help you pass the PMI-ACP exam but also provide clarity as you navigate real-world Agile scenarios.

So, let’s take the first step toward Agile mastery together. Dive into this glossary, absorb the knowledge, and prepare to apply it in ways that bring lasting value to your teams, projects, and organizations.

---

1. Agile: Agile is a mindset, methodology, and set of principles for software development and project management that prioritizes flexibility, collaboration, customer feedback, and rapid delivery of small, functional increments of a product. Agile approaches aim to respond to change and continuously improve by focusing on adaptive planning, iterative progress, and strong teamwork.
2. Agile Manifesto: A declaration of four values and twelve principles that guide Agile development.
3. Iteration: A time-boxed period during which specific work is completed and made ready for review.
4. Increment: A usable version of the product developed during each iteration, incorporating the features completed during the iteration.
5. Scrum: An Agile framework that uses fixed-length iterations called sprints and roles like Product Owner, Scrum Master, and Development Team.
6. Kanban: A visual framework for managing work as it moves through a process, emphasizing continuous delivery.
7. Lean: A methodology focused on maximizing value by eliminating waste and improving efficiency in processes.
8. XP (Extreme Programming): A software development methodology that emphasizes technical excellence, frequent releases, and strong collaboration.
9. Product Backlog: An ordered list of requirements for the product, maintained and prioritized by the Product Owner.
10. Sprint Backlog: A list of tasks or user stories to be completed during a sprint, drawn from the Product Backlog.
11. Burn-down Chart: A graphical representation of the remaining work versus time in a sprint or project.
12. Velocity: The amount of work completed in a given iteration, typically measured in story points or hours.
13. Forecasted Velocity is an estimate of Agile project team velocity and is used when it is impossible or impractical to determine how many story points they will need to complete an iteration. This is commonly used on a new Agile project’s first iteration since there is no historical data available to help estimate this velocity.
14. User Story: A short, simple description of a feature from the perspective of the user.
15. Acceptance Criteria: The conditions that must be met for a user story to be considered complete.
16. Epic: A large body of work that can be broken down into smaller user stories.
17. Feature: A functionality or characteristic of the product that adds value to the user.
18. Time-boxing: The practice of setting a fixed duration for a task or activity.
19. Cross-functional Team: A team composed of members with diverse skills necessary to deliver the product or service.
20. Scrum Master: The individual responsible for facilitating the Scrum process, removing impediments, and ensuring the team adheres to Scrum practices.
21. Product Owner: The person responsible for managing the product backlog, ensuring that the team is working on the most valuable features.
22. Development Team: A self-organizing, cross-functional group of professionals responsible for delivering the product increment.
23. Stand-up Meeting (Daily Scrum): A daily meeting where the team synchronizes, discusses progress, and identifies obstacles.
24. Sprint: A fixed-length iteration, typically 1-4 weeks, during which a defined set of work is completed.
25. Sprint Planning: A meeting to define the work that will be performed during the sprint.
26. Sprint Review: A meeting held at the end of the sprint to demonstrate the completed work to stakeholders.
27. Sprint Retrospective: A meeting for the team to reflect on the sprint and identify opportunities for improvement.
28. Release Planning: Planning done at the beginning of a release cycle to define the features and work for the release.
29. Definition of Done (DoD): A shared understanding of what it means for a task or user story to be complete. It includes requirements like coding standards, testing, documentation, and acceptance criteria.
30. Agile Coach: A mentor who supports the team and organization in adopting and improving Agile practices.
31. Backlog Refinement (Grooming): The ongoing process of reviewing and prioritizing the product backlog.
32. Spike: A time-boxed research task used to investigate an unknown or high-risk area of a project.
33. Burndown Chart: A chart showing the amount of work remaining over time, often used to track progress in a sprint.
34. WIP (Work In Progress): The number of tasks or user stories that are currently being worked on at any given time.
35. Lean Thinking: A methodology focused on creating more value with less work by eliminating waste.
36. Agile Release Train (ART): A group of Agile teams working together to deliver value in a coordinated way.
37. Value Stream: The series of steps that an organization takes to deliver a product or service to the customer.
38. Feature Toggle: A technique that allows features to be turned on or off in production without deploying new code.
39. Continuous Integration (CI): A practice in which developers frequently integrate their code into a shared repository, usually multiple times a day. In other words, Continuous integration is executed when code changes are checked in and tested daily.
40. Continuous Delivery (CD): A practice where code is automatically deployed to production after passing tests and builds.
41. Test-Driven Development (TDD): A software development tool where tests are written before the code to ensure that the code meets the requirements.
42. Dynamic Systems Development Method (DSDM), Feature Driven Development (FDD) and Adaptive Software Development (ASD) are all Agile development methods. 
43. Adaptive Software Development (ASD) – Adaptive Software Development (ASD) focuses on adaptability and continuous learning to address uncertain and changing project requirements.
44. Feature-Driven Development (FDD) – Feature-Driven Development (FDD) is a structured Agile methodology centered on delivering tangible and functional features in short iterations. It follows a defined five-step process: developing an overall model, building a feature list, planning by feature, designing by feature, and building by feature.
45. Lean Software Development (LSD) – Lean Software Development (LSD) applies Lean principles to software development, focusing on eliminating waste, optimizing workflow, and maximizing value delivery.
    • It emphasizes practices such as reducing work-in-progress, fast feedback loops, and empowering cross-functional teams to make decisions.
    • Lean encourages continuous improvement and fosters a culture of learning, enabling teams to adapt and optimize processes over time.
    • It is best suited for projects that require streamlined workflows and minimal inefficiencies.
    • However, its implementation often demands cultural shifts, strong team discipline, and a deep understanding of Lean principles to realize its full benefits.
46. Pair Programming: A software development technique where two developers work together at one workstation.
47. Story Point: A unit of measure used to estimate the effort or complexity of a user story.
48. MoSCoW Method: A prioritization technique that classifies features as Must have, Should have, Could have, or Won’t have.
49. Invest Criteria: A mnemonic for user story quality: Independent, Negotiable, Valuable, Estimable, Small, Testable.
50. Cumulative Flow Diagram (CFD): A visual representation of the flow of work in a Kanban system, showing work in different stages.
51. Agile Maturity Model: A framework for assessing the maturity of an organization’s Agile practices.
52. Scrum of Scrums: A meeting of Scrum Masters or representatives from different teams to discuss issues, dependencies, and coordination.
53. Time-Box: A fixed period within which an activity or event must be completed.
54. Product Increment: The sum of all the product backlog items completed during a sprint, making the product potentially shippable.
55. Planning Poker: A consensus-based estimation technique used to estimate effort or complexity for user stories.
56. Kanban Board: A visual tool that helps teams manage their work and track progress, typically divided into columns representing different stages of work.
57. Value Proposition: A statement describing the benefits and value a product or service provides to its customers.
58. Retrospective: A meeting in which the team reflects on the last iteration and discusses how they can improve in the next one.
59. User Story Mapping: A technique used to visualize user stories and their relationships to help with prioritization and release planning.
60. Agile Project Charter: A document that provides high-level information about the project, its goals, and stakeholders.
61. Risk Burndown: A chart that tracks the mitigation of risks over time, similar to a burndown chart for work.
62. Empowered Teams: Teams with the authority and responsibility to make decisions about how to do their work.
63. SWOT Analysis: A technique for identifying strengths, weaknesses, opportunities, and threats in a project or organization.
64. Defect Backlog: A list of known defects that need to be addressed in the product.
65. Team Velocity: The average number of story points a team completes in a sprint.
66. MVP (Minimum Viable Product): MVP refers to the smallest version of a product that can be released to users to validate its core value proposition. It includes the essential features needed to solve the problem for users and gather feedback. MVP refers to the functionality that is complete enough to be useful to the users or the market, yet still small enough that it does not represent the entire project.
67. Business Value: The benefits a project or feature provides to its stakeholders, often used to prioritize work.
68. Cohesion: The degree to which the components of a team or product work well together.
69. Collaboration: The act of working together to achieve a common goal, a fundamental aspect of Agile practices.
70. Flow: The smooth movement of work from one stage to another without delays or bottlenecks.
71. Work Item: An individual task, user story, or feature that requires completion.
72. Scrumban: A hybrid framework that combines elements of Scrum and Kanban.
73. Agile Portfolio Management: The practice of aligning project and program work with business strategy and goals using Agile principles.
74. T-Shaped Skills: A concept where team members have deep expertise in one area (the vertical bar of the T) but also possess broad skills in other areas (the horizontal bar).
75. SAFe (Scaled Agile Framework): A framework for scaling Agile practices to large enterprises, combining principles of Lean, Agile, and DevOps.
76. Burndown Rate: The rate at which work is being completed in a sprint or project, often measured by the amount of work remaining over time.
77. Definition of Ready (DoR): A checklist that defines when a user story is ready to be worked on, typically including criteria for clarity, size, and dependencies.
78. Change Management: The process of managing changes to a project or product in a controlled and systematic way.
79. Root Cause Analysis: A method used to identify the underlying cause of a problem or issue.
80. Innovation Games: A set of activities used to gather requirements, prioritize features, and solve problems in a collaborative way. Stakeholders are given fake money to “purchase” features they prefer, which is a common approach in innovation games. This method allows stakeholders to prioritize features based on their perceived value, helping the team understand which features are most important to the stakeholders in a fun and collaborative manner.
81. Integrated Test Environment: An environment where all aspects of testing (unit, integration, acceptance) are performed together.
82. Risk Mitigation: The process of reducing or eliminating risks to a project or product.
83. Capability Maturity Model Integration (CMMI): A model for assessing and improving the maturity of an organization’s processes.
84. Continuous Improvement: A core principle of Agile that focuses on incrementally improving processes, practices, and product quality.
85. Change Request: A formal proposal for a change in a project’s scope, schedule, or resources.
86. Project Charter: A document that formally authorizes a project and outlines objectives, stakeholders, and key details.
87. Customer Collaboration: A principle from the Agile Manifesto that emphasizes working directly with customers to understand their needs and deliver value.
88. Time-to-Market: The total time taken from the initial idea to the delivery of a product to the market.
89. Self-Organizing Teams: Teams that organize their own work and make decisions independently, empowering them to achieve high performance.
90. Backlog Item: An entry in the backlog, such as a user story, task, or bug, that represents work to be completed.
91. Servant Leadership: A leadership philosophy where the leader serves the team by supporting their needs and helping them achieve their goals.
92. Work in Process (WIP) Limits: Limits on the number of work items that can be in progress at any given time to optimize flow.
93. Cost of Delay: The economic impact of delaying a product feature or project, often used to prioritize work.
94. Value Stream Mapping: A visual tool for analyzing and improving the flow of materials and information required to deliver a product.
95. Product Roadmap: A high-level strategic plan that outlines the product’s vision, goals, and timeline. In other words, A product roadmap is a strategic planning tool that provides a high-level visual representation of the planned product releases, milestones, and key components or features to be developed over time. A product roadmap is used as a communication tool.
96. A Product Roadmap is an Agile artifact that describes the incremental nature of how a product will be built and delivered over time, along with the important factors that drive each individual release
97. Sprint Zero: The initial sprint in a project, focused on setting up infrastructure, defining initial requirements, and getting the project ready to start.
98. Team Velocity: The amount of work a team can complete in a given sprint, typically measured in story points.
99. Feature-Driven Development (FDD): A model-driven, short-iteration process for Agile development.
100. Continuous Testing: The practice of testing code continuously throughout the development process to identify defects early.
101. Just-in-Time (JIT): A Lean principle that focuses on delivering work and features only when they are needed, avoiding waste. Just in Time is a principle that emphasizes delivering work, making decisions, or producing documentation at the last possible moment, in order to reduce waste and increase efficiency.
102. Just Because: “Just Because” in Agile refers to a decision or action taken without a clear reason, often due to assumptions or outdated practices. It highlights the importance of continuously questioning and validating choices to ensure they align with current needs and goals.
103. Scaled Agile Framework (SAFe): A framework for implementing Agile at scale across large enterprises with multiple teams and programs.
104. Customer Journey Mapping: A visual representation of the steps a customer takes when interacting with a product or service.
105. Collective Ownership: A principle that ensures all team members can contribute to and make improvements to any part of the code or project.
106. Risk Register: A document that lists all identified risks to a project, their likelihood, impact, and mitigation plans.
107. Agile Transformation: The process of adopting and implementing Agile practices across an organization, shifting both mindset and processes.

101. Agile Metrics: Quantitative measurements used to evaluate the performance of Agile processes and teams, such as velocity, cycle time, and lead time.
102. Acceptance Test-Driven Development (ATDD): A development approach where the acceptance tests are defined before the code is written, ensuring that the product meets user expectations.
103. Behavior-Driven Development (BDD): A software development approach that emphasizes collaboration between developers, testers, and business stakeholders to define clear, understandable specifications for features.
104. Value Stream Mapping: A Lean tool used to visualize the flow of information and materials needed to deliver a product, identifying areas of waste and inefficiency.
105. Customer-Centric: A mindset in Agile where decisions are made with the focus on delivering value and satisfaction to the customer.
106. Collaboration Tools: Tools such as Slack, Jira, or Trello that enable teams to collaborate, track progress, and communicate in Agile environments.
107. DevOps: A cultural and technical movement that aims to improve collaboration between development and operations teams to deliver software quickly and reliably.
108. Risk Management: The practice of identifying, assessing, and prioritizing risks in an Agile project and creating strategies to mitigate or manage them.
109. Time-to-Value: The time it takes to deliver the first value to the customer from the beginning of the project.
110. Backlog Item: A discrete unit of work in the backlog, which could be a user story, feature, defect, or task.
111. Feature Team: A team that is cross-functional and works together to deliver a complete feature of the product, not just a component.
112. Agile Framework: A structure or set of principles used to implement Agile practices. Examples include Scrum, Kanban, and Lean.
113. Priority Queue: A queue in which the items are processed based on priority, rather than in the order they arrive.
114. Capacity Planning: The process of determining the work a team can handle in a given time frame based on their capacity and availability.
115. Lead Time: The total time it takes from when work is requested until it is delivered, from start to finish.
116. Cycle Time: The amount of time it takes for an item to move from one stage of a process to the next, often used in Kanban systems. Cycle time = WIP/Throughput. The team can use cycle time to predict the approximate date of completion of the features.
117. Sprint Retrospective: A meeting at the end of each sprint where the team reflects on what went well, what didn’t, and how they can improve.
118. Project Portfolio Management (PPM): The centralized management of all projects within an organization to ensure alignment with business objectives.
119. Risk Register: A tool used to record risks, their likelihood, impact, and responses, helping the team track and manage project risks.
120. Impact Mapping: A strategic planning method used to identify and align project goals with business outcomes.
121. Definition of Done (DoD): A shared understanding between the team and stakeholders about the criteria that must be met for a task or user story to be considered complete.
122. Failure Modes and Effects Analysis (FMEA): A systematic approach to identifying potential failure points in a process and analyzing their effects on the project or product.
123. Impact vs Effort Matrix: A tool for prioritizing work by considering the value (impact) and cost (effort) of each task or feature.
124. Flow Metrics: Metrics used to track the efficiency of work flowing through a system, such as cycle time, throughput, and work in progress (WIP).
125. Release Train Engineer (RTE): A servant leader responsible for facilitating and guiding the release train (Agile Release Train or ART) within the Scaled Agile Framework (SAFe).
126. Stakeholder: Any person or group who has an interest or concern in the outcome of a project.
127. Release Planning: The process of planning what features will be delivered in each release, including timelines, resources, and risk management.
128. Incremental Delivery: A development approach where the product is delivered in small, incremental portions, each adding value to the customer.
129. Feature Prioritization: The process of determining which features of a product are most important and should be delivered first, often based on customer needs.
130. Program Increment (PI): A time-boxed period in SAFe where a group of teams deliver a set of features and milestones.
131. Scrumban: A hybrid approach combining Scrum and Kanban principles to give teams more flexibility in their Agile practices.
132. Continuous Deployment: A software development practice where code is automatically deployed to production as soon as it passes automated tests.
133. Retrospective Action Plan: The set of actions agreed upon during a retrospective meeting to improve team performance or processes in the next iteration.
134. High-Performance Team: A team that consistently delivers high-quality work, communicates effectively, and collaborates to solve problems.
135. Value Proposition Canvas: A tool used to design, test, and analyze a product’s value proposition to ensure it meets customer needs and expectations.
136. Sprint Goal: A concise statement of what the team aims to achieve during the sprint, guiding the focus of the sprint backlog.
137. Timeboxing: A practice of limiting the amount of time spent on a particular activity to maintain focus and efficiency.
138. Work Breakdown Structure (WBS): A hierarchical decomposition of the total work to be performed in a project, used for planning and organizing tasks.
139. Fixed-Price Contract: A type of contract where the price is set at the beginning of the project and does not change, regardless of actual costs.
140. Shared Ownership: A principle where all team members are collectively responsible for the quality and success of the product.
141. Planning Poker: A collaborative estimation technique where team members use cards to vote on the complexity or effort required for a task.
142. Test Automation: The practice of automating repetitive testing tasks to improve efficiency and reduce human error in the testing process.
143. Lead Time vs. Cycle Time: Lead time is the total time from start to finish, while cycle time refers to the time taken to complete a single task or item.
144. Dependency Management: The practice of identifying and managing dependencies between tasks, teams, or components to ensure smooth project flow.
145. Process Improvement: The continuous effort to identify, analyze, and improve processes to increase efficiency, quality, and value.
146. Product Lifecycle: The series of stages a product goes through from inception to delivery and eventual retirement or replacement.
147. Product Roadmap: A high-level plan that outlines the vision, goals, and timeline for the product’s development and release strategy.
148. Continuous Monitoring: The practice of continuously monitoring the progress, quality, and performance of the product during development.
149. Test-Driven Development (TDD): A software development practice where automated tests are written before the actual code to define and verify the behavior of the code.
150. Risk Avoidance: A strategy for managing risk by eliminating or avoiding the factors that contribute to risk.
151. Risk Transfer: A strategy for managing risk by shifting the impact of the risk to another party, such as through outsourcing or insurance.
152. Agile Transformation: The process of an organization adopting Agile methodologies at all levels to become more flexible and responsive.
153. Cross-Functional Team: A team composed of individuals with a variety of skills, enabling them to handle all aspects of product development without outside help.
154. Scrum-of-Scrums: A meeting held between representatives from multiple Scrum teams to ensure alignment, share progress, and resolve inter-team dependencies.
155. Cycle Time Reduction: The process of shortening the time it takes to complete a task or user story by optimizing processes and reducing waste.
156. Capability: A specific ability or skill that a team or individual possesses, often referenced in the context of delivering product features.
157. Estimation: The process of predicting the time, effort, or resources required to complete a task, user story, or project.
158. Shared Vision: A collective understanding among team members and stakeholders about the desired outcomes and goals of the project.
159. DevSecOps: An approach to software development that integrates security practices into the DevOps process, ensuring that security is considered throughout the development lifecycle.
160. Innovation: The introduction of new ideas, products, or practices aimed at improving quality, efficiency, or value in Agile development.
161. Stakeholder Management: The process of identifying, analyzing, and managing stakeholders’ expectations, communication, and involvement in the project.
162. Team Charter: A document that defines the roles, responsibilities, and behaviors expected from each team member in an Agile team.
163. Feature Toggle: A mechanism that allows features to be turned on or off dynamically in the production environment, allowing for controlled testing or gradual release.
164. Kanban System: A visual management system used to track the flow of work through a process, emphasizing just-in-time delivery and limiting work in progress.
165. Root Cause Analysis: A technique used to identify the underlying cause of problems and issues in a project or product.
166. Burn-up Chart: A visual representation that tracks progress toward project completion by showing the total work completed against the total work planned. If the scope increases during the sprint (as in your scenario, where the Product Owner suggested new changes), the chart will show a shift in the total scope, providing visibility of the scope change to the team.
167. Capability Maturity Model Integration (CMMI): A framework for process improvement in organizations, which can be adapted to Agile environments to assess and enhance processes, ensuring alignment with business goals and increasing efficiency and quality.

168. Process Tailoring: Customizing Agile frameworks, practices, or processes to fit the specific needs of a team, project, or organization, ensuring optimal alignment with goals and context.
169. Program Management: The coordinated management of multiple, related projects to achieve strategic objectives, often leveraging Agile principles for flexibility and alignment.
170. Work Item Tracking: The practice of documenting and managing tasks, user stories, or features as they progress through their lifecycle in an Agile project.

171. Agile Principles: The 12 principles outlined in the Agile Manifesto that guide Agile practices, such as welcoming change, delivering working software frequently, and fostering collaboration.
172. Agile Values: The four foundational values from the Agile Manifesto: (1) Individuals and interactions over processes and tools, (2) Working software over comprehensive documentation, (3) Customer collaboration over contract negotiation, (4) Responding to change over following a plan.
173. Throughput: The number of work items completed in a given time period, often used to measure team productivity. It is a measure of how many work items (e.g., user stories, tasks, features) a team completes over a given period of time. It is typically measured as the number of items finished or delivered within a specific time frame (e.g., per day, per sprint, or per week).
174. Cumulative Flow Diagram (CFD): A chart that visualizes work in progress, completed work, and bottlenecks across stages of a workflow.
175. Work In Progress (WIP) Limits: A constraint in Kanban that restricts the maximum number of work items in progress at any given time.
176. Net Promoter Score (NPS): A metric used to gauge customer loyalty and satisfaction based on how likely they are to recommend the product to others.
177. Agile Triangle: A concept that focuses on value, quality, and constraints (scope, cost, and time) as measures of project success.
178. Team Happiness Metric: A qualitative measure of team satisfaction, often tracked through surveys or mood boards.
179. Code Coverage: A metric that measures the percentage of source code tested by automated tests.
180. Escaped Defects: The number of defects found by the customer after the product is released, indicating gaps in quality assurance.
181. First-Time Pass Rate: The percentage of work items that pass quality checks on the first attempt.
182. Lead Time Distribution: A histogram showing the distribution of lead times for completed work items, providing insights into variability.
183. Cycle Efficiency: The ratio of value-added time to the total time (lead time) for a work item.
184. Mean Time to Repair (MTTR): The average time required to fix a defect or recover from an issue in the production environment.
185. Mean Time Between Failures (MTBF): The average time between system failures, often used to assess system reliability.
186. Burn-Up Chart: A chart that tracks the total scope and the work completed, showing progress toward the project goal.
187. Story Splitting: The process of breaking down large user stories into smaller, more manageable pieces while retaining their value.
188. Law of Diminishing Returns: A principle stating that adding more resources or effort may lead to reduced marginal gains in productivity or output.
189. Parkinson’s Law: The idea that work expands to fill the time available for its completion, highlighting the importance of time-boxing.
190. Conway’s Law: The principle that software systems are designed in a way that mirrors the communication structure of the organization.
191. Little’s Law: A formula used in queuing theory to predict system performance: L=λWL = \lambda W, where LL is the average number of items in a system, λ\lambda is the arrival rate, and WW is the average time an item spends in the system.
192. Hawthorne Effect: The phenomenon where individuals improve their performance simply because they are being observed.
193. Shu-Ha-Ri: A concept from martial arts applied to Agile learning: Shu (follow rules), Ha (break rules), and Ri (master the rules).
194. Maturity Models: Frameworks that assess an organization’s maturity level in adopting Agile practices, such as the Agile Maturity Model or the SAFe Maturity Model.
195. Theory of Constraints (TOC): A management philosophy that focuses on identifying and addressing the most limiting factor (constraint) in a process.
196. Team Morale: A qualitative measure of the team’s spirit, enthusiasm, and motivation.
197. Empirical Process Control: A foundational principle of Scrum emphasizing transparency, inspection, and adaptation.
198. Jidoka: A Lean principle of building quality into processes by allowing workers to stop production to address defects immediately.
199. Kaizen: A Japanese term for continuous improvement, focusing on small, incremental changes to processes or products.
200. Value-Based Prioritization: The practice of ranking features or tasks based on their potential value to the customer or organization.
201. Fishbone Diagram: A tool used for root cause analysis, also known as the Ishikawa or Cause-and-Effect Diagram or Herringbone diagrams.
202. Agile Mindset: A way of thinking that embraces flexibility, collaboration, and continuous improvement to deliver value.
203. Personas: Fictional representations of user types based on research, used to better understand customer needs and behaviors. Personas provide a detailed summary of the ideal customer, including demographic traits such as location, age, and job title, as well as psychographic traits such as behaviors, feelings, needs, and challenges
204. INVEST Criteria: A guideline for good user stories: Independent, Negotiable, Valuable, Estimable, Small, and Testable.
205. Team Velocity: The average number of story points a team completes in a sprint, used for capacity planning and forecasting.
206. Risk Burn-Down Chart: A chart that tracks the mitigation of risks over time in a project.
207. Pull System: A production model, such as Kanban, where work is started only when there is demand or capacity.
208. Servant Leadership: A leadership style where the leader prioritizes the needs of the team and supports their growth and development.
209. Technical Debt: The cost of additional work caused by choosing quick-and-dirty solutions over more robust approaches.
210. Acceptance Test: A test to determine whether a feature meets the predefined acceptance criteria.
211. Behavioral Economics: A field of study that examines how psychological factors influence economic decision-making, often applied in prioritization.
212. Product Mapping visually organizes product components or features in relation to goals or priorities.
213. Economic Analysis evaluates the financial aspects of decisions to optimize value or minimize cost.
214. Market Analysis assesses the broader market environment, customer preferences, and competition.
215. Velocity Range: A team’s historical range of velocity values, used to predict future performance under similar conditions.
216. Spaghetti Diagram: A Lean tool used to map physical workflow or processes to identify inefficiencies or redundancies.
217. Productivity: The rate at which a team or individual produces deliverable value.
218. Swarming: A technique where the multiple team members focuses on completing a single task to resolve a bottleneck or expedite work.
219. Adaptive Planning: A flexible approach to planning that accommodates changes and uncertainties.
220. Opportunity Cost: The value of the next best alternative foregone when making a decision, often used in feature prioritization.
221. Customer Journey Mapping: A visualization of the customer’s interactions with a product or service, used to identify areas for improvement.
222. Five Whys: A problem-solving technique used to drill down to the root cause of an issue by asking “Why?” repeatedly.
223. Agile Estimation Techniques: Methods such as Planning Poker, T-shirt Sizing, or Bucket System for estimating effort or complexity.
224. Shared Vision: A collective understanding of the project’s goals and desired outcomes among stakeholders and the team.
225. Feature Burndown: A chart that tracks progress in completing features over time.
226. Pair Testing: A collaborative testing approach where two team members (often a developer and a tester) test a product together.
227. Right-Sizing: The practice of ensuring that work items are appropriately sized for completion within an iteration or sprint.
228. Pareto Principle: The idea that 80% of outcomes result from 20% of causes, often used in prioritization.
229. Predictability: A measure of how accurately a team meets its commitments or planned deliverables.
230. Relative Sizing: An estimation technique where work items are sized relative to one another, rather than assigning absolute values.
231. Outcome-Based Metrics: Metrics that focus on the value delivered to the customer, such as customer satisfaction or user adoption.
232. Customer Delight: Exceeding customer expectations to create exceptional experiences and build loyalty.
233. Plan-Do-Check-Act (PDCA): A four-step iterative cycle for continuous improvement in processes and products.
234. Self-Organizing Teams: Teams that determine how to accomplish their work without external direction, embodying autonomy and accountability.
235. Value-Driven Delivery: A focus on delivering the most valuable features to stakeholders and customers as quickly as possible.
236. Situational Leadership: A leadership model that adjusts leadership style based on the team’s maturity and the task at hand.
237. Definition of Ready (DoR): Criteria that ensure a user story or task is clear, actionable, and ready for the team to work on.
238. Takt Time: The pace at which a product must be completed to meet customer demand, used in Lean planning.
239. Risk Exposure: A calculated measure of risk impact and probability, used to prioritize risk responses.
240. Dynamic Systems Development Method (DSDM): An Agile framework focused on delivering business value and ensuring active user involvement.
241. Agile Modeling: A practice of creating simple, effective models for software systems to aid in communication and development. Agile modeling is a practice within Agile and Extreme Programming (XP) methodologies that emphasizes visual communication and collaboration among team members using various modeling techniques, such as whiteboard sketches, diagrams, and mock-ups.
242. Refactoring: The process of improving existing code without changing its functionality, enhancing maintainability and performance.
243. Release Burn-Up Chart: A visual representation of progress toward a release goal, showing scope and work completed.
244. Planning Horizon: The length of time for which detailed planning is feasible and practical in Agile projects.

242. Technical Excellence: A principle of Agile emphasizing high-quality practices, tools, and techniques to enhance product quality.
243. Agile Coaching: Guiding individuals and teams in adopting and improving Agile practices to achieve greater effectiveness.
244. Time Value of Money (TVM): A financial principle that considers the value of money over time, used in cost-benefit analysis.
245. Agile Governance: The application of governance principles in an Agile context, balancing control and flexibility.

246. Dynamic Systems Development Method (DSDM): An Agile framework emphasizing active user involvement, frequent delivery, and prioritization of functionality to deliver high-value outcomes.
247. Agile Unified Process (AUP): A simplified version of the Rational Unified Process (RUP) that incorporates Agile principles, focusing on iterative development, flexibility, and customer feedback.
248. Minimum Marketable Feature (MMF): The smallest functionality in a product that delivers value to customers and can be marketed or released independently.
249. The six core values of Crystal Methods are communication, people, flexibility, simplicity, feedback, and enhancing skills.
250. Crystal Clear: A lightweight Agile methodology tailored for small teams (1 to 6 members) working on low-complexity, critical projects. It emphasizes frequent delivery, clear communication, and adaptability.
251. Crystal Yellow: Part of the Crystal family, designed for slightly larger teams (7 to 10 members) managing moderately critical projects. It focuses on simplicity and strong communication practices.
252. Crystal Orange: Suited for medium to large teams (11 to 50 members) handling projects of moderate to high criticality. It emphasizes formal documentation, structured processes, and clear communication.
253. Crystal Red: Created for large teams (50+ members) working on highly critical projects. Crystal Red incorporates strict processes, comprehensive documentation, and robust communication practices to ensure reliability and accountability.
254. Crystal comes from Alistair Cockburn’s characterization of projects along the two dimensions of “size” (meaning the size of the project team) and “criticality” (meaning the damage that will be caused if the developed product or system fails).
255. Four TYPES of Conflict: A framework identifying levels of conflict in teams: (1) Intrapersonal (internal to a person), (2) Interpersonal (between individuals), (3) Intragroup (within a team), and (4) Intergroup (between teams).
256. 5 TYPES of conflict – Level 1 -Problem to Solve, Level 2 Disagreement, Level 3 Contest, Level 4 Crusade, Level 5 World War.
257. Crusade: Conflict at this level is characterized by strong emotions, passion, and a sense of mission or purpose. It may involve deeply-held beliefs, values, or ideologies, and can result in significant polarization and division among individuals or groups.
258. World War: Conflict at this level is the most intense and destructive, involving widespread hostility, aggression, and violence. It may result in long-lasting and severe consequences, and can have a detrimental impact on relationships, teams, and organizations.
259. Iteration Planning: A meeting where the team plans the work for an iteration, selecting user stories or tasks and breaking them down into actionable items.
260. Roadmap Planning: High-level planning that outlines the vision, goals, and timeline of a product over a long-term horizon, helping stakeholders align on priorities.
261. Release Planning: Planning the delivery of features or functionality in a specific release, focusing on achieving goals and aligning with business needs.
262. Mob Programming: A development practice where the entire team works on the same task, at the same time, on the same workstation, fostering collaboration and shared ownership.
263. Introspectives: Team reflections held during or after a project to evaluate what went well, what could be improved, and actionable steps for future improvement.
264. Risk-Based Spike: A time-boxed activity to investigate a risky or unknown aspect of a project, such as technology feasibility or potential challenges.
265. Prune the Product Tree: A collaborative brainstorming exercise where stakeholders map out features as branches on a tree, helping to prioritize and visualize product growth.
266. Sailboat Retrospective: A retrospective format where the team identifies forces helping (wind), hindering (anchors), and risks (icebergs) to their progress toward goals.
267. Relative Estimation: An estimation method that compares tasks or user stories to each other rather than assigning absolute time or effort values.
268. Parametric Estimation: A technique that uses mathematical models or historical data to estimate the effort or time required for tasks.
269. Adaptive Approach: A flexible project management approach that embraces change and evolves as new information or requirements emerge.
270. Agile Roadmap: A strategic overview of the product vision and development path, focusing on high-level goals and guiding incremental deliveries.

266. Wireframes: Simple visual guides that outline the structure and layout of a product interface, focusing on functionality rather than design details.
267. Regression Testing: A testing practice to ensure that new changes or updates to the software do not break existing functionality.
268. Exploratory Testing: A testing approach where testers actively explore the application without predefined scripts, focusing on identifying unexpected issues.
269. Yesterday’s Weather: A principle in Agile estimating where a team bases future sprint commitments on their performance in previous sprints, ensuring realistic planning.
270. Kaizen: A Japanese term meaning “continuous improvement,” emphasizing small, incremental changes to improve processes and outcomes.
271. Lowering Coupling: The process of minimizing dependencies between components in a system to improve maintainability and flexibility.
272. Architectural Spike: A time-boxed investigation focused on evaluating architectural solutions or resolving technical uncertainties early in a project.
273. ESVP: Stands for Explorer, Shopper, Vacationer, Prisoner, a retrospective exercise where participants reflect on their attitude toward the retrospective, helping the facilitator adjust accordingly.
     • Explorer: Team members who take on the role of “Explorer“ are enthusiastic and actively seek out new ideas and improvements. They are open to experimentation and are willing to take risks to drive positive change.
       2. Shopper: “Shoppers“ are team members who are more cautious and observant. They prefer to gather information and learn from the experiences of others before committing to any changes. They are more reserved and may take a wait-and-see approach before actively engaging in improvement initiatives.
       3. Vacationer: “Vacationers“ are content with the current state of the project or sprint and may not actively participate in improvement discussions. They may be complacent or disinterested in the retrospective process and may require motivation or encouragement to actively engage in discussions.
       4. Prisoner: “Prisoners“ are team members who may have negative attitudes or feel stuck in their current situation. They may express frustration or resistance to change and may require special attention to understand and address their concerns.
274. Monopoly Money: A prioritization exercise where stakeholders allocate a fictional budget to features or projects, helping to identify priorities based on perceived value.
275. Broken Comb: A skill model representing professionals who have expertise in multiple areas but are deeply skilled in a few, balancing breadth and depth.
276. Fist of Five: A decision-making technique where team members raise their hand with fingers (1 to 5) to express their level of agreement, encouraging consensus and quick feedback.
277. Caves and Commons: A workspace strategy in Agile that provides areas for focused work (caves) and collaboration (commons), balancing individual and team needs.
278. Fishbone Analysis: A root cause analysis tool that identifies contributing factors to a problem, visualized in a “fishbone” diagram format.
279. Fishbowl Window: A collaboration technique where a small group discusses a topic while others observe silently, fostering clarity and engagement.
280. Working Agreement: A set of shared guidelines or norms that a team creates to define how they will work together effectively.
281. Project Tweet: A concise summary of a project’s goals and value, written as if describing the project in a single tweet, promoting clarity and focus.
282. Large Scale Scrum (LeSS): A framework for scaling Scrum to larger teams and organizations, focusing on simplicity, continuous improvement, and team autonomy.
283. Blending Agile: Combining elements of different Agile frameworks or methodologies (e.g., Scrum and Kanban) to suit a team’s unique needs.
284. Trend Analysis: Analyzing historical data to predict future outcomes, often used in Agile metrics to track performance or identify patterns.
285. Net Present Value (NPV): A financial metric that calculates the value of future cash flows in today’s terms, used to evaluate project feasibility.
286. Internal Rate of Return (IRR): A financial measure used to evaluate the profitability of investments by determining the discount rate that makes the NPV equal to zero.
287. Return on Investment (ROI): A financial metric used to evaluate the efficiency of an investment, calculated as the ratio of net profit to the cost of the investment.
288. Throughput: The number of work items completed within a specific time period, often used to measure team productivity.
289. Technical Debt: The cost of additional work required due to shortcuts or suboptimal solutions in development, often impacting long-term maintainability. Technical debt can accumulate over time and manifest in various forms, such as poor code quality, lack of documentation, incomplete test coverage, outdated technologies, design flaws, or inefficient processes. 
290. Continuous Integration: A development practice where code changes are frequently integrated and automatically tested, ensuring early detection of issues.
291. Continuous Delivery: An extension of continuous integration where software is built, tested, and prepared for deployment in short cycles.
292. Cone of Uncertainty: A visual representation of how uncertainty decreases over time as more is learned about a project, emphasizing the need for flexibility in early estimates.
293. Task Switching: The inefficiency caused by shifting focus between multiple tasks, often leading to reduced productivity and increased errors.
294. Generalizing Specialist: A team member who has deep expertise in one area but is also proficient in other areas, contributing to team flexibility and collaboration. While team members may initially be specialists, they typically evolve into generalizing specialists over time, enhancing team flexibility and collaboration.
295. Handoffs: The transfer of work or responsibility between individuals or teams, which can lead to delays or miscommunication if not managed effectively.

296. Horizon 0: Represents the core operations of a business, focusing on maintaining and optimizing current processes, systems, or products to ensure stability and reliability.
297. Horizon 1: Involves near-term improvements and incremental innovations that enhance existing offerings or expand into closely related markets, ensuring short-term growth.
298. Horizon 2: Focuses on mid-term opportunities by developing new capabilities, products, or services that leverage existing strengths but explore new market areas or user needs.
299. Horizon 3: Represents long-term, transformative initiatives aimed at creating entirely new markets, technologies, or business models that could disrupt the industry or redefine the organization.
300. Horizon 4: Extends the model by exploring speculative, experimental, or future-oriented ideas that are still in early conceptual stages, often involving high risk but significant potential for long-term breakthroughs.

301. Generic Product: The basic version of a product that fulfills the core need or function for which it is designed, without any additional features or enhancements.
302. Expected Product: The set of attributes or features that customers typically expect when they purchase a product, aligning with industry standards or norms.
303. Augmented Product: A product enhanced with additional features, services, or benefits that differentiate it from competitors and add extra value for customers.
304. Potential Product: The future possibilities of a product, encompassing all enhancements, innovations, or features that could be added to meet emerging needs or create new value.
305. Model-Based Solution Design (MBSD): A structured approach to designing solutions using models to represent systems, processes, or scenarios. This approach focuses on visualizing, analyzing, and iterating on design options before implementation to ensure alignment with business goals and technical feasibility.
306. Descriptive Models: Models that describe current states or systems, used to document and understand existing processes or structures.
307. Predictive Models: Models used to forecast potential outcomes based on data and assumptions, helping in decision-making and risk assessment.
308. Prescriptive Models: Models that recommend actions or solutions by optimizing variables and constraints, focusing on achieving desired outcomes.
309. Exploratory Models: Models designed to explore various possibilities and test “what-if” scenarios to assess potential impacts of different decisions.
310. Brainstorming is a creative problem-solving technique used to generate a large number of ideas or solutions in a short period of time. The goal is to encourage free thinking and open discussion, where participants can share ideas without judgment, fostering innovation and creative solutions to a problem or challenge.
311. Affinity estimates is a technique used in Agile project management to estimate the relative effort or complexity of tasks by grouping them based on similarity or affinity, rather than assigning specific numerical values. Team members collaboratively categorize items into groups that represent similar levels of effort, complexity, or size. This method helps prioritize work without requiring precise estimates.
312. Dot voting is a decision-making technique used to prioritize or select options by allowing participants to vote on items using dots or marks. Each participant is given a set number of votes (dots), which they can place on the options they believe are most important or valuable. The options with the most votes are considered the most preferred or prioritized. Dot voting is often used in brainstorming or planning sessions to quickly gauge the group’s preferences and make decisions.
313. Agile Triangle: agile projects attempt to fix time and cost and adjust scope to achieve the highest-priority, best-quality product possible within the fixed constraints.
314. Low-tech, high-touch tools are simple, non-digital methods that prioritize human interaction and collaboration. Examples include whiteboards, sticky notes, and face-to-face meetings. These tools focus on direct communication and engagement, fostering effective teamwork without relying on complex technology.
315. Information radiators are visual displays used in Agile environments to share key project information in a clear, accessible, and transparent way. These displays, such as task boards, burndown charts, or kanban boards, provide real-time updates on project status, progress, and issues, ensuring all team members and stakeholders are informed without needing detailed reports or meetings.
316. Self-assessments are tools that allow the team to reflect on their current practices and identify areas for improvement. The team can conduct a self-assessment specifically focused on their branching and commit model to evaluate its effectiveness and identify any pain points or areas of improvement.
317. Storming: This is the second stage in team development, where conflict and disagreements often arise as team members assert their opinions, roles, and ideas. Tensions may surface due to differences in working styles or goals, but this phase is crucial for team growth as members navigate challenges and learn to collaborate effectively.
318. Norming: This is the third stage, where the team starts to establish clear roles, processes, and working relationships. Conflicts from the storming phase are resolved, and team members begin to work more cohesively. There’s a sense of unity, and the team starts to focus on shared goals, leading to improved collaboration and productivity.
319. A Cumulative Flow Diagram (CFD) is a visual tool used in Agile to track the progress of work items, such as user stories or features, over time. It displays work items in different stages (e.g., backlog, in progress, completed) using a stacked area chart or line chart. CFDs help teams visualize project flow, identify bottlenecks, and understand cycle times and completion trends. This tool provides valuable insights into project status and potential issues, supporting better decision-making and efficient delivery.
320. Single-loop learning occurs when individuals or teams make adjustments to their actions or strategies to correct errors, without questioning or altering the underlying assumptions or goals. It’s a more reactive process focused on solving problems within the current framework.
321. Double-loop learning goes deeper by not only correcting mistakes but also questioning and potentially changing the underlying assumptions, policies, or objectives that led to the problem in the first place. It’s a more reflective and proactive learning process that allows for transformational change, encouraging individuals and teams to reconsider their approach and fundamental beliefs.
322. A project elevator statement is a brief, concise description that communicates the core goals, benefits, and objectives of a project. It’s designed to help team members quickly understand the project’s purpose and value, often in the time it would take to ride an elevator with someone
323. A graduated fixed-price contract is a type of contract where the supplier’s payment is linked to the timeliness of delivery. In this contract, if the supplier delivers the project on time, they are paid at a standard rate for the hours worked. If they deliver early, they are paid for fewer hours but at a higher rate. Conversely, if the supplier delivers late, they are paid for more hours, but at a lower rate. This type of contract allows for risk sharing between the customer and the vendor, as the vendor is incentivized to deliver early and faces a penalty for delays, balancing the risk between both parties. It is considered more suitable for Agile projects, as it accommodates changes while promoting collaboration and performance.
324. An Agile Time and Materials contract allows the customer to terminate the contract at any time on the project if they do not see any added value.   
325. Just-in-time (JIT) in Agile refers to the practice of breaking down requirements or tasks at the last responsible moment when the team is about to work on them. Rather than decomposing requirements too early in the project, which might lead to unnecessary work or outdated assumptions, the team waits until they have enough information and clarity to make informed decisions
326. The Dreyfus Model of Skill Acquisition describes five stages of learning: Novice, Advanced Beginner, Competent, Proficient, and Expert. It outlines how individuals develop skills, from rule-based learning to intuitive, experience-driven expertise. This model is used to understand skill development and guide learning and coaching processes.
327. Common Cause Variation Scenario: A software development team consistently completes an average of 5 user stories per sprint. However, in one sprint, they only completed 4. This slight difference is within the expected range and is considered a normal fluctuation in productivity due to factors like team member availability or minor variations in task complexity. No corrective action is required because this variation is inherent to the team’s normal process.
328. Special Cause Variation Scenario: A team typically completes 5 user stories per sprint, but during one sprint, they only completed 1 story. Upon investigation, the project manager discovers that a critical team member fell ill for a few days, causing significant disruption in the sprint’s progress. This is an example of special cause variation, as it was caused by an identifiable, unexpected event (the team member’s illness) that affected the process. Corrective action, such as adjusting the workload or adding resources, may be needed to prevent future disruptions.
329. Premotem is an Agile technique used for risk management, where the team anticipates potential problems by imagining that a project or sprint has already failed. Team members then brainstorm the reasons behind the failure, helping identify possible risks, challenges, and obstacles. This proactive approach allows the team to develop strategies to mitigate or address these issues before they occur, improving project planning and decision-making. It encourages critical thinking and preparation, aiming to reduce the impact of risks on the project’s success.
330. Agility in software development refers to a team’s ability to quickly adapt to changes and deliver high-quality solutions. Teams with strong technical expertise and a solid understanding of design principles can identify and solve problems early, move efficiently, and create systems that are easier to maintain and extend, leading to faster, more reliable software delivery.
331. A story map in Agile is a visual tool that organizes user stories or product backlog items (PBIs) along a timeline to provide a clear overview of a project’s scope and progress. It helps teams prioritize work, plan iterations, and align on goals by grouping stories into themes or epics.
332. Blending Agile refers to the practice of combining or using elements from different Agile frameworks, such as XP (Extreme Programming) and Scrum, to tailor an approach that best suits the team’s needs. By integrating practices from multiple frameworks, teams can leverage the strengths of each to improve collaboration, efficiency, and product quality.
333. Flow Master: When formal training is not available, the Flow Manager helps guide the team in adopting and maturing Kanban practices. They focus on optimizing the flow of work, identifying and removing bottlenecks, and supporting the team in continuous improvement to enhance efficiency and delivery.
334. A hardening iteration in Agile refers to a time-boxed sprint focused on stabilizing and finalizing the product before release. It is used to address defects, conduct testing, optimize performance, and ensure the product is ready for deployment.
335. A Hardening Iteration is an iteration that Agile project teams use to perform integrated testing on each of the different product increments developed during each iteration so far to ensure that they work together as a whole
336. Value Stream Mapping includes the following steps:
     • Define the scope and boundaries of the value stream.
     • Create a current state map capturing the value stream’s existing steps and flows.
     • Analyze the map to identify waste, such as overproduction and defects.
     • Identify improvement opportunities and create a future state map with optimized flows.
     • Develop an action plan to implement the identified improvements.
     • Continuously monitor and update the value stream map to reflect changes and improvements.
337. The Dynamic Systems Development Method (DSDM) stands out from other Agile methodologies due to its strong focus on aligning projects with business objectives. Unlike frameworks that prioritize flexibility in scope, DSDM fixes time, cost, and quality constraints, adjusting the scope to meet these boundaries. It follows a clear, structured set of phases: pre-project, feasibility, foundations, exploration, engineering, and deployment allowing for iterative development that delivers incremental value.
338. Wideband Delphi is a group estimation technique where team members anonymously provide their estimates for work items, such as user stories or tasks. The process is iterative, with results being summarized and shared to reach a consensus estimate. This method minimizes bias by allowing participants to estimate independently, using units like story points or t-shirt sizes.
339. Leading metrics/indicators are predictive and measure factors that influence future performance, helping teams anticipate issues or opportunities.
340. Lagging metrics/indicators, on the other hand, reflect past performance and outcomes, providing insights into what has already happened, but not necessarily guiding future actions.
341. An S-curve is a graphical representation that shows the growth or progress of a project, process, or system over time. It typically starts slowly, accelerates as progress builds, and then slows down again as it approaches completion, forming an “S” shape.
342. Explicit knowledge is easily codified and shared through words, numbers, or images, like instructions for uploading a file to a shared drive.
343. Tacit Knowledge, is personal, subjective, and difficult to express, such as an individual’s beliefs, insights, or aesthetic sense, which are shaped by personal experiences and values and are hard to communicate in simple terms.
344. Tacit Knowledge – Undocumented knowledge or information that people keep to themselves on an Agile project team without wanting to share with the rest of the team is known as Tacit Knowledge.
345. The communication channels in a team can be described by a formula called “n*(n-1)/2“, where “n“ represents the number of team members. This formula indicates that as the team size increases, the number of communication channels can grow exponentially.
346. In a Premortem, participants imagine that the project has failed and then work backward to identify potential causes of failure. This technique helps uncover risks, assumptions, and weaknesses before the project starts, allowing teams to take preventive actions.
347. Remember the Future, on the other hand, encourages teams to imagine the project has been successfully completed and reflect on the actions, decisions, and behaviors that contributed to that success. This positive outlook helps teams identify best practices, strategies, and factors that led to achieving their goals.
348. The Gulf of Evaluation is the gap between what a user thinks is happening in a system and what is actually happening. It occurs when feedback from the system is unclear or hard to understand, making it difficult for users to know if their actions are correct or if they need to adjust. Reducing this gap makes the system easier to use by providing clear feedback.
349. The ideal time estimate is typically calculated based on the team‘s collective experience and expertise, taking into account factors such as the complexity of the task, the skills and availability of team members, and the team‘s historical velocity or productivity.
     • It is not influenced by external factors such as interruptions, meetings, or other constraints that may affect the actual time taken to complete the work.
350. One of the major problems faced by organizations new to Agile is rework related to prototyping and could be viewed negatively in the beginning.
351. For vision-setting and requirements-elicitation, the collaborative game the team should be playing is “Remember the Future”. Remember the Future: This game is ideal for helping teams set a vision and envision what success looks like in the future. It encourages participants to imagine what they want the outcome of a project or product to be and how they would feel about it, thus aiding in defining goals and requirements for the project.
352. Bang for the Buck: A game used for prioritizing features or ideas based on their value and cost, useful for backlog refinement but not directly for vision-setting or requirements elicitation.
353. The Stacey Complexity Model is a framework used to determine the best management or development approach based on the level of certainty in requirements and technology. It helps teams understand whether traditional or adaptive approaches are better suited for their environment.
     • Zones:
     • Simple Zone:
       • Position: Bottom-left (clear requirements, simple technology).
       • Characteristics: Predictable, stable environment; low uncertainty.
       • Approach: Waterfall or linear planning works best here.
     • Complicated Zone:
       • Position: Bottom-middle (requirements mostly clear, technology moderately complex).
       • Characteristics: Some uncertainties exist but can be managed with expertise and planning.
       • Approach: Waterfall or hybrid approaches; use expert knowledge to address specific challenges.
     • Complex Zone:
       • Position: Middle (unclear requirements and technology with moderate to high uncertainty).
       • Characteristics: Emergent solutions; requires iterative exploration and adaptation.
       • Approach: Agile is ideal, with focus on probing, feedback, and incremental development.
     • Chaotic Zone:
       • Position: Top-right (uncertain requirements, complex or unstable technology).
       • Characteristics: High uncertainty and disorder; immediate stabilization is needed.
       • Approach: Stabilize first, then shift to Agile once manageable.
     • Disordered Zone:
       • Position: Center (lack of clarity about the state of requirements and technology).
       • Characteristics: Unclear environment; needs decomposition into smaller problems.
       • Approach: Break the problem down, then apply the appropriate approach for each smaller piece.
354. The concept of VUCA (Volatility, Uncertainty, Complexity, and Ambiguity) originated in the military to address rapidly changing, unpredictable environments. It is now widely applied in project management and organizational contexts.
     • VUCA Components:
     • Volatility:
       • Definition: Rapid and unpredictable changes in the environment.
       • Examples: Sudden market shifts, fluctuating prices, unexpected resource availability issues.
       • Strategies:
         • Use Alternatives Analysis: Evaluate different ways to achieve objectives.
         • Employ Reserves: Time, money, or resources to absorb shocks.
         • Estimate Ranges: Include contingencies (e.g., 40% of the budget as a reserve).
     • Uncertainty:
       • Definition: Unknown future events or outcomes.
       • Examples: Emerging technologies, and unpredictable legal or economic changes.
       • Strategies:
         • Gather Information: Research, consult experts, and analyze situations.
         • Experiment: Conduct trials to learn and reduce uncertainty.
         • Plan for Multiple Outcomes: Use prototypes or mock-ups to explore scenarios.
         • Build Resilience: Create psychologically safe teams that can adapt positively.
     • Complexity:
       • Definition: Numerous interconnected factors make outcomes hard to predict.
       • Examples: Intricate systems, diverse team dynamics, or multi-variable dependencies.
       • Strategies:
         • Decouple Systems: Break down into smaller, manageable parts.
         • Use Simulations: Model scenarios to anticipate outcomes.
         • Reframe Problems: Leverage diverse perspectives and team collaboration.
         • Iterative Approaches: Build incrementally, incorporating feedback (e.g., Agile).
     • Ambiguity:
       • Definition: Lack of clarity about meaning or multiple possible interpretations.
       • Types:
         • Conceptual Ambiguity: Not understanding concepts clearly.
         • Situational Ambiguity: Multiple potential outcomes exist.
       • Strategies:
         • Progressive Elaboration: Iteratively refine plans with more detail as new information becomes available.
         • Use Prototypes: Create low-cost models, wireframes, or sketches to test ideas.
         • Iterative Experimentation: Reduce ambiguity by uncovering cause-effect relationships before committing resources.
355. Set-Based Design (SBD) is a product development approach that involves considering multiple design options simultaneously rather than committing to a single solution early in the process. It is particularly useful in uncertain or complex environments and is commonly associated with Lean Product Development and Agile methodologies.
356. Reciprocal Commitment, where the Agile project team commits to delivering the specified functionality 100 % according the definition of done at the end of the iteration, and the product owner, organization and customer agree not to change priorities during the iteration and leave the team alone to “do the work”.
357. The four main artifacts used in Agile project management and product development are the Iteration Plan, Iteration Backlog, Iteration Burndown Charts and Iteration Burnup Charts. The only type of “vision statement” used as an artifact in Agile is the Product Vision Statement. 
358. Real Time, which is sometimes called Real Days or Actual Days.  This refers to the actual time during each day that the team members are available and are productively working on specific Agile project tasks.
359. Ideal Time, or Ideal Days, where you make the assumption that your Agile project team members will have no interruptions in their work, such as checking email or attending meetings, and will be 100% productive every hour of every day.
360. Relative Size, which is the recommended “sizing unit” to use for requirements size estimation on your Agile project. This sizing unit allows you to estimate the “level of effort” a user story will take to complete, relative to the other user stories you will be performing on your Agile project.
361. Ideal Size is not a recognized sizing unit for estimating the level effort of effort to complete an Agile project requirement.
362. Actual time = How long the task really takes, including delays.
363. Ideal time = How long the task would take if there were no interruptions.
364. Elapsed time = The time that passes from start to finish, which can be a mix of actual time and ideal time. The time it takes to complete tasks (elapsed time) can vary from person to person, but for a team, you can usually estimate this difference based on past experience.
365. On Agile projects, risk management can be classified as either “Organic” or “Overt.”
366. Organic risk management refers to the risk management that naturally occurs through the implementation of Agile best practices, such as iterative planning and review activities, without the need for formal, explicit risk management processes.
367. Overt Risk Management is the implementation of risk management techniques on your Agile project to explicitly identify, track and create risk responses plans for project risks.
368. Team Evaluation, Individual Evaluation and Process Tailoring are all methods of soliciting feedback from your Agile project team members. Prototyping is a form of “Product” feedback, not a form of “Project Team” feedback.
369. Agile Modeling is a tool that Agile project teams often use to create models for Agile software development, and is a collection of values, principles and practices
370. A Feature Breakdown Structure is an Agile artifact that displays the backlog of features for each of the releases on an Agile project.
371. A) Dominating – Exercising control or authority over others, often by being assertive, overpowering, or commanding. It involves having a strong influence or position in a situation, making others follow your lead or direction.
372. B) Influencing– The act of affecting or guiding someone’s behavior, thoughts, or decisions indirectly and often subtly. It typically relies on persuasion, inspiration, or demonstrating value rather than using force or authority.
373. C) Dictating – Imposing rules, decisions, or commands on others in a controlling or authoritarian way. It suggests a lack of collaboration or input from others, with a focus on issuing orders that must be followed.
374. D) Anchoring – In decision-making or perception, anchoring refers to the tendency to rely heavily on the first piece of information encountered (the “anchor”) when making judgments. In a broader sense, it can also mean establishing a firm position or serving as a stable point of reference.
375. The four distinct steps in the Value Stream Mapping process are (in order); 1) Identify the value stream target, 2) Define the current state, 3) Clarify the opportunity, and 4) Depict the desired future state. Describe the Opportunity is not a valid Value Stream Mapping process step.
376. When you think about the Agile Daily Standup Meeting, remember the term ‘synchronize’.  This Agile meeting is used to synchronize an Agile project team’s activities to ensure they are all working toward a common iteration goal.
377. Brainstorming: A collaborative technique where team members freely generate and build on ideas without criticism. Benefits: Encourages creativity, diverse perspectives, and group synergy. Challenges: Can be dominated by louder participants or veer off-topic.
378. Free-For-All: An unstructured approach where participants share ideas openly and spontaneously. Benefits: Fosters unrestricted input and creativity. Challenges: Can lead to chaos, lack of focus, or uneven participation.
379. Silent Idea Generation: Individuals write down ideas privately before sharing with the group. Benefits: Ensures equal participation, reduces groupthink, and values quieter voices. Challenges: May limit immediate collaboration or spontaneity.
380. When utilizing the interpersonal skill of Emotional Intelligence on an Agile project, Social Awareness is characterized by the use of empathy in order to understand the perspective of the person with whom you are interacting and communicating.
381. User stories represent “what” the customer wants and are measured in points (effort or complexity). Tasks represent “how” the team will achieve the story and are measured in hours, with specific team members assigned to complete them.
382. The Declaration of Interdependence was published four years after the Agile Manifesto in 2005 by a group of Agile practitioners to help implement guidelines set forth in the Agile Manifesto.
383. Adaptive planning is a technique the employs iterative development cycles in order to produce incremental product deliverables and allows you to adapt your project plans based on the current reality that surrounds and affects your Agile project.
384. Rolling Wave Planning is a form of Progressive Elaboration that focuses more on the near term plans and rolls into the longer term as more information becomes available about the project requirements. Progressive Planning and Incremental Planning are not terms associated with Agile product development.
385. Teaming Agreements refer to contractual arrangements between two or more entities (like teams, departments, or external partners) to collaborate or form a partnership for the duration of a project. These agreements outline roles, responsibilities, expectations, and terms under which the teams will work together. In Agile projects, they often focus on defining how teams will interact and collaborate, ensuring alignment and accountability across teams.
386. Working Agreements are Agile-specific agreements that a team develops collaboratively to establish guidelines on how they will operate during a project. These agreements cover topics such as communication, roles, decision-making processes, and conflict resolution. They are considered a “verbal contract” that helps ensure clarity and alignment among team members. Working agreements foster a collaborative environment and are often displayed as information radiators (e.g., visible charts or boards) for transparency.
387. In Non-Agile settings, Rules of Engagement may be more formal, outlining expectations for communication, decision-making, and roles between teams or stakeholders.
388. Work in Process is a Lean Manufacturing term that refers to the set of unfinished items being developed or waiting in the backlog that produce no business value until they are fully completed.
389. Work in Progress is a more general term that is not specific to Lean Manufacturing and refers to any work for which you are actively performing tasks at any given moment.
390. Fractional Assignment is particularly common in organizations where an individual is assigned to one or more projects simultaneously. This makes it extremely difficult for the individual to focus and achieve their maximum productivity on either project, and is not considered an Agile Project Management best practice.
     • If the time an Agile project team member has available is not 100% fully dedicated to one project, then the team member is said to be fractionally assigned.
391. Fear of conflict is one of the main reasons for team members to avoid taking responsibility, to be afraid to ask questions, and not to collaborate with each other
392. Decompose the features into stories is the best choice. The next step is for the team to continue analysis by decomposing features into stories. Such decomposition is part of adaptive planning.
393. Simplicity and reflection are core agile practices. Simplicity, “the art of maximizing the amount of work not done”, is one of the Agile Manifesto principles. Reflection is in the center of iteration retrospectives aimed to improve the team’s process and performance. Focusing on reflection and simplicity will most likely help the team improve its process, making this the best answer to the question asked.
394. On average through the course of all the sprints, some amount of time allocated for unplanned events (such as team taking time off) needs to be included as a safety in the team’s estimates.
395. Sprint timebox for each ceremony below
396. 
397. Force Field Analysis is a decision-making tool developed by Kurt Lewin. It helps analyze the forces that are driving change (forces that push for the change) and the restraining forces (forces that resist the change). The goal is to assess the strength of each force and determine actions to strengthen the driving forces or weaken the restraining forces in order to facilitate change.
398. Top of the burndown chart: Total initial planned work at the start of the sprint.
399. Bottom of the burndown chart: Remaining work at any point during the sprint, which is usually zero at the end of the sprint if all work is completed.
400. Seven lean principles are
     • Eliminate Waste: Remove activities that don’t add value (e.g., reducing excessive meetings or overproduction).
     • Amplify Learning: Encourage experimentation and feedback for continuous improvement (e.g., using iterative development in Agile).
     • Decide as Late as Possible: Delay decisions to keep options open until the last responsible moment (e.g., choosing the technology stack after gathering more user requirements).
     • Deliver as Fast as Possible: Deliver value quickly to get feedback sooner (e.g., releasing software increments every 2 weeks).
     • Empower the Team: Give teams the autonomy to make decisions (e.g., allowing developers to choose their tools for the project).
     • Build Integrity In: Ensure quality is built into the process, not inspected in later (e.g., continuous integration with automated tests).
     • See the Whole: Optimize the entire system rather than individual parts (e.g., improving cross-team collaboration to eliminate bottlenecks in a project flow).
401. The Product Owner is responsible for maximizing the value of the product and ensuring that the project aligns with customer needs and business goals. One of the key aspects of their role is tracking and reporting on the Return on Investment (ROI), as it directly impacts the product’s value and the prioritization of features.
402. A theme is a broad category or overarching goal that ties together a group of related user stories, iterations, or releases. It represents the main purpose or focus area for a set of work and helps provide context and alignment for the team.
     • Themes are often used to group related work into bigger chunks, making it easier to prioritize, plan, and track progress toward achieving strategic objectives.
403. Continuous integration: Continuous integration (CI) is about frequently integrating code into a shared repository and running automated tests. While CI helps speed up development and testing, it does not directly address the operational readiness and deployment speed issues.
404. DevOps is a set of practices that combines development (Dev) and operations (Ops) to enhance the efficiency of the development-to-deployment pipeline. It focuses on automating the deployment process and improving collaboration between development teams and operational teams.
405. Predictive (Waterfall) Approach
     • Definition: The predictive approach, also known as Waterfall, is a linear, step-by-step process. The phases of the project, analyzing, designing, building, testing, and delivering are completed one after the other in a fixed sequence, and the project is delivered all at once at the end.
     • Advantages: Works well for projects with well-defined requirements and predictable outcomes.
     • Challenges: If something goes wrong at the end, the project may need to go back and revise earlier steps, which can be time-consuming and costly. It lacks flexibility for handling changes after the project has begun.
406. Iterative Approach
     • Definition: The iterative approach involves repeating cycles of development, where feedback is gathered after each cycle to improve and refine the product. The project is developed in prototypes, and each iteration involves revisiting steps like design and development to refine the product incrementally.
     • Advantages: Provides continuous feedback, allowing teams to adjust and improve along the way, reducing the risk of major errors late in the project.
     • Challenges: While it allows for improvements, it may not result in a final product until several iterations are complete, which may delay delivery.
407. Incremental Approach
     • Definition: The incremental approach delivers a project in smaller, manageable parts (increments). Each increment follows the full development cycle analyze, design, build, test, and deliver and delivers a small usable portion of the product. New increments are added in each cycle.
     • Advantages: The project delivers usable features early, and each increment is refined based on feedback, reducing the risk of large-scale failure. It can provide value incrementally as the project progresses.
     • Challenges: While the product is developed step by step, it might require significant coordination between increments to ensure overall product coherence.
408. Agile Approach (Combination of Iterative and Incremental)
     • Definition: Agile combines both iterative and incremental approaches, meaning that the project is developed in small, usable increments, with regular iterations to refine and improve the product through feedback. The team continuously tests and gathers feedback to iterate on each increment until the product is ready.
     • Advantages: Agile maximizes flexibility and responsiveness to change. It’s particularly useful in environments where the requirements and systems are unclear, as it allows for continuous refinement and adjustment.
     • Challenges: It requires a high level of collaboration, and the scope is often variable, which means it can be difficult to predict the exact final product at the beginning of the project.
409. Hybrid Approach
     • Definition: The hybrid approach blends elements of agile and predictive (waterfall) methodologies, depending on the needs of the project. This could involve using agile practices for some parts of the project (e.g., iterative and incremental development) while applying predictive methods for other parts (e.g., large-scale planning or when working with external vendors).
     • Advantages: This approach allows flexibility in choosing the best methodology for different project elements. It is suitable for projects that have both predictable and uncertain aspects.
     • Challenges: Managing a hybrid approach can be complex, as it requires balancing the structured, linear planning of waterfall with the flexibility of agile.
410. The cost of quality refers to the total cost incurred to ensure that a product or service meets quality standards and satisfies customer requirements. These costs can be categorized into four types: prevention costs, appraisal costs, internal failure costs, and external failure costs.
411. Prevention Costs
     • Definition: These are costs incurred to prevent defects and ensure quality before they occur. The goal is to improve processes and systems to avoid the need for corrections later.
     • Examples:
       • Training employees to improve their skills.
       • Implementing better processes or equipment.
       • Developing prototypes or models to test ideas early.
       • Refactoring code to make it easier to maintain and reduce errors.
     • Impact: Prevention costs are typically the lowest and most cost-effective way to maintain quality, as they help avoid expensive issues later in the project.
412. Appraisal Costs
     • Definition: These are the costs associated with evaluating and measuring the product or service to identify defects or issues before they reach the customer.
     • Examples:
       • Testing and inspections (e.g., functional testing, code reviews).
       • Peer reviews, sprint reviews, and product demonstrations.
       • Quality audits.
     • Impact: Appraisal costs are necessary for identifying problems before the product is delivered, but they are higher than prevention costs because they require time and resources for testing and validation.
413. Internal Failure Costs
     • Definition: These costs are incurred when defects are found before the product reaches the customer, but after the product has been created or partially developed. This category includes costs for rework, corrections, and other activities needed to address problems identified during testing or review.
     • Examples:
       • Fixing defects discovered during internal testing (e.g., fixing bugs in the code or redesigning a feature).
       • Rewriting requirements or redesigning a solution due to errors.
       • Re-coding or re-developing features that do not meet quality standards.
     • Impact: Internal failure costs are more expensive than appraisal costs because the product has already been developed, and now you need to redo parts of the process, such as design, coding, or testing.
414. External Failure Costs
     • Definition: These are the costs incurred when defects or issues are discovered by the customer after the product has been delivered. This is the most expensive type of cost, as it not only involves fixing the issue but also damages the brand and customer satisfaction.
     • Examples:
       • Product recalls due to defects found after release.
       • Customer complaints or support calls to fix issues.
       • Costs associated with rework when customers report problems.
       • Loss of reputation or brand damage due to poor quality.
     • Impact: External failure costs are the highest because they involve not only the direct costs of fixing the defect but also the long-term impact on customer satisfaction and company reputation.