PMI-ACP flashcards

Mindset

• Test first the assumption that is least known and most damaging if wrong, and re-rank after every result: once one kind of question is settled, the other kind often becomes the riskiest.
• A testable hypothesis names the metric, baseline, threshold and time frame, agreed before the test; judge it on that metric, not on vanity numbers.
• Use the cheapest artefact that answers the question validly; for behaviour in real conditions, fake the back end, not the context.
• An MVP is the least effort that produces validated learning; an MMF is the smallest unit customers will pay for and the business can sell, including the operational and regulatory pieces selling needs.
• A spike answers one precisely stated question within an agreed timebox; keep its learning and rebuild its code to the definition of done.
• Behaviour beats opinion, and a concurrent, randomized control beats comparisons across time periods or self-selected groups.
• When a timebox ends, decide: a missed threshold is valid learning, never a reason to change the criteria, and an in-between result calls for a new focused test.
• For uncertain decisions that are costly to reverse, experiment on several options and commit at the last responsible moment, before an important alternative is lost.
• Innovation needs planned capacity, experiments in the product backlog, guardrails instead of approvals, self-service tooling and metrics that do not punish exploration.
• Feature toggles control reversibility, small cohorts control exposure, and shadow runs test new logic on real inputs with no user impact.

• Left over right means valued more, not instead of: keep documentation, contracts, tools and plans where they add value.
• The twelve principles diagnose problems: daily business access and live conversation, sustainable pace, simplicity, self-organizing teams.
• Progress is working, accepted product; no partial credit, and testing belongs inside the iteration.
• Cynefin: clear sense-categorize-respond, complicated sense-analyze-respond, complex probe-sense-respond, chaotic act-sense-respond; in confusion, split and classify the parts.
• Complacent best practice can drop a clear system over the cliff into chaos.
• Stacey: read agreement (what) and certainty (how) separately; simple work can be planned, and near anarchy you reduce uncertainty before iterating.
• A complex adaptive system shows emergence, self-organization and non-linearity; guide it with a few rules and feedback, not a blueprint.
• Suitability filter: centre agile, middle band hybrid, outer edge predictive; one outlier is a risk to fix, and diverging scores are a finding to discuss.
• Integrate models by need: Kanban for interrupts, XP practices inside Scrum, a scaling layer for multi-team dependencies, hybrid by component or governance layer.

• The practitioner facilitates and coaches; the team writes its agreements, makes its decisions and chooses its improvements.
• A vision works only when the team can use it for trade-offs: co-create it in a workshop, and align on users and goal when feature debates keep stalling.
• Working agreements are written by the team, enforced by the team through the retrospective, and reworked by the whole team when membership or context changes.
• Tuckman stages map to directing, coaching, supporting and delegating; membership changes cause regression, and directing a performing team suppresses it.
• High-performing teams are dedicated, stable, small and cross-functional, with generalizing specialists and shared goals; split big teams along product areas, not skills.
• Retrospective output should be one or two owned actions with a baseline and a success criterion, reviewed first at the next retrospective.
• Swarming, pairing, mobbing, feature teams, communities of practice and joint retrospectives remove hand-offs instead of scheduling them.
• Use fist of five or Roman voting for one proposal and dot voting for many options, reveal together, and hear low-support concerns before deciding.
• Disagree, then commit; revisit a team decision only by bringing new evidence back to the team.
• Assess agile understanding before tailoring (Shu: follow and learn purpose; Ha/Ri: adapt through time-boxed trials); coordination structure grows with the number of teams and their dependencies.

• An information radiator is a large, visible, current display anyone can read at a glance without asking; information that must be fetched is in a 'refrigerator'.
• The team owns and updates its radiators; a stale or cluttered radiator misleads, so keep few displays and keep them current.
• When a measure such as velocity is misused, coach the person misusing it and radiate team-level progress; do not hide the chart.
• Report the status the data shows, and use a burnup with a separate scope line when scope changes.
• Post the process (definition of done, column exit criteria, WIP limits, expedite policy) on the board itself.
• Flag blocked work and show card ageing as it happens; describe the blocked work and the help needed, never who is to blame.
• Show risks with their response and owner; a risk burndown shows exposure falling over time, and risk work belongs on the board.
• Share learning by bringing it to people (open reviews, regular cross-team forums), while keeping retrospectives the team's own.
• Agree how the team raises problems as they arise; the standup is the team's loop, not a report to the scrum master.
• Co-located teams sit together with caves and commons; distributed teams use overlap windows, written decisions and channel norms; hybrid teams default to the medium everyone can use.

• Psychological safety is a shared belief that the team is safe for interpersonal risk; it is built by behaviour, not by policies or announcements.
• Blameless reviews ask how the system let a failure happen; "be more careful" is not a fix, and no blame never means no follow-up.
• Turn labels about people into timelines and flow data, and use data to build shared understanding rather than to declare a winner.
• The prime directive removes blame, not problems; a safety check measures how freely people can speak, anonymously, and low results change the session with the team's input.
• Safe is not soft: high safety with high standards is the learning zone; fix fear by raising safety, not by lowering goals.
• How authority figures react to bad news decides whether it arrives early: thank the messenger, then work the problem; leaders go first in admitting mistakes and speak last.
• Dialogue seeks understanding and debate seeks victory; explore in dialogue, then converge and commit.
• Give feedback with Situation-Behaviour-Impact, privately and soon; ask for feedback and always report back what changed, including when the answer is no.
• Make challenge normal with pre-mortems and devil's advocates, and change externally owned practices with evidence and a trial through their owner.

• A feedback loop's length is the whole time from action to adaptation; every practice in this task moves feedback earlier or makes it more direct.
• Involve stakeholders and users from chartering and the first iterations, so they react to working product repeatedly and first-hand; showing unfinished work is the point.
• Find everyone who can use, approve or block the product at the start; a late-discovered approver should join refinement and reviews, not a final gate.
• Proxies help decide but do not replace direct feedback from real users; observe and test with users where they work, within the constraints.
• In a fixed timeframe, fix time and cost, flex scope, protect quality and deliver highest value first; scope is the lever because people, pace and velocity do not stretch reliably.
• MoSCoW protects a deadline only when the Must-haves fit with room to spare; otherwise split and challenge the Musts with the product owner.
• Order work by value per unit of build time and release incrementally; for time-sensitive value, compare what each item loses by waiting.
• Use the shortest feedback loop that answers the question: pairing, tests on every commit, story acceptance, prototype tests, reviews, releases.
• Design thinking: empathize, define, ideate, prototype, test; define one problem before generating solutions, and prototype cheaply with real users.
• Lean startup: minimize total time through build-measure-learn, fix the slowest step, plan learn-measure-build, and release changes in small batches.

• A failed first attempt or a learning dip means 'not yet': inspect the evidence and plan the next try instead of concluding the team can't.
• Recognize effort, strategy and learning, and align what the organization rewards; people follow incentives, not slogans.
• Turn people who resist a change into co-designers, plan capacity for the learning dip, and learn the new thing together.
• Welcome late change for the customer's competitive advantage, and keep it affordable with test automation and easy-to-change code.
• Change lands in the product backlog, ranked by the product owner; under fixed time, new value in means lower value out. Mid-iteration, the goal holds and the product owner and team renegotiate scope.
• Tailor governance with its owners: control the budget and goal envelope, and let the product owner reorder what's inside.
• The team owns its process: show it the data, let it choose, try one change for a set period and review it. Match the cadence to how fast priorities change.
• Generalizing specialists (T-shaped people) let work follow the priorities; spread scarce skills by pairing, swarming, coaching and a skills matrix read against the roadmap.
• Experts and leaders model cross-skilling by pairing so others drive and by doing work outside their own specialty.
• Decide on future value, not sunk cost, and treat the roadmap as a living plan revised with the stakeholders who depend on it.

Leadership

• Empowering means growing the team's ability to decide and act; ask whether your response leaves the team more or less dependent next time.
• Trust comes from transparency (known, unknown, when more is expected), kept commitments and decision rights that are agreed with managers and never reversed after the fact.
• Motivation comes from autonomy, mastery and purpose; find the missing driver. Rewards aimed at individuals and contingent prizes on creative work undermine it, and any planning measure turned into a target gets gamed.
• People experiment when trials are small, timeboxed and framed as learning; if someone's reaction to failure is the blocker, address it with that person.
• Training when the knowledge is missing, coaching when it exists but is not applied, mentoring when someone wants an experienced person's guidance; the method, not the helper, decides the label.
• Coach by asking questions so the team reaches its own answer, and match the stance to Shu-Ha-Ri: teach the standard to beginners, support purposeful adaptation by experienced teams.
• Collective ownership rests on one shared goal, pulling work, swarming and team-level recognition, not pre-assigned stories or individual metrics.
• Emotional intelligence: self-awareness recognises your reaction, self-management controls it; empathy starts with a private check-in; influence links your request to the other person's goals; in conflict, acknowledge and restate before solving.
• Non-verbal cues, especially words and body language that disagree or a change from someone's normal behaviour, are prompts to check neutrally or privately, never proof and never something to call out in public.
• Read self-assessments for spread and trends, let the team discuss and pick one or two areas, and keep the results with the team for its own learning.

• A workaround treats the symptom; a root-cause fix changes the condition the evidence identifies. A problem that keeps coming back after being cleared is still open.
• Five Whys: keep asking until you reach a process cause, never stop at a person, and follow every branch the evidence supports.
• Fishbone: specific problem statement at the head, everyone who touches the process in the room, brainstorm together, then test candidates with data.
• Pareto ranks logged causes by frequency; a value stream map shows where elapsed time goes across groups; a fishbone maps many contributing causes.
• Points inside control limits are normal variation, so don't investigate or tamper; a point outside a limit, or seven in a row on one side of the mean (PMI's rule of seven), is a signal.
• Candidate causes are hypotheses: agreement and a manager's theory are not evidence, and the method should not build in the assumed cause.
• The team generates and chooses its own fix; the leader facilitates, and roles involved in the cause (such as the product owner) take part.
• Pick the fix with the best value under real constraints, fix shared problems once at the source, and set a success measure and review date; an unchanged outcome after full adoption means revisit the diagnosis.
• Contain harm to customers first, then find the root cause; swarm on blockers; surface problems at the stand-up and solve them in a follow-up straight after.
• Escalate what the team cannot fix, with data and impact, and keep the product owner informed; keep what it can fix; close only when the team confirms the effect has stopped.

• Agile teams capture and act on lessons every iteration through retrospectives, and share urgent knowledge immediately rather than waiting for the next ceremony.
• A lesson is only learned when it changes behaviour: bring it to planning, turn it into backlog items or checklist steps, and avoid approval gates.
• Retrospective learning should travel beyond the team, but the team decides what leaves the room; team-led cross-team sessions spread insight without breaking safety.
• A community of practice is voluntary, member-led and has no authority over teams; revive a fading one by asking members what would make it valuable, and judge it by problems solved.
• Use a community of practice for ongoing peer learning, a time-boxed working group for a specific decision, and a center of excellence for standards and governance.
• Explicit knowledge goes into living documents; tacit judgement transfers through pairing, shadowing and shared work.
• A single expert is a bottleneck and a risk: turn the expert from doer into guide, and agree the short-term cost with the product owner.
• Use organizational knowledge assets early, prefer actual results over original plans, engage the people who did the work, and adapt rather than adopt their processes.
• Match the sharing format to the goal, audience and constraints: talks for awareness, hands-on sessions for skill, asynchronous living guides for distributed teams.
• Knowledge sharing needs reserved capacity (in sprint planning or WIP limits) agreed with the product owner, and required updates belong in the definition of done and estimates.

• Doing agile is following practices; being agile is living the values they serve. When practices become rituals, revisit their purpose with the team before changing anything.
• Build stakeholder awareness through their own concerns and working increments, not theory or old-style reports. Velocity is never a target.
• Teach values by experience: simulation, then debrief, then one small change applied to real work.
• Leaders are copied for what they do. Model transparency and experimentation, and repair any say-do gap with visible action.
• Coach anti-patterns by making their cost visible and teaching the principle; coach people outside the team privately before escalating.
• Kaizen means small, frequent, team-owned improvements that are tried and reviewed; improvement can happen any time through an improvement board or intraspective.
• Improvement needs planned capacity agreed with the product owner, not spare or after-hours time; agree advance permission with governance for small, reversible trials.
• Keep strong teams improving with fresh retrospective formats and stretch goals.
• Recognize agile behaviours specifically, promptly and peer-to-peer; never reward overtime or heroics — fix the cause behind them.
• Celebrate milestones and early learning with the team, and influence HR and managers so reviews reflect shared team results and colleagues' input.

• Purpose is the why and for whom; features, modules and dates are scope.
• The product vision box and the agile charter (vision, mission, success criteria, ways of working) build a shared picture because people create them together.
• Conflicting stakeholder readings mean the vision is not shared: bring the groups together and pin it down with measurable success criteria.
• Awareness and approval are not understanding; check understanding by having people explain the vision and apply it to real choices.
• Test each request by how it advances the vision, with the requester; effort, seniority and source do not decide its place.
• Judge increments by the vision's outcome, not applause or plan delivery; name drift openly and correct it in the backlog order.
• When organizational goals move or the product succeeds on the wrong measure, revisit the vision and its measures with leadership; the backlog follows.
• A vision changes by deliberate, evidence-based decision with the sponsor and stakeholders, never by drift or one person's yes or no.
• Use the vision in every planning session and review, frame each iteration goal as a step towards it, and tailor one vision to each audience.
• Introduce newcomers to the vision early; a shared vision lets the team make trade-offs without waiting for approval.

• Open disagreement about the work that ends in decisions is healthy; no visible disagreement at all is a warning sign.
• Speed Leas' levels: 1 problem to solve, 2 disagreement (self-protection), 3 contest (winning, 'always/never'), 4 crusade (factions and principle), 5 world war (intent to harm).
• Match the response to the level: observe at 1, support at 2, get factual and negotiate at 3, shuttle diplomacy at 4, prevent harm at 5.
• Let the team resolve low-level conflict itself and coach it to do so; a practitioner who referees every dispute gets more disputes.
• Look for the structural cause first: unclear definitions, conflicting incentives, scarce resources or unworkable rules.
• Ask what each position protects or makes possible; meeting both interests is collaboration, splitting the difference is compromise.
• Collaborate when the issue matters and time allows; decide trivial issues quickly, compromise under short-term pressure, and follow the agreed decision rule in emergencies.
• Recurring friction is solved by the team's own working agreement, kept current; once the team decides, disagree and commit.
• Move heated text arguments to a private live call, and route harassment, policy breaches and priority conflicts to their proper owners.

Product

• A story is a promise of a conversation: resolve ambiguity with whoever owns the need (or someone they empower to decide), then confirm it with acceptance criteria.
• Acceptance criteria belong to one story; the definition of done applies to every item; the definition of ready is a light entry agreement, not an approval gate.
• Refine just in time: roughly one to two iterations of ready items at the top, coarse epics below.
• The product owner orders the backlog with stakeholders; developers inform it with dependencies, cost and risk; the scrum master facilitates rather than decides.
• MoSCoW needs real contingency; Kano says meet must-be features first, and its categories drift over time.
• Pick the financial measure that matches the stated goal: NPV for lifetime value, payback for cash recovery, cost of delay for time-sensitive value.
• Put risk spikes early in a risk-adjusted backlog, and order compliance work by its deadline, not its popularity.
• Split vertically by workflow step, operation, business rule or data variation, never by technical layer; a first release takes the simplest story under every activity of the story map.
• Story points are relative, team-specific and sized by everyone who does the work; re-size only remaining work.
• Use planning poker for a few items worth discussing, affinity estimating for many, Wideband Delphi against anchoring, T-shirt sizes for early epics.

• An increment is aligned with business priorities when the team pulls work from the top of a backlog the product owner keeps ordered by current value; check the order before every planning session.
• A new priority mid-iteration goes to the top of the backlog for the next increment; only an obsolete goal justifies ending an iteration, and only the product owner decides that.
• The increment goal is one outcome that fits one iteration, shaped together by the product owner and developers; the goal is the commitment, the stories are the forecast.
• Hold the goal and the timebox; renegotiate the remaining scope with the product owner when work proves bigger than expected.
• Done means meeting both the story's acceptance criteria and the shared definition of done; acceptance criteria can add to the definition of done but never subtract from it.
• Only done work is demonstrated; undone work returns to the backlog. Teams raise their definition of done as they learn, and teams sharing one product share one definition of done.
• The review is a working session on the working increment with real users present, aimed at shaping the next increments, not a status report or sign-off.
• Review feedback becomes backlog items that the product owner orders by value against the product goal, however small or senior the request.
• Slice vertically so every increment works end to end; a done increment is releasable, and the product owner decides when, including limited releases for early feedback.
• Measure value with outcomes (and leading indicators when outcomes lag), not velocity; agile SPI = actual percent complete / planned percent complete, CPI = EV / AC, and above 1 is favourable.

• Board columns are the team's real workflow steps, waiting steps included; not people, priorities or iterations.
• A Done sub-column turns a push handoff into a visible queue the next step pulls from.
• The team designs its own board; consistency across teams comes from mapping columns to a few shared states, not one template.
• A task board holds one iteration's plan and is reset each iteration; a Kanban board never resets, and that unbroken flow is what cycle time measures.
• If the team spends capacity on it, it goes on the board: support work, deadlines, classes of service and improvement actions.
• Add a chart when a question needs it, choose the chart that answers that question, and teach people to read it.
• A burndown that rises with no new scope means work was discovered; remaining hours are re-estimated, never estimate minus time spent.
• Forecast from a burnup as a range from the slowest and fastest velocity; when scope grows, the gap closes at velocity minus growth.
• On a CFD, vertical gap is WIP, horizontal gap is time, slope is throughput; a widening band is a bottleneck, and cycle time is about WIP divided by throughput.
• Whoever does the work moves the card when the work moves, under agreed rules, and every audience's view is drawn from that same live data.

• Value is defined before building as success criteria: an outcome with a baseline, a target and a timeframe, not a feature list, fixed scope or velocity.
• Pair a lagging outcome (annual retention or revenue) with a leading behaviour measure you can observe within weeks of each release.
• Value is defined with buyers, users and other stakeholders and aligned to organizational goals; when they disagree, facilitate shared measures, and the product owner decides the order.
• Security, privacy and compliance are part of value and are built into every increment. Rules for every item go in the definition of done; story-specific rules go in acceptance criteria.
• Privacy by design means collecting only the data the purpose needs, making the protective setting the default and building consent, deletion and retention into the increment that collects the data.
• Technical debt is a value problem: show each item's repayment effort and the slowdown it causes, and plan repayment with the product owner. When a date and sustainable pace conflict, change scope, not hours or quality.
• Simplicity optimizes increments: no gold plating, the common case first, build for the need you have.
• WSJF = cost of delay divided by duration; enablers carry the cost of delay of what they block, and a high-value slice of a big item can be scored and delivered first.
• Value is realized only when increments are in use: shorten the path from done to in use, and support adoption, including the practices around the product.
• Judge results with actionable outcome measures, check side effects and other causes before declaring success, and when results stall, inspect why before adapting the backlog.

Delivery

• NPS asks about recommending (0-10, promoters minus detractors), CSAT about satisfaction with one thing, customer effort about how easy a task was; pick the one whose question matches the goal.
• For captive users, usage is not satisfaction; measure what the goal names, at the moment of use.
• When words and usage disagree, usage shows there is a problem and watching users shows what it is.
• Measure satisfaction after each increment with at least one question that never changes, and rule out coincident causes before crediting an increment.
• Averages, falling response rates and self-selected respondents can hide the customers who are unhappy; segment and go find the missing voices.
• Small increments of working product make mistakes cheap; documents, sign-offs and mock-ups do not give the same feedback.
• Release frequency is limited by how fast you can prove nothing broke: continuous integration, automated regression tests and a deployment pipeline keep the product releasable.
• Deploying is not releasing: feature flags let chosen users try finished work in production long before everyone does.
• Analytics tell you where and how many, observation and interviews tell you why, split tests tell you which design performs better.
• Feedback is incorporated only when it is reviewed regularly, weighed by goal and representativeness rather than volume, ordered in the backlog, and its outcome, including 'not now' and 'no', is told to the people who gave it.

• Start from the audience's decision, then choose the metric: WIP and cycle time for the team, forecasts for the product owner, outcomes and forecasts for sponsors and finance, lead time for customers.
• Lead time (request to delivery) is what customers feel; cycle time (start to done) is what the team controls. Promise customers a high percentile of lead time.
• Velocity is a team's own planning aid: count only done work, never compare teams with it, and re-baseline after team, definition-of-done or iteration-length changes. Productivity is read as a team trend, never a ranking.
• A metric made into a target gets gamed; pair speed or volume metrics with quality and value metrics and keep the counted unit stable.
• WIP and item age are leading indicators of delay; revenue, retention and past velocity are lagging.
• Judge a metric against its own normal range and trend, and normalise by volume, time and capacity before calling it better or worse.
• Forecast with ranges from real throughput, using net burn when scope grows and like-for-like items; pick the percentile by the cost of a miss.
• Radiate with definitions, data dates and trends; show bad news with context; act on a forecast while choices remain.
• Approved iterations track what the product owner or stakeholders actually accepted; an increment that is not accepted is a signal to resolve at once.

• An impediment is blocking work now and needs action; a risk is uncertain and future and needs assessing, a response and monitoring. A risk that occurs becomes an impediment: run the prepared response and replan.
• Identify risks early with the whole team, including the product owner. A pre-mortem with silent writing first surfaces risks that optimism or a dominant voice would suppress.
• The practitioner facilitates; the team chooses the response. When a response changes scope or release content, the team and product owner decide together.
• Pick avoid, mitigate, transfer or accept by weighing the response's cost against the exposure and the project's constraints, such as a fixed date.
• A risk-adjusted backlog ranks risk responses with features. EMV = probability × impact; when response costs differ, compare exposure removed minus response cost.
• Spikes are timeboxed and succeed when they answer their question, even with a 'no'. Do risky work, or a spike on it, early, especially when it could change the design of high-value work.
• Prioritize impediments by the value they block, whether anyone owns them and lead time. Fix team-controlled impediments inside the team; escalate the rest with data on delayed value.
• Give significant risks an owner and an early-warning trigger, act when it fires, keep risks on the team board, review them at regular events, and question any risk burndown that rises or drops without evidence.
• Alert other teams and component owners about shared risks; CI, automated regression tests, TDD and deployment automation reduce delivery risk at the source; lessons learned must become backlog actions or automated controls.

• Waste is anything that consumes time or effort without adding what the customer values; the task is visualize, identify, prioritize, iterate.
• Map the real flow from request arriving to change in use, with people from every step and actual timestamps, not the documented process.
• Required steps are necessary non-value-added: keep their purpose, cut their effort and wait. A deliverable the customer wants is value-added even if it is a document.
• Process cycle efficiency = value-added (in practice, active work) time / total lead time; cutting waits raises it, cutting work usually lowers it.
• Most lead time in knowledge work is waiting, so shrink queues before speeding up the work.
• The seven wastes: partially done work, extra features, relearning, handoffs, task switching, delays, defects (the 2003 list also had extra processes).
• Reduce handoffs by collaboration, and confirm with the consumers of a report or approval before removing it.
• Measure the flow, not people: cycle time by state, blocked time, rework share, usage data; shorter feedback loops catch wrong work earlier.
• Optimize the whole: busy specialists and batching can lengthen end-to-end lead time.
• Change one thing at a time, measure, update the map and look for the next constraint.

• Continuous improvement is a loop: obtain metrics and feedback, implement a change as an experiment, evaluate it, then keep, adapt or abandon it.
• Read several metrics together and add customer, stakeholder and health-check feedback; a single stable metric can hide declining quality or flow.
• Retrospective stages: set the stage, gather data (facts and feelings), generate insights, decide what to do, close. Skipping insights produces symptom fixes that recur.
• Good improvement actions are specific and observable, and each retrospective checks whether the previous actions worked, not just whether they were done.
• Run changes as time-boxed experiments with an expected result, a representative baseline with its normal range, an evaluation date and a stop condition.
• Use an intraspective when an experiment needs attention mid-iteration, and a pre-mortem before a significant change to set rules and early warning signs.
• Tailor only the part of the process the evidence implicates, and trial the tailoring like any other change.
• Judge outcomes, not activity; one good point inside the old range is noise; pair every improvement metric with a balancing metric and rule out confounding changes.
• Expect a J-curve dip with a new practice, but a pre-agreed stop condition always wins; after a deliberate shift, recalculate control limits from post-change data.
• Standardise a proven change within its tested scope, and lock it in through the definition of done or the working agreement.

• Customers include funders, users, affected people, internal consuming teams and people who avoid the product; analyze all of them, directly where possible.
• Ask what a request is for, and what the customer does next with the result, before deciding how to build it.
• Observe when words and evidence disagree; interview for depth; survey for breadth; workshop and model together when knowledge is split across groups.
• Personas come from research, change when evidence contradicts them, and each distinct user group gets its own persona.
• A story map runs the user journey across and priority down; the first release is the thinnest slice across the whole journey.
• When customer groups conflict, explore the underlying needs together, test options cheaply if needed, and let the product owner decide on value.
• Acceptance criteria are concrete, objective examples of observable behaviour, agreed by customer, developers and testers before building.
• Validate each story as soon as it is finished; a story that misses any criterion is not accepted, earns no points and returns to the backlog.
• New wishes about accepted work, and needs discovered after acceptance, become new backlog items; accepted stories are not reopened.
• Spend scarce customer time on hands-on feedback and shaping priorities; let users discuss details with developers while the product owner keeps priorities; agile contracts use incremental pricing, dynamic scope or early cancellation.

• A WIP limit is the maximum number of items allowed in a state at once; it turns a board into a pull system: stop starting, start finishing.
• Little's Law: average cycle time = average WIP ÷ average throughput — valid only when starts and finishes are roughly balanced.
• If throughput is flat and cycle time grows, check WIP before adding capacity.
• When the next stage is full, help finish there; an unlimited queue column is hidden WIP.
• Limit WIP where the waiting happens: features across teams, initiatives across the portfolio, goals one at a time by value.
• Route outside requests through one intake owned by the product owner; a rotating interrupt role shields the rest of the team.
• Expedite lanes carry their own small limit and explicit entry criteria; expedite items may exceed column limits.
• Start limits a little below current WIP and tune with data: never-reached limits are too high, idle people plus falling throughput means too low.
• Watch the age of open items, read with their position in the workflow, to catch stuck work early.
• Improve the constraint (queue before, starvation after); near-100% utilization grows queues, and slack is best spent helping the bottleneck.

Yes — the whole PMI-ACP deck is free and needs no account, as is every PMI-ACP revision lesson. Create a free account to save progress and drill practice questions; full-length mock exams are a one-time unlock per certification.