Certified - PMI-ACP

Work in process, often shortened to WIP, refers to the number of items currently being worked on at any given time. While it might seem logical to maximize the amount of parallel work, too much WIP quickly degrades predictability and quality. High WIP creates longer wait times, as each item competes for limited attention, and it increases context switching, which drains focus and productivity. Agile teams establish WIP limits to constrain this tendency, ensuring that attention is concentrated and flow is steady. For example, a team may decide to allow no more than three stories in progress at once, creating a visible signal when the limit is reached. On the exam, questions about flow often test whether candidates recognize that reducing WIP leads to faster, more predictable delivery. The principle reinforces that multitasking is rarely efficient; limiting work enables sustainable progress.
Throughput represents the rate at which items are completed over a given period. When combined with WIP and cycle time, throughput offers a powerful way to understand system capability. For example, if a team consistently completes eight stories per two-week sprint, their throughput establishes a baseline for forecasting future delivery. Unlike velocity, which can be distorted by estimation practices, throughput counts actual completions and thus provides objective evidence of flow. It is not about maximizing raw numbers but about sustaining consistent, reliable delivery. On the exam, throughput often appears in questions about forecasting or evaluating performance. The correct answers usually highlight using throughput alongside other measures to ground commitments in evidence rather than guesswork. In agile contexts, throughput is a measure of health, showing whether the system is moving items to completion efficiently.
Lead time is the elapsed time from when a request is made to when it is delivered. This metric reflects the customer’s perspective, capturing the total wait they experience. Lead time includes all sources of delay, from backlog prioritization to development and release. For example, if a feature request is submitted in January and delivered in March, the lead time is two months. Understanding lead time helps organizations assess responsiveness and customer satisfaction. A long lead time may indicate bottlenecks or misaligned prioritization. On the exam, scenarios about stakeholder expectations often hinge on recognizing that lead time is the most relevant measure of customer experience. Agile practices aim to shorten lead time by reducing queues, minimizing waste, and delivering increments frequently, thereby improving trust and value perception among stakeholders.
Cycle time, distinct from lead time, measures the duration from when active work begins to when it is completed. Whereas lead time spans the customer’s entire wait, cycle time focuses on the team’s process efficiency. For instance, if a story is pulled into development on Monday and finished on Thursday, the cycle time is four days. By monitoring cycle time, teams can diagnose delays and variability within their process. Shorter, predictable cycle times enable more accurate planning and faster feedback. On the exam, candidates may face questions asking which measure best reveals process efficiency. The agile answer usually emphasizes cycle time, as it highlights how effectively teams convert effort into completed increments. When combined with lead time and throughput, cycle time provides a comprehensive picture of system performance.
Flow efficiency highlights the proportion of time work spends actively being advanced compared to waiting. Many processes are plagued by long periods of inactivity, where items sit idle in queues or await approvals. Flow efficiency exposes this imbalance, often revealing that value-adding time represents only a fraction of total lead time. For example, a task may take two hours of active work but spend five days in waiting states, yielding extremely low efficiency. Improving flow efficiency requires reducing bottlenecks, streamlining approvals, and smoothing workload distribution. On the exam, flow efficiency often appears in scenarios about waste reduction or system improvement. The correct answers typically involve addressing waiting and rework rather than merely increasing effort. Agile principles emphasize making work visible, and flow efficiency provides a lens for identifying and eliminating systemic waste.
A bottleneck is the stage in a process that constrains overall throughput. No matter how efficient upstream or downstream steps become, the bottleneck dictates the pace of the entire system. For example, if testing capacity is half that of development, completed stories will accumulate in queues waiting for testers. Addressing bottlenecks involves either increasing their capacity or ensuring they are not overwhelmed. Protective policies may limit how much work enters the bottleneck to prevent starvation or overload. On the exam, bottleneck scenarios often ask candidates how to improve flow when work piles up at one stage. The agile response typically involves focusing improvement efforts on the constraint rather than pushing harder elsewhere. Recognizing bottlenecks as leverage points reflects systems thinking, ensuring that local optimizations do not mask global inefficiencies.
Little’s Law provides a simple but powerful relationship among average WIP, throughput, and cycle time. It states that average cycle time equals WIP divided by throughput. This means that controlling WIP directly influences how quickly work flows. For example, if a team maintains ten items in progress and completes five items per week, their average cycle time is two weeks. The law allows teams to make evidence-based policies, such as adjusting WIP limits to improve predictability. On the exam, Little’s Law may appear in questions about forecasting or balancing flow. Candidates should recognize that it is not a theoretical curiosity but a practical rule that enables transparent, data-driven decision-making. By grounding planning in Little’s Law, agile teams avoid wishful thinking and establish realistic expectations about system capacity.
Comparing arrival rate to completion rate reveals whether demand is aligned with capacity. If new requests enter the system faster than items are completed, WIP grows unchecked and delays mount. For instance, if a team receives ten new stories each week but only completes five, the backlog will balloon. This imbalance signals the need to re-sequence work, manage intake, or increase capacity. The exam often tests whether candidates can spot when demand exceeds throughput and identify corrective actions. The agile response usually involves limiting new work until the system stabilizes. This principle mirrors lean thinking, where mismatches between demand and capacity are seen as primary drivers of waste. Sustainable flow requires balancing what enters the system with what can realistically be delivered.
Queues and queue discipline shape how work waits and is selected. A queue represents items awaiting attention, and the rules governing selection—such as first-in-first-out, priority-based, or shortest-job-first—determine fairness and predictability. Poorly managed queues create hidden delays, uneven flow, and stakeholder dissatisfaction. For example, if items linger in queues without clear discipline, stakeholders may perceive favoritism or neglect. Adopting consistent rules ensures transparency and stability. On the exam, queue scenarios often test whether candidates recognize the impact of selection policies on flow. The correct agile response usually involves applying predictable, fair discipline to reduce variability and ensure alignment with priorities. Managing queues is part of managing system health, ensuring that waiting does not silently erode value delivery.
Batch size is the amount of work released or moved together. Large batches often seem efficient but increase variability, delay feedback, and raise risk exposure. Smaller batches reduce cycle time, allow earlier inspection, and minimize rework. For example, releasing hundreds of changes at once makes it hard to isolate defects, whereas deploying small increments allows rapid detection and rollback. The exam frequently tests understanding of batch size in scenarios about release planning or quality. The agile answer usually emphasizes reducing batch size, as this aligns with principles of incremental delivery and continuous learning. Just as small iterations increase adaptability, small batches sustain predictable, low-risk flow. By breaking work into thin slices, teams transform uncertainty into manageable learning cycles.
Variability describes the fluctuations in work arrival, execution, or output. Some variability is natural, such as differing levels of effort required for different stories. Other variability is assignable, such as inconsistent prioritization or unclear requirements. High variability increases queues and delays, making flow less predictable. Managing variability involves smoothing intake, clarifying requirements, and reducing uncertainty. For instance, standardizing story readiness reduces surprises once work begins. On the exam, variability often appears in questions about why flow is unstable or why cycle times fluctuate wildly. The correct responses usually emphasize reducing unnecessary variability and managing the rest transparently. Agile acknowledges that variability cannot be eliminated entirely but can be controlled to preserve predictability and trust in delivery commitments.
Process capability refers to the stable performance range of a system. It sets the boundaries for reliable forecasting and prevents overpromising. For example, if a team consistently delivers five to seven stories per sprint, that is their capability. Promising delivery of fifteen stories would be unrealistic and damaging to credibility. By grounding commitments in observed performance, teams build trust with stakeholders and avoid burnout. On the exam, process capability appears in scenarios about planning and commitments. The correct agile response usually involves basing forecasts on historical data rather than aspirational goals. Recognizing process capability ensures that plans respect reality, aligning agile practice with transparency and honesty. Commitments become achievable agreements rather than speculative guesses.
Percentiles and averages offer different views of performance, with percentiles often providing a more accurate picture of user experience. Averages can be distorted by outliers, masking real patterns. For example, if most requests are delivered in five days but a few take sixty, the average may misrepresent typical performance. Percentiles, such as the 85th percentile lead time, show the performance experienced by most users. This prevents teams from being misled by mathematical artifacts. On the exam, candidates may encounter scenarios about interpreting metrics. The agile answer usually favors using percentiles alongside averages, as they provide distribution-sensitive insight. Recognizing the limitations of averages helps teams avoid poor decisions and ensures that measurement reflects lived experience rather than abstract calculation.
Trend and control thinking distinguish between meaningful signals and normal noise in metrics. Overreacting to every fluctuation wastes energy, while ignoring real trends hides problems. Control charts help teams see whether variation falls within normal limits or indicates a systemic shift. For example, a sudden, sustained increase in cycle time may signal a bottleneck, whereas small fluctuations around the mean are natural. The discipline of trend and control thinking prevents knee-jerk reactions and enables thoughtful improvement. On the exam, scenarios may test whether candidates can separate noise from signal. The correct answers usually involve monitoring trends over time and responding only when evidence suggests true change. This reflects agile’s emphasis on empirical learning and responsible adaptation rather than reactive firefighting.
For more cyber related content and books, please check out cyber author dot me. Also, there are other prepcasts on Cybersecurity and more at Bare Metal Cyber dot com.
A defect is any variance between the expected behavior of a product and what is actually observed. Defects matter not only because they reduce customer satisfaction but also because they disrupt flow, requiring rework and consuming valuable capacity. Agile teams classify defects by severity, which reflects the impact on users, and by priority, which reflects the urgency of fixing them. For example, a cosmetic spelling error is a low-severity defect, while a security flaw that exposes data is high severity. Prioritization ensures that limited capacity is spent where it matters most. On the exam, defect scenarios often test whether candidates can distinguish between severity and priority or recognize how teams should manage defects within their normal flow. Agile practice integrates defect management into everyday delivery rather than treating it as a separate phase.
Escaped defects are those discovered after release, meaning they reached the customer before being detected. These represent higher risk because they damage trust, increase operational cost, and sometimes create compliance issues. Escaped defects highlight weaknesses in quality gates and testing strategies. For instance, if users frequently report performance issues in production, it may suggest insufficient performance testing upstream. While escaped defects cannot be eliminated entirely, their frequency and severity should inform prevention priorities. Teams may respond by strengthening automated tests, improving acceptance criteria, or tightening the definition of done. On the exam, escaped defects often appear in scenarios where teams must balance delivery speed with quality assurance. The agile answer usually emphasizes learning from escapes and adjusting processes to reduce recurrence.
Defect density measures the number of defects per unit size, such as per thousand lines of code or per function point. While it offers a sense of quality, its interpretation requires caution. Different components may naturally vary in complexity, criticality, or risk, making density comparisons misleading. For example, a core authentication service may tolerate very few defects, while a marketing feature might accept more minor issues. Agile teams use defect density as one input among many, not as a singular measure of quality. On the exam, candidates may face questions about interpreting defect density across systems. The correct responses usually caution against simplistic comparisons and emphasize context-sensitive interpretation. Agile quality practices focus less on counting defects and more on preventing them by embedding quality into everyday work.
Test coverage indicates the proportion of code or behavior exercised by tests. High coverage can create confidence, but coverage alone is not sufficient. It is possible to have high coverage while still missing critical edge cases or user scenarios. For example, automated tests may confirm that a login page loads but fail to verify usability under load. Agile teams combine coverage with risk-based thinking, ensuring that tests focus on areas of high impact and uncertainty. Coverage provides visibility but should be used as a guide, not as a goal in itself. On the exam, coverage scenarios often test whether candidates can recognize its limitations. The agile answer usually highlights the need to balance coverage metrics with judgment about where defects would be most damaging.
Different layers of testing provide complementary assurance. Unit tests validate small components in isolation, offering speed and precision. Integration tests confirm that components work together as intended, catching issues at boundaries. End-to-end tests simulate realistic user journeys, ensuring that the whole system delivers value. Each layer has trade-offs: unit tests are fast but limited in scope, while end-to-end tests provide realism but are slower and more brittle. Effective agile teams balance these layers to maximize confidence with minimal overhead. For example, a team might rely on a large suite of automated unit tests, a moderate number of integration tests, and a few high-value end-to-end tests. On the exam, scenarios about test strategy often emphasize layering tests appropriately rather than relying exclusively on one type.
Test-Driven Development, or TDD, is a practice where developers write tests before writing the corresponding code. The process follows a rhythm: write a failing test, implement code to make it pass, then refactor while keeping tests green. TDD encourages better design by forcing developers to think about behavior and interfaces upfront. It also supports safe refactoring, as the test suite provides immediate feedback if functionality breaks. For example, before implementing a new calculation method, a developer writes a test specifying expected inputs and outputs. TDD requires discipline but yields cleaner, more maintainable code. On the exam, TDD may appear in questions about design or quality practices. The agile response usually highlights its role in improving cohesion and reducing defects, not as a guarantee of perfection but as a tool for building quality in.
Acceptance Test–Driven Development, or ATDD, extends the test-first approach to collaboration between business, testing, and development roles. Teams define acceptance tests together before development begins, ensuring that everyone shares a common understanding of what “done” means. For example, before coding a new feature, the team may agree that “given a valid username and password, when the user logs in, then the system should grant access within two seconds.” These tests drive development and reduce rework by aligning expectations early. On the exam, ATDD often appears in scenarios about clarifying requirements or reducing ambiguity. The correct agile response usually involves using ATDD to bring stakeholders and teams together, demonstrating that quality starts with shared definitions, not just post-hoc validation.
Behavior-Driven Development, or BDD, focuses on creating shared, executable specifications in business-readable language. Using formats like “Given, When, Then,” teams write scenarios that describe behavior in terms stakeholders understand. For example, “Given a registered user, when they attempt login with an incorrect password three times, then their account should be locked.” These specifications can be automated, bridging the gap between business and technical teams. BDD reduces miscommunication, clarifies intent, and ensures that functionality aligns with stakeholder needs. On the exam, BDD may appear in scenarios about communication gaps between business and development. The agile answer usually highlights its value in creating shared language and reducing rework by aligning intent with implementation.
Exploratory testing is the practice of simultaneously designing and executing tests to discover issues not covered by scripted cases. It emphasizes tester creativity and domain knowledge, allowing them to probe unexpected behaviors. For example, a tester exploring a shopping cart feature may attempt unusual sequences of actions or edge-case inputs, uncovering defects automated tests miss. Exploratory testing is structured but flexible, often time-boxed and guided by charters. On the exam, exploratory testing may appear in scenarios where scripted automation has failed to catch usability or integration issues. The agile response usually emphasizes its role as a complement to automation, capturing the human insight that scripted tests cannot fully replicate. Agile quality relies on both automation and exploration for comprehensive assurance.
Static and dynamic analysis provide automated ways to detect defects early. Static analysis examines code without executing it, identifying vulnerabilities, style violations, or complexity issues. Dynamic analysis runs code in controlled environments, catching runtime errors such as memory leaks or performance bottlenecks. For example, static tools may highlight unused variables, while dynamic tests may reveal instability under load. Both approaches enhance quality and support compliance with standards. On the exam, scenarios about preventing defects upstream often reference analysis tools. The correct agile response usually involves incorporating static and dynamic analysis into continuous integration pipelines, ensuring that quality checks occur early and continuously. These practices align with agile’s principle of embedding quality into the process rather than relying solely on end-stage inspection.
Reliability and availability are key service quality attributes. Reliability refers to the system’s ability to perform consistently under expected conditions, while availability measures the proportion of time it is operational and accessible. Organizations often set explicit targets, such as “four nines” of availability, meaning 99.99 percent uptime. Error budgets balance innovation and reliability by allowing controlled levels of failure. For example, a team may accept occasional outages in exchange for faster feature delivery, provided reliability remains within agreed limits. On the exam, reliability and availability often appear in scenarios about balancing delivery pace with service commitments. The agile answer usually involves acknowledging these attributes as constraints on design and delivery, ensuring that innovation does not come at the expense of customer trust.
Mean time to detect (MTTD) and mean time to restore (MTTR) measure how quickly teams identify and recover from incidents. MTTD reflects responsiveness in spotting issues, while MTTR reflects how fast service is restored after disruption. For example, a system with an MTTD of five minutes and MTTR of one hour provides a very different customer experience than one with detection lagging for hours. Improving these measures requires monitoring, alerting, and streamlined recovery processes. On the exam, operational metrics often test whether candidates connect responsiveness to customer impact. The agile response usually emphasizes reducing MTTD and MTTR to align with agile’s commitment to delivering ongoing value. These measures remind practitioners that quality is not only about building features but also about sustaining service once live.
Quality gates in delivery pipelines act as explicit criteria for promoting work from one stage to another. Gates may include passing automated tests, meeting performance thresholds, or completing security scans. Their purpose is to prevent regressions and preserve the integrity of the definition of done. For example, a pipeline may block deployment if code coverage drops below an agreed threshold or if critical vulnerabilities are detected. Quality gates provide discipline while enabling speed, ensuring that increments remain trustworthy. On the exam, pipeline scenarios often test whether candidates recognize the importance of automated, enforceable gates. The agile answer usually involves integrating quality checks continuously rather than relying on late-stage manual reviews. Gates sustain flow by ensuring quality without slowing delivery.
Risk-based testing prioritizes effort on areas with the highest impact and uncertainty. Not all functionality requires the same level of testing; some features are mission-critical, while others are less consequential. For example, payment processing demands rigorous testing, while a cosmetic theme change may require only light checks. By concentrating resources where failure would be most damaging, teams optimize quality assurance investment. Risk-based testing aligns with agile’s principle of delivering maximum value with limited capacity. On the exam, testing scenarios often ask how to allocate limited time. The correct agile response usually involves focusing on high-risk areas rather than attempting to achieve uniform coverage. This principle underscores that effective testing is about strategic allocation, not blanket activity.
In conclusion, metrics, flow, and quality vocabulary provide a shared language for managing delivery systems. Defects, density, and coverage terms describe quality, while layered testing approaches balance speed and assurance. Practices like TDD, ATDD, and BDD align development with intent, while exploratory testing and analysis tools broaden coverage. Reliability, availability, MTTD, and MTTR connect technical performance to customer trust, while quality gates and risk-based testing embed discipline into pipelines. Together, these terms emphasize that measurement is not for gaming but for learning. Agile teams use metrics to improve flow, shorten feedback loops, and deliver fit-for-purpose increments sustainably. For exam candidates, mastering these terms equips them to reason effectively in scenario questions, demonstrating an understanding of how measurement, quality, and flow intersect in agile delivery.