Free PMP, PMI-ACP, PMI-RMP, Scrum, CAPM & PMI-PBA Flashcards

Free flashcards for every PMP, PMI-ACP, PMI-RMP, Scrum Master, CAPM and PMI-PBA key term and PMP formula, by domain — flip, mark what you know, and keep reviewing the rest.

PMP key terms

People

Vision statement

A short, inspiring description of the future the project will create. The PM uses it to align the team and stakeholders on why the work matters. Read the chapter

Servant leadership

A leadership style that puts the team first: removing obstacles, shielding the team, coaching and supporting rather than commanding. The default leadership style on the exam for agile and high-trust teams. Read the chapter

Shared purpose

A common understanding, across team and stakeholders, of what the project is for. When subgroups drift apart, re-anchoring them to the shared purpose is usually the PM's first move. Read the chapter

Withdraw/Avoid

Retreating from or postponing a conflict. Only appropriate when emotions need to cool or the issue is trivial — it doesn't resolve anything. Read the chapter

Smooth/Accommodate

Emphasising agreement and conceding on minor points to keep harmony. Protects the relationship but leaves the real issue unresolved. Read the chapter

Compromise

Each side gives something up to reach a decision (lose–lose). Quick, but rarely the best answer when there's time to collaborate. Read the chapter

Force/Direct

Imposing one view through authority (win–lose). Reserve it for emergencies, safety or truly non-negotiable issues — it damages trust. Read the chapter

Collaborate/Problem-solve

Working through the disagreement openly to reach a solution that includes both viewpoints (win–win). The preferred approach on the exam when there's time. Read the chapter

Situational leadership

Adapting your leadership style to the team's maturity and the task: directing → coaching → supporting → delegating as competence and commitment grow (Hersey-Blanchard). Read the chapter

Directing vs. coaching

Directing gives clear instructions to a new or inexperienced team; coaching explains decisions and builds skills as the team develops. Match the style to the team, not to your preference. Read the chapter

Maslow

Maslow's hierarchy of needs: physiological, safety, belonging, esteem, self-actualisation. Higher needs motivate only once lower ones are met. Read the chapter

Herzberg

Two-factor theory: hygiene factors (pay, conditions) prevent dissatisfaction but don't motivate; motivators (achievement, recognition, growth) create satisfaction. Read the chapter

McGregor

Theory X assumes people dislike work and need control; Theory Y assumes people are self-motivated and want responsibility. Modern PM practice leans Theory Y. Read the chapter

McClelland

Acquired-needs theory: people are driven mainly by a need for achievement, affiliation or power. Assign work that fits each person's dominant need. Read the chapter

Power/interest grid

Classifies stakeholders by power and interest: manage closely (high/high), keep satisfied (high power, low interest), keep informed (low power, high interest), monitor (low/low). Read the chapter

Stakeholder register

The project document listing stakeholders with their role, interest, influence, expectations and classification. Check it first when a stakeholder question comes up. Read the chapter

Salience model

Classifies stakeholders by power, urgency and legitimacy. Those with all three are 'definitive' stakeholders who need the most attention. Read the chapter

Requirements elicitation

Drawing out what stakeholders actually need through interviews, workshops, observation, prototypes and similar techniques — not just recording what they first ask for. Read the chapter

Assumption log

Records assumptions and constraints made during the project, so they can be validated and their impact tracked if they turn out to be wrong. Read the chapter

RACI

A responsibility assignment matrix showing who is Responsible, Accountable, Consulted and Informed for each activity. Only one person is Accountable per task. Read the chapter

Expectation drift

Stakeholders' expectations gradually moving away from the agreed plan. Prevent it with regular, honest communication and early warning of changes. Read the chapter

Status reporting

Regular reports on where the project stands against the plan (scope, schedule, cost, risks). Bad news should be shared early, not hidden until it's certain. Read the chapter

Trust management

Deliberately building and keeping stakeholder trust through transparency, consistency and keeping commitments. Lost trust is far harder to rebuild than to keep. Read the chapter

Tacit vs. explicit knowledge

Explicit knowledge can be written down (documents, procedures); tacit knowledge lives in people's heads (judgment, experience) and transfers best through mentoring, pairing and shadowing. Read the chapter

Lessons learned register

A living record of what worked and what didn't, updated throughout the project — not just at the end — and fed into the organisation's knowledge base at closure. Read the chapter

Mentoring

An experienced person guiding a less experienced one over time. One of the best ways to transfer tacit knowledge. Read the chapter

Communication model

Sender encodes a message, sends it through a medium, the receiver decodes it and gives feedback; noise can distort it at any point. The sender is responsible for making it clear. Read the chapter

Push/pull/interactive communication

Push: sent to recipients (email, memos). Pull: recipients fetch it (intranet, repositories). Interactive: real-time two-way (meetings, calls) — best for urgent or complex issues. Read the chapter

Communications management plan

Defines who needs what information, when, in what format, by which method and from whom. The first place to look when someone isn't getting the right updates. Read the chapter

Process

Integrated PM plan

The project management plan combining all subsidiary plans and baselines (scope, schedule, cost). Changes to it go through integrated change control. Read the chapter

Development approach

How the product will be built: predictive (waterfall), adaptive (agile), incremental, iterative or hybrid. Choose it from the project's uncertainty, risk and constraints. Read the chapter

Tailoring

Adapting processes, tools and governance to the project's size, risk and context, rather than applying a methodology rigidly. PMI expects tailoring, not one-size-fits-all. Read the chapter

WBS

Work Breakdown Structure: a hierarchical decomposition of the total scope into deliverables and work packages. Together with the scope statement and WBS dictionary it forms the scope baseline. Read the chapter

Product backlog

The ordered list of everything that might be needed in the product, owned by the product owner and continuously re-prioritised by value. Read the chapter

Scope creep

Uncontrolled growth of scope without matching changes to time, cost or resources. Prevented by routing every change through change control. Read the chapter

Gold-plating

The team adding extra, unrequested features. It feels generous but adds risk and cost and bypasses the agreed scope — the PM should stop it. Read the chapter

MVP

Minimum Viable Product: the smallest version that delivers value and lets you learn from real users before investing more. Read the chapter

Value stream

The end-to-end sequence of activities that delivers value to the customer. Mapping it reveals waste and delays. Read the chapter

Benefits realization

Making sure the outcomes the business case promised are actually achieved after delivery — often measured after the project ends. Read the chapter

RAM/RACI

A Responsibility Assignment Matrix maps work to people or roles; RACI is the most common form (Responsible, Accountable, Consulted, Informed). Read the chapter

Resource leveling

Adjusting start and finish dates to resolve resource over-allocation. It can change the critical path and push out the end date. Read the chapter

Resource smoothing

Adjusting activities only within their float so resources are used evenly without changing the critical path or end date. Use it when the deadline can't move. Read the chapter

Fixed-price

Contract with a set price for defined scope. The seller carries most of the cost risk; best when scope is clear and stable (FFP, FPIF, FP-EPA). Read the chapter

Cost-reimbursable

Contract where the buyer pays the seller's actual costs plus a fee (CPFF, CPIF, CPAF). The buyer carries most of the cost risk; suits uncertain scope. Read the chapter

Time & materials

Hybrid contract paying an agreed rate for time and materials used. Good for small or quickly needed work with unclear scope; cap it with a not-to-exceed limit. Read the chapter

SOW

Statement of Work: a narrative description of the products, services or results to be supplied under a contract. Read the chapter

EV

Earned Value: the budgeted value of the work actually completed (% complete × BAC). Every EVM index puts EV first. Read the chapter

PV

Planned Value: the budgeted value of the work scheduled to be done by now. Read the chapter

AC

Actual Cost: what has really been spent on the work done so far. Read the chapter

CPI

Cost Performance Index = EV ÷ AC. Below 1.0 means over budget; 0.8 means you get 80 cents of work per dollar spent. Read the chapter

SPI

Schedule Performance Index = EV ÷ PV. Below 1.0 means behind schedule. Read the chapter

EAC

Estimate at Completion: the expected total cost. Most common form: BAC ÷ CPI (current cost performance continues). Read the chapter

ETC

Estimate to Complete = EAC − AC: how much more you expect to spend to finish. Read the chapter

Cost of quality

Cost of conformance (prevention + appraisal) versus cost of non-conformance (internal + external failures). Spending on prevention is cheapest overall. Read the chapter

Prevention vs. inspection

PMI's quality philosophy: build quality in by preventing defects, rather than relying on inspection to catch them afterwards. Read the chapter

Pareto/fishbone/control charts

Pareto: ranks causes by frequency (80/20). Fishbone (Ishikawa): finds root causes by category. Control chart: shows whether a process is stable within its control limits (watch the rule of seven). Read the chapter

Critical path

The longest path through the schedule network; it sets the shortest possible duration. Activities on it have zero total float. Read the chapter

Float/slack

How long an activity can be delayed. Total float: without delaying the project end (LS − ES). Free float: without delaying the next activity. Read the chapter

Crashing

Shortening the schedule by adding resources to critical-path activities. It increases cost. Read the chapter

Fast tracking

Shortening the schedule by doing activities in parallel that were planned in sequence. Adds risk and rework, but not direct cost. Read the chapter

Burndown/burnup charts

Burndown shows work remaining against time; burnup shows work completed and total scope. A burnup makes scope changes visible. Read the chapter

Status vs. progress reports

A status report says where the project is now; a progress report says what was accomplished during a period. Forecasts predict where it's heading. Read the chapter

Variance analysis

Comparing planned against actual results (scope, schedule, cost) to find the cause and size of a difference and decide on corrective action. Read the chapter

Acceptance criteria

The conditions a deliverable must meet before the customer accepts it. Agree them up front; formal acceptance comes before administrative closure. Read the chapter

Administrative closure

Closing the project or phase: getting formal acceptance, releasing resources, archiving records, completing final lessons learned and the final report. Read the chapter

Final lessons learned

The last update of the lessons learned register at closure, transferred to the organisation's process assets so future projects benefit. Read the chapter

Business Environment

Governance structure

The framework of roles, committees and processes that oversees the project and makes key decisions. Tailor it to the project's size and risk. Read the chapter

Decision rights

Who has the authority to make which decisions (budget, scope, priority). Clear decision rights stop delays and confusion. Read the chapter

Escalation path

The agreed route for raising issues the team can't resolve, and to whom. Use it after trying to resolve at the team level. Read the chapter

Regulatory compliance

Meeting the laws, regulations and standards that apply to the project or product. Non-negotiable — compliance gaps must be reported and fixed. Read the chapter

Audit

An independent, structured review that checks whether project activities follow organisational and regulatory policies, processes and procedures. Read the chapter

Compliance categories

Grouping requirements by type (legal, safety, data privacy, financial, industry standards) so each can be tracked, tested and owned. Read the chapter

Change control board (CCB)

The group that reviews and approves or rejects change requests. Even a senior stakeholder's change goes through it. Read the chapter

Change request

A formal proposal to change scope, schedule, cost, a baseline or a document. Assess its impact first, then submit it for approval. Read the chapter

Integrated change control

The process of reviewing all change requests and assessing their impact across scope, schedule, cost, quality and risk before approving or rejecting them. Read the chapter

Impediment

Anything slowing the team down. Removing impediments is a core part of servant leadership. Read the chapter

Blocker

An impediment that stops work completely until it's resolved. Try to resolve it within the team first, then use authority or escalate. Read the chapter

Escalation threshold

The pre-agreed point (time, cost, impact) at which an issue must be escalated to a higher level. Read the chapter

Risk register

The document listing identified risks with their probability, impact, owner, triggers and planned responses. Update it throughout the project. Read the chapter

Probability/impact matrix

A grid that rates each risk by its likelihood and impact, so you can prioritise which risks to respond to first. Read the chapter

Risk response strategies

Threats: escalate, avoid, transfer, mitigate, accept. Opportunities: escalate, exploit, share, enhance, accept. Read the chapter

Retrospective

A regular team meeting to inspect how the team works and agree concrete improvements. Without an assigned action item, it's just complaining. Read the chapter

Kaizen

Japanese for 'change for the better': continuous, small, incremental improvements made by everyone, all the time. Read the chapter

Process improvement plan

Describes how project processes will be analysed to find and implement improvements that add value. Read the chapter

Change management (organizational)

Helping people adopt a change through communication, training, support and reinforcement. Without it, a technically successful project can still fail on adoption. Read the chapter

ADKAR

Prosci's change model: Awareness, Desire, Knowledge, Ability, Reinforcement — the stages a person moves through to accept a change. Read the chapter

Resistance to change

People's natural reluctance to change. Address it by listening, involving them early, explaining the 'why' and supporting them through the transition. Read the chapter

PESTLE

Analysis of the external environment: Political, Economic, Social, Technological, Legal and Environmental factors that could affect the project. Read the chapter

Business case revalidation

Re-checking that the project is still worth doing when the environment changes. If a regulation or market shift undermines it, raise it with the sponsor. Read the chapter

Environmental scanning

Continuously watching the external environment (market, regulations, technology, competitors) for changes that could affect the project's value. Read the chapter

PMI-ACP key terms

Mindset

Osmotic communication

Alistair Cockburn's term for information team members absorb just by overhearing nearby conversations. A key benefit of co-location. Read the chapter

Caves and commons

A co-located layout: an open 'commons' for collaboration and spontaneous conversation, plus quiet 'caves' for focused, heads-down work. Read the chapter

Information radiator

A highly visible display of project information (task board, burndown chart, build status) that anyone passing by can read at a glance. Read the chapter

Pair programming

Two developers at one workstation: one writes code (the driver) while the other reviews in real time (the navigator), swapping often. Improves quality and spreads knowledge. Read the chapter

Distributed team tooling

Tools that recreate co-location for remote teams: always-on video links, shared digital boards, chat and virtual whiteboards. Read the chapter

Active listening

Listening to fully understand the speaker, at three levels: internal, focused and global. Read the chapter

Internal listening

Level 1: listening through your own thoughts and reactions — useful for self-awareness, but you miss what the speaker means. Read the chapter

Focused listening

Level 2: full attention on the speaker's words, meaning and emotion. Read the chapter

Global listening

Level 3: taking in everything — words, tone, body language and the room's dynamics. What skilled facilitators use. Read the chapter

Nominal group technique

Each person writes ideas silently first, then the group shares, discusses and ranks them. Stops louder voices drowning out quieter ones. Read the chapter

Group passing technique

An idea sheet is passed round the group; each person adds to what the last person wrote. Read the chapter

Directed brainstorming

Brainstorming restricted to a specific, pre-chosen topic or root cause. Read the chapter

Guided brainstorming

A facilitator steers the group toward an objective, without narrowing the topic as tightly as directed brainstorming. Read the chapter

Two-way communication

Communication that flows both ways in real time (conversations, team chat), so understanding can be checked and corrected straight away. Read the chapter

Tuckman's model

Team development stages: forming, storming, norming, performing, adjourning. Each stage calls for a different leadership style. Read the chapter

Forming

The team has just come together: polite, roles unclear, little visible conflict. Leader style: directing. Read the chapter

Storming

Real conflict surfaces as roles and ways of working are contested. Leader style: coaching. Read the chapter

Norming

Roles settle, trust builds and the team agrees how to work. Leader style: supporting. Read the chapter

Performing

A mature, self-organising team that resolves its own issues and delivers. Leader style: delegating. Read the chapter

Adjourning

The work ends and the team disbands. Recognise contributions and capture lessons learned. Read the chapter

Shu-Ha-Ri

Stages of mastering a practice, from martial arts. Shu: follow the rules exactly. Ha: start adapting them. Ri: transcend them — you embody the principle. Read the chapter

Dreyfus model

Five stages of skill acquisition: novice, advanced beginner, competent, proficient, expert. Read the chapter

Novice

Dreyfus stage 1: needs explicit, step-by-step rules; no situational judgment yet. Read the chapter

Advanced beginner

Dreyfus stage 2: starts to recognise recurring patterns but is still rule-bound. Read the chapter

Competent

Dreyfus stage 3: can plan and prioritise, and takes responsibility for outcomes. Read the chapter

Proficient

Dreyfus stage 4: sees the whole situation and knows what matters, guided by experience. Read the chapter

Expert

Dreyfus stage 5: acts intuitively from deep experience, without needing rules. Read the chapter

Sprint retrospective

The event at the end of each sprint where the team reflects on how it worked and agrees improvements for the next sprint. Read the chapter

Set the Stage

Retrospective step 1 (Derby & Larsen): create safety and frame the session. Read the chapter

Gather the Data

Retrospective step 2: build a shared, factual picture of what actually happened. Read the chapter

Generate Insights

Retrospective step 3: ask why things happened and look for patterns and root causes. Read the chapter

Decide What to Do

Retrospective step 4: agree a few specific, owned improvement actions. Read the chapter

Close the Retrospective

Retrospective step 5: summarise, thank people and reflect on how the retrospective itself could improve. Read the chapter

Intraspective

An ad-hoc retrospective called mid-sprint when something goes wrong, instead of waiting for the scheduled one. Read the chapter

Lessons learned

Knowledge gained during the work. Retrospectives capture lessons every iteration so the very next iteration improves. Read the chapter

Process tailoring

Adapting the team's process to the project's real needs instead of following a fixed process regardless of fit. Read the chapter

Blended Agile

Combining practices from two or more agile methods (e.g. ScrumBan) so the project uses exactly what it needs. Read the chapter

ScrumBan

Scrum's sprint structure with Kanban's board and WIP limits. Read the chapter

Disciplined Agile Delivery (DAD)

A toolkit that draws practices from Scrum, Lean, agile modelling and others, letting teams choose their way of working. Read the chapter

Hybrid model

Blending agile with traditional (waterfall) practices, e.g. predictive planning with agile delivery. Read the chapter

AgileFall

A hybrid where agile and waterfall practices are combined, often waterfall planning and governance around agile development. Read the chapter

WaterSprint

A hybrid that runs waterfall-style phases inside short sprints — often a sign of only partial agile adoption. Read the chapter

Project pre-mortem

The team imagines the project has already failed and works backwards to identify what caused it, then plans to prevent those causes. Read the chapter

Extreme Programming (XP)

An agile method focused on engineering practices: TDD, pair programming, continuous integration, refactoring and small releases. Read the chapter

Kent Beck

The creator of Extreme Programming (XP) and author of 'Test-Driven Development by Example'. Read the chapter

C3 Payroll project

Chrysler's Comprehensive Compensation payroll project, where Kent Beck developed and first applied XP in the late 1990s. Read the chapter

Engineering best practices

Technical practices that keep code quality high — XP's focus: TDD, refactoring, pair programming, continuous integration, coding standards. Read the chapter

Whole Team

XP practice: the team works as one unit and whoever is best suited picks up each task — no fixed, prescribed roles. Read the chapter

XP Values

Communication, simplicity, feedback, courage and respect. Read the chapter

XP Roles

Programmer, tester, coach, customer and an optional tracker. Read the chapter

XP Activities

Four core activities: listening, designing, coding and testing. Read the chapter

Collective code ownership

Anyone on the team can change any part of the code, so knowledge spreads and nobody becomes a bottleneck. Read the chapter

Crystal methods

Alistair Cockburn's family of agile methods, tuned to team size and project criticality — more people and higher stakes mean more process. Read the chapter

Alistair Cockburn

Agile Manifesto signatory who created the Crystal methods and coined 'osmotic communication' and 'caves and commons'. Read the chapter

Criticality

In Crystal, what's at stake if the system fails: comfort, discretionary money, essential money, or life. Higher criticality needs more rigour. Read the chapter

Crystal Clear

The lightest Crystal method, for small co-located teams (up to about 6–8 people) on low-criticality projects. Read the chapter

Crystal Yellow/Orange/Red/Maroon

Heavier Crystal methods for progressively larger teams and higher criticality: more documentation, verification and coordination. Read the chapter

Agile suitability tools

Assessments (e.g. of culture, team and project factors) that help decide whether an agile, predictive or hybrid approach fits a project. Read the chapter

Leadership

Voice of Customer (VOC)

The end user's or customer's perspective: what they need, what 'done' means to them, what they'd pay for. Read the chapter

Voice of Business (VOB)

The sponsor's or business's perspective: return on investment, budget, strategic fit and market timing. Read the chapter

Reciprocal commitment

Both sides make offsetting promises — e.g. the team commits to delivering, the business commits to not changing the sprint — rather than one side just demanding. Read the chapter

Pigs and Chickens

A fable about commitment: 'pigs' (the delivery team) are committed and speak at the daily stand-up; 'chickens' (stakeholders) are involved but don't drive it. Read the chapter

Emotional intelligence

The ability to recognise and manage your own emotions and to understand and influence others'. Goleman's five components: self-awareness, self-regulation, motivation, empathy and social skill. Read the chapter

Self-awareness

Recognising your own emotions, strengths and triggers as they happen. Read the chapter

Self-regulation

Managing your reactions and impulses instead of being driven by them. Read the chapter

Empathy

Understanding other people's feelings and viewpoints. On the exam: check in privately with a struggling team member before treating it as a performance issue. Read the chapter

Social skill

Managing relationships, building networks and influencing others — the outward-facing part of emotional intelligence. Read the chapter

Collaboration

Working together continuously throughout the work, rather than handing finished pieces between specialists in sequence. Read the chapter

Agile Manifesto

Four values: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. Plus 12 principles. Read the chapter

Adaptive leadership

Leading through uncertainty by helping the team learn, experiment and adapt, rather than handing down fixed answers. Read the chapter

Situational leadership

Adapting your leadership style to the team's maturity and the task: directing → coaching → supporting → delegating as competence and commitment grow (Hersey-Blanchard). Read the chapter

Hersey-Blanchard

The authors of situational leadership: four styles — directing, coaching, supporting, delegating — matched to the team's competence and commitment. Read the chapter

Servant leadership

A leadership style that puts the team first: removing obstacles, shielding the team, coaching and supporting rather than commanding. The default leadership style on the exam for agile and high-trust teams. Read the chapter

Directing

Situational leadership style for a new team: clear, specific instructions and close supervision (Tuckman: forming). Read the chapter

Coaching

Situational leadership style for a team gaining skills: explain decisions, ask for input, still give direction (Tuckman: storming). Read the chapter

Supporting

Situational leadership style for a capable team: share decisions and encourage; less direction (Tuckman: norming). Read the chapter

Delegating

Situational leadership style for a mature, self-managing team: hand over decisions and step back (Tuckman: performing). Read the chapter

Negotiation

Reaching agreement between parties with different interests. In agile, aim for win–win outcomes that keep the relationship intact. Read the chapter

Contest

A bounded disagreement over a specific issue, where both sides still want to win fairly and can accept the result. Usually just needs facilitation. Read the chapter

Crusade

A conflict escalated into attacks on people's character or motives. Needs active de-escalation before any resolution technique will work. Read the chapter

Force/Direct

Imposing one view through authority (win–lose). Reserve it for emergencies, safety or truly non-negotiable issues — it damages trust. Read the chapter

Smooth/Accommodate

Emphasising agreement and conceding on minor points to keep harmony. Protects the relationship but leaves the real issue unresolved. Read the chapter

Compromise/Reconcile

Both sides give something up. Fast, but often leaves nobody fully satisfied. Read the chapter

Withdraw/Avoid

Retreating from or postponing a conflict. Only appropriate when emotions need to cool or the issue is trivial — it doesn't resolve anything. Read the chapter

Collaborate/Problem-solve

Working through the disagreement openly to reach a solution that includes both viewpoints (win–win). The preferred approach on the exam when there's time. Read the chapter

Kaizen

Japanese for 'change for the better': small, continuous improvements, made through repeated Plan-Do-Check-Act cycles. Read the chapter

Plan-Do-Check-Act (PDCA)

Deming's improvement cycle. Plan a change, do it on a small scale, check the results against the plan, act on what you learned. Read the chapter

Deming cycle

Another name for Plan-Do-Check-Act (PDCA), the cycle through which Kaizen improvements are made. Read the chapter

Fishbone (Ishikawa) diagram

A cause-and-effect diagram whose 'bones' group possible causes by category, leading to the problem at the 'head'. Used for root cause analysis. Read the chapter

5-Why analysis

Ask 'why?' repeatedly (about five times) until you reach the underlying cause instead of stopping at a symptom. Read the chapter

Root cause analysis

Finding the underlying cause of a problem so it can be fixed for good, rather than treating symptoms. Tools: fishbone, 5 Whys. Read the chapter

Build Integrity In

Lean principle: build quality in from the start, both perceived integrity (customer experience) and conceptual integrity (sound architecture). Read the chapter

Perceived Integrity

How the customer experiences the system. They judge quality entirely by what they see and use. Read the chapter

Conceptual Integrity

The system's internal coherence: its components work well together as a whole. Read the chapter

Last Responsible Moment

Lean principle (decide as late as possible): make a decision when you have the most information, but before delaying it causes harm. Read the chapter

Empower the Team

Lean principle: trust the people doing the work to make decisions and improve their own process. Read the chapter

Optimize the Whole

Lean principle: improve the entire value stream, not just one part of it, and avoid local optimisation. Read the chapter

Peter Senge

Author of 'The Fifth Discipline' on systems thinking — the idea behind Lean's 'optimise the whole'. Read the chapter

The Fifth Discipline

Peter Senge's book on systems thinking: seeing whole systems and their interrelationships rather than isolated parts. Read the chapter

Product

Value stream mapping (VSM)

A visual map of a process from request to delivery, showing value-added time against waiting (waste) time. Read the chapter

Cumulative flow diagram (CFD)

A chart of work items in each state over time. Widening bands show bottlenecks; the horizontal gap between bands shows cycle or lead time. Read the chapter

Work in progress (WIP)

Work that has started but isn't finished. Too much WIP slows everything down — Little's Law: cycle time = WIP ÷ throughput. Read the chapter

Cycle time

The time an item takes from when work starts on it to when it's delivered, including both work and waiting time. Read the chapter

Lead time

The time from when a request is made (enters the backlog) to when it's delivered. Lead time includes cycle time. Read the chapter

Throughput

How much work is completed per period (e.g. stories per week). In value stream mapping, process efficiency = work time ÷ total time. Read the chapter

Quality

How well the product meets customer needs: both intrinsic (how well it's built) and extrinsic (how much value it delivers). Read the chapter

Conformance to requirements

A definition of quality: the product meets its stated, documented requirements. Read the chapter

Fitness for use

A definition of quality: the product actually works for its intended purpose in real use. Read the chapter

Performance

Quality attribute: does the product do what it's supposed to do, and how well? Read the chapter

Reliability

Quality attribute: does the product keep working consistently over time? Read the chapter

Serviceability

Quality attribute: how quickly and easily the product can be repaired or supported. Read the chapter

Perceived quality

Quality attribute: the customer's impression of quality, shaped by brand, reputation and experience. Read the chapter

Iron triangle

The traditional triple constraint: scope fixed at the top, with cost and schedule estimated from it. A change to one forces a change in the others. Read the chapter

Inverted triangle

Agile flips the iron triangle: cost (team) and time (iterations) are fixed, and scope is the variable. Read the chapter

Agile Triangle of Constraints

Jim Highsmith's model: value (extrinsic quality) at the top as the goal, with quality (intrinsic) and constraints (scope, cost, schedule) at the base. Read the chapter

Intrinsic quality

How well the product is built internally: architecture, code quality, low technical debt. Read the chapter

Extrinsic quality

The value the product delivers to the customer: features that solve real problems. Read the chapter

Organic quality

Quality that comes naturally from following agile practices: iterations, reviews, pair programming, continuous integration. Read the chapter

Overt quality

Quality from deliberate, explicit measures: verification, validation, unit, integration and regression tests. Read the chapter

Today vs. tomorrow quality

Today's quality: correct functionality delivering value now. Tomorrow's quality: the product's ability to keep delivering value and adapt to change, by keeping technical debt low. Read the chapter

Product Backlog

The ordered list of everything needed in the product, owned by the product owner. Its commitment is the Product Goal. Read the chapter

Sprint Backlog

The sprint goal, the backlog items selected for the sprint and the plan to deliver them, owned by the developers. Its commitment is the Sprint Goal. Read the chapter

Product Increment

The sum of all completed work that meets the Definition of Done — a usable step toward the Product Goal. Read the chapter

Product Goal

The long-term objective for the product; the commitment for the Product Backlog. Read the chapter

Sprint Goal

The single objective for the sprint; the commitment for the Sprint Backlog. Read the chapter

Definition of Done

The shared checklist a work item must meet to count as complete. In Scrum, the Product Increment's commitment. Read the chapter

Backlog refinement

Ongoing work to break down, clarify, estimate and order Product Backlog items so they're ready for upcoming sprints. Read the chapter

Scrum of Scrums

A meeting of representatives from several Scrum teams working on the same product, to coordinate dependencies and cross-team impediments. Read the chapter

Delivery

Incremental development and delivery

Building and delivering the product in small, working pieces, with short iterations, frequent verification and validation, and continuous integration. Read the chapter

Frequent verification

Regularly checking the product is built right — meets its specifications (e.g. tests, reviews). Read the chapter

Frequent validation

Regularly checking the right product is being built — it meets the customer's real needs (e.g. demos, reviews). Read the chapter

Hardening iteration

A final iteration before release focused on verification, validation and stabilisation. A safety net, not a substitute for testing throughout. Read the chapter

Continuous integration (CI)

Developers merge small changes into a shared repository frequently, each verified by an automatic build and tests, so conflicts and defects surface early. Read the chapter

Definition of Done

The shared checklist a work item must meet to count as complete. In Scrum, the Product Increment's commitment. Read the chapter

Technical debt

The future cost of shortcuts and poor design in the code. Left unpaid, it slows the team down and can lead to 'design death'. Read the chapter

Design death

The point where technical debt has grown so large that the code can no longer be changed safely or economically. Read the chapter

Refactoring

Improving the internal structure of code without changing its behaviour, to keep it clean and reduce technical debt. Read the chapter

Pair programming

Two developers at one workstation: one writes code (the driver) while the other reviews in real time (the navigator), swapping often. Improves quality and spreads knowledge. Read the chapter

Test-Driven Development (TDD)

Write a failing test first, write just enough code to pass it, then refactor (red–green–refactor). Also called test-first development. Read the chapter

Acceptance Test-Driven Development (ATDD)

The whole team agrees acceptance tests for a story before building it — 'begin with the end in mind'. Read the chapter

Exploratory testing

Unscripted testing where the tester learns the system and designs tests on the fly to find unexpected defects. Read the chapter

Usability testing

Watching real users perform real tasks to find where the product is hard or confusing to use. Read the chapter

Scope creep

Uncontrolled expansion of scope without adjusting time, cost or resources. Read the chapter

Gold plating

Delivering extra, unrequested functionality. It adds untested scope and cost the customer never asked for — a form of waste. Read the chapter

Planning Game

XP's planning meeting each iteration, covering release and iteration planning, in three phases: exploration, commitment and steering. Read the chapter

Small Releases

XP practice: frequent, small, valuable releases instead of one big release, giving early feedback and catching defects while they're cheap. Read the chapter

Customer Tests

XP practice: the customer defines and runs acceptance tests to confirm the system does what they expect. Read the chapter

Simple Design

XP practice: build the simplest design that works for today's needs — no speculative features (YAGNI). Read the chapter

Collective Code Ownership

XP practice: the whole team owns all the code, and anyone may improve any part of it. Read the chapter

Sustainable Pace

XP practice (originally the 40-hour week): work at a pace the team can keep up indefinitely, avoiding burnout. Read the chapter

Metaphor

XP practice: a shared story or analogy describing how the system works, giving everyone a common vocabulary. Read the chapter

Slack

XP practice: deliberately include a few small, low-priority items in each iteration that can be dropped if the team falls behind. Read the chapter

Lean Software Development

Lean manufacturing principles applied to software (Mary and Tom Poppendieck): eliminate waste, build quality in, deliver fast, defer decisions, empower the team, optimise the whole. Read the chapter

Just In Time (JIT)

Toyota's concept of producing only what is needed, when it's needed — the root of Lean. Read the chapter

Mary and Tom Poppendieck

Authors of 'Lean Software Development: An Agile Toolkit', who adapted Lean's principles and seven wastes to software. Read the chapter

Muda

Japanese for waste: anything that adds no value for the customer. Read the chapter

Muri

Japanese for overburden: pushing people or systems beyond their capacity. (Mura, its partner, means unevenness.) Read the chapter

Partially Done Work

Lean waste: work started but not finished (unmerged code, untested features). Also called work in progress. Read the chapter

Task Switching

Lean waste: juggling several items or teams at once instead of finishing one before starting the next. Read the chapter

Set-Based Development

Keep several design options open as long as possible and eliminate weaker ones over time, rather than choosing one up front. Read the chapter

Options Thinking

Paying a small cost to keep a choice open without fully committing, so you can decide later with better information. Read the chapter

Pull Systems

Work is pulled forward when there is capacity for it, rather than pushed onto the team regardless. Read the chapter

Queuing Theory

The mathematics of waiting lines. Too much work in the queue increases waiting time and cycle time — limit WIP. Read the chapter

Cycle Time

The time from starting work on an item (or selecting a story) to delivering it, including wait and work time. Read the chapter

Throughput

How much work is completed per period (e.g. stories per week). In value stream mapping, process efficiency = work time ÷ total time. Read the chapter

Cost of Delay

The value lost by not delivering a feature when the customer or market needed it. Used to prioritise work. Read the chapter

Last Responsible Moment

Lean principle (decide as late as possible): make a decision when you have the most information, but before delaying it causes harm. Read the chapter

Kanban

A visual workflow management method: visualise the work, limit WIP, manage flow, and pull work as capacity allows. Read the chapter

Visual workflow management

Making every work item and its status visible (e.g. on a board) so bottlenecks and blockers stand out. Read the chapter

Work In Progress (WIP) limit

A cap on how many items can be in a workflow state at once. When a column is full, the team helps clear it before starting new work. Read the chapter

Management by Sight

Kanban goal: anyone can see the state of the work and where problems are just by looking at the board. Read the chapter

Bottleneck

A step in the workflow where work piles up because capacity is lower than demand. It limits the whole system's throughput. Read the chapter

Value Chain

The full sequence of steps that delivers value to the customer. Kanban aims to control the whole chain, not one stage. Read the chapter

PMI-RMP key terms

Risk Strategy and Planning

Preliminary document analysis

Reviewing existing documents — historical data, lessons learned, industry benchmarks — before formal risk identification begins. Domain I, Task 1. Read the chapter

Industry benchmarks

Published data on how similar projects or organizations in the same industry typically perform, used to sanity-check assumptions during preliminary analysis. Read the chapter

Historical information

Records from past, similar projects (schedules, costs, risks that occurred) used to inform current risk planning and avoid repeating known mistakes. Read the chapter

Lessons learned register

A document capturing what worked and what didn't on past projects — a key preliminary-analysis input, and something every closed risk should feed back into. Read the chapter

OPA

Organizational Process Assets — templates, historical data, and processes an organization already has, which shape which risk methodology fits a given project. Read the chapter

EEF

Enterprise Environmental Factors — conditions outside the project's control (culture, market, regulations) that shape which development approach and risk process fit. Read the chapter

PESTLE

Political, Economic, Social, Technological, Legal, Environmental — a framework for scanning the external environment for threats and opportunities. Read the chapter

SWOT analysis

Strengths, Weaknesses, Opportunities, Threats — used alongside PESTLE to assess a project's environment during risk strategy and planning. Read the chapter

Risk appetite

An organization's general attitude toward accepting uncertainty — how much risk it's willing to take on, in principle, to pursue its objectives. Read the chapter

Risk culture maturity

An assessment of how an organization's actual, lived risk behavior compares to its stated risk appetite — stated and lived appetite can genuinely differ. Read the chapter

Risk threshold

The specific, calculated boundary a risk appetite translates into for a given project — the line past which exposure becomes unacceptable. Read the chapter

Risk tolerance

The degree of variation from a target that a stakeholder is willing to accept on a specific objective — a more granular cousin of risk threshold. Read the chapter

Risk capacity

The objective maximum amount of risk an organization could absorb, as distinct from risk appetite (how much it chooses to take on, often less than its full capacity). Read the chapter

Risk management strategy

The high-level approach — processes, tools, metrics, and risk categories — an organization or project will use to manage risk, set early in Domain I. Read the chapter

Risk categories

Groupings risks fall into (e.g. technical, external, organizational, project management), established in the risk management strategy to enable meaningful analysis. Read the chapter

Risk metrics

Measures used to track risk exposure and response effectiveness over time, defined as part of establishing the risk management strategy. Read the chapter

Servant leadership

A leadership style — coaching and enabling the team's own risk competence rather than mandating a rigid process top-down. Named explicitly in Domain I. Read the chapter

Risk management plan

The documented plan covering roles, the RBS, communication cadence, and prioritization criteria for how risk will be managed across the project. Read the chapter

Risk Breakdown Structure (RBS)

A hierarchical decomposition of risk categories, similar to how a WBS decomposes scope — distinct from the risk register, which logs specific risk instances. Read the chapter

RACI

A Responsibility Assignment Matrix (Responsible, Accountable, Consulted, Informed) used to align risk roles so register updates don't fall through the cracks. Read the chapter

Risk communication plan

Part of the risk management plan defining how risk information will be shared with stakeholders — tailored per audience, not one generic update. Read the chapter

Risk prioritization criteria

The agreed rules for ranking competing risks against each other, documented in the risk management plan ahead of actual analysis. Read the chapter

Stakeholder risk attitude

A stakeholder's individual disposition toward risk — their personal comfort with uncertainty, which can differ from the organization's overall appetite. Read the chapter

Rules of engagement

Clear expectations set with stakeholders about how their input will actually be used in the risk process, so engagement is genuine rather than symbolic. Read the chapter

Risk prioritization

The act of ranking identified risks against each other using agreed criteria, so the team knows where to focus limited response effort. Read the chapter

Stakeholder empowerment

Actively enabling stakeholders to challenge existing risk thresholds and assumptions, rather than treating early decisions as fixed and final. Read the chapter

Risk Identification

Risk identification exercises

Structured activities — meetings, interviews, focus groups, SME support — used to surface candidate risks before they're screened into the register. Read the chapter

SME interviews

Structured conversations with subject matter experts used during risk identification exercises to surface risks the team itself might miss. Read the chapter

Threats vs. opportunities

The two-sided nature of risk in PMI-RMP: every identified risk is indicated as either a threat (negative) or an opportunity (positive) from the start. Read the chapter

Assumption log

A record of things taken as true without proof; each entry is a candidate source of risk, since an assumption can turn out to be wrong or shift unexpectedly. Read the chapter

Constraint analysis

Examining fixed limits the project must operate within, since constraints — like assumptions — can shift or prove inaccurate and introduce risk. Read the chapter

Cascade effect

How a small, easy-to-overlook assumption can ripple into a larger impact on project objectives (like schedule) once the chain is traced far enough. Read the chapter

Risk trigger

The event or condition that signals a risk is about to happen or has just started happening — distinct from its cause and its consequence. Read the chapter

Risk cause

The underlying reason a risk could occur in the first place — distinct from its trigger (the signal) and its consequence (the resulting impact). Read the chapter

Risk consequence

What happens to the project if a risk actually occurs — the resulting impact, distinct from the risk's cause and its trigger. Read the chapter

Risk threshold (contextual)

A threshold reassessed and confirmed against updated risk data as a project's actual context evolves — thresholds aren't fixed forever once documented. Read the chapter

Risk register

The central artifact logging every validated risk and its attributes (probability, impact, urgency, origin) — built only from risks that passed a validity screen. Read the chapter

Risk attributes

The core fields scored for each risk in the register: probability (likelihood), impact (severity), and urgency (how soon the window for action closes). Read the chapter

Risk ownership

The named person accountable for monitoring and executing the response to a specific risk — without an owner, a response plan risks never being activated. Read the chapter

Internal vs. external risk

A risk's classified origin: internal (within the project team's control) or external (outside it, such as a regulatory or market shift). Read the chapter

Risk Analysis

Qualitative risk analysis

Prioritizing risks using a consistent probability-and-impact assessment against agreed definitions — produces a relative, ordinal ranking, not a dollar figure. Read the chapter

Risk matrix

The standard tool for qualitative analysis: an agreed assessment approach, historical information, probability/impact definitions, categories, and pre-set criteria. Read the chapter

Nominal vs. ordinal classification

Two scoring approaches in qualitative analysis: nominal groups risks into categories (e.g. high/medium/low); ordinal ranks them relative to one another. Read the chapter

Probability and impact

The two core dimensions scored in qualitative analysis — likelihood of occurrence, and severity of consequence if it occurs. Read the chapter

Quantitative risk analysis

Numerically modeling risk — EMV, simulations, sensitivity analysis — typically reserved for the highest-priority risks a qualitative pass already surfaced. Read the chapter

Monte Carlo simulation

A quantitative technique that runs many randomized scenarios to produce a probability distribution of possible project outcomes (cost, schedule, etc.). Read the chapter

Decision tree

A quantitative tool that maps out sequential decisions and their probability-weighted outcomes, helping compare competing response options. Read the chapter

Expected Monetary Value (EMV)

Probability × impact, summed across all possible outcomes — gives one comparable numeric figure per risk or response option. Read the chapter

Sensitivity analysis

A quantitative technique (e.g. Monte Carlo, decision trees) that shows how sensitive a project's outcome is to changes in a given risk variable. Read the chapter

SWOT analysis

Strengths, Weaknesses, Opportunities, Threats — used alongside PESTLE to assess a project's environment during risk strategy and planning. Read the chapter

Ishikawa (fishbone) diagram

A root-cause tool that traces a risk back to its underlying causes across categories — people, process, environment, and more. Read the chapter

Tree diagram

A branching diagram used to assess risk complexity by visually tracing how root causes lead to specific risk outcomes. Read the chapter

Impact analysis

Evaluating a risk's effect across every relevant project objective — cost, schedule, quality, AND compliance/governance — not just the obvious one or two. Read the chapter

Risk Response

Avoid

A threat-response strategy: eliminating the risk entirely by removing its source, such as cutting the feature or activity that created it. Read the chapter

Mitigate

A threat-response strategy: reducing a negative risk's probability or impact without necessarily eliminating it — the most common threat response. Read the chapter

Transfer

A threat-response strategy: shifting the financial or operational consequence of a risk to a third party, such as through insurance or a contract clause. Read the chapter

Accept

A response strategy (threat or opportunity) acknowledging the risk with no further proactive action — can be passive (monitor only) or active (set aside a contingency reserve). Read the chapter

Exploit

An opportunity-response strategy: taking deliberate action to ensure a positive risk definitely occurs, rather than leaving it to chance. Read the chapter

Enhance

An opportunity-response strategy: actively increasing the probability or impact of a positive risk being realized — the mirror of mitigate. Read the chapter

Share

An opportunity-response strategy: partnering with a third party who is better positioned to capture an opportunity, splitting the resulting gain. Read the chapter

Risk burndown chart

A tool (alongside dot plots) that illustrates and communicates how risk exposure decreases over time as responses are implemented. Read the chapter

Workaround

An unplanned response to a risk that wasn't identified in advance — reactive, as opposed to a pre-planned response strategy. Read the chapter

Secondary risk

A new risk introduced BY implementing a response to a different, original risk — logged as its own register entry with its own response plan. Read the chapter

Residual risk

The risk that remains after a response has been implemented — most responses (especially mitigate) reduce exposure without eliminating it completely. Read the chapter

Contingency plan execution

Carrying out a pre-planned response — drawing on a contingency reserve of time or budget — once a risk's defined trigger condition is met. Read the chapter

Monitor and Close Risks

Variance analysis

Comparing actual risk-relevant performance data against the baseline to see whether real exposure is tracking as expected during monitoring. Read the chapter

Risk exposure

The overall level of risk a project currently carries, often tracked in aggregate and reported to stakeholders on a regular cadence. Read the chapter

Work package reconciliation

Reconciling performance data and reports specifically from risk-relevant work packages, comparing actual status against the baseline. Read the chapter

Residual risk monitoring

Checking back on a risk's remaining exposure after a response was implemented — treating implementation as a checkpoint, not a permanent finish line. Read the chapter

Secondary risk monitoring

Actively watching for new risks introduced by implemented responses, so they get logged and managed rather than missed entirely. Read the chapter

Risk register updates

Keeping the register current as risk status changes — including documented closure of expired risks rather than letting them accumulate unreviewed. Read the chapter

Expired risk

A risk tied to a project phase or condition that no longer applies — should be closed with documented rationale, not silently deleted or left active. Read the chapter

Change log

A project document updated with aggregated risk data as part of Domain V's responsibility to keep related documents current, not just the register itself. Read the chapter

Overall project risk level

The aggregate, whole-project risk exposure — distinct from any single risk's status — often the subject of recurring steering-committee reporting. Read the chapter

Risk reporting

Communicating risk information on a regular, planned cadence (set in Domain I) so stakeholders can track a consistent trend, not just hear about problems. Read the chapter

Stakeholder-tailored reporting

Preparing different levels of risk detail for different audiences — a summarized view for executives, a more granular one for the delivery team. Read the chapter

Scrum Master key terms

Scrum Theory and Values

Empiricism

Knowledge comes from experience, and decisions are made on what is actually observed. Scrum is founded on empiricism and lean thinking. Read the chapter

Transparency

The process and the work are visible to those doing it and those receiving it, so decisions are based on the real state of the artifacts. Read the chapter

Inspection

Frequently and diligently checking the artifacts and progress toward agreed goals to spot problems early. Every Scrum event is an inspection opportunity. Read the chapter

Adaptation

Adjusting the process or product as soon as possible when something drifts outside acceptable limits. Harder when people aren't empowered or self-managing. Read the chapter

Lean thinking

Reducing waste and focusing on the essentials. With empiricism, one of Scrum's two foundations. Read the chapter

Iterative delivery

Revisiting and improving the product and the way of working cycle after cycle (Sprint after Sprint). Read the chapter

Incremental delivery

Delivering value in usable pieces, each Increment adding to the previous ones, to optimize predictability and control risk. Read the chapter

Scrum framework

A lightweight framework for complex problems. It defines only accountabilities, events, artifacts and rules, and is intentionally incomplete. Read the chapter

Commitment

A Scrum value: the team commits to achieving its goals and to supporting each other — not to delivering every forecast item no matter what. Read the chapter

Focus

A Scrum value: the primary attention is on the work of the Sprint, to make the best possible progress toward the goals. Read the chapter

Openness

A Scrum value: the team and stakeholders are open about the work and the challenges. It makes transparency possible. Read the chapter

Respect

A Scrum value: team members respect each other as capable, independent people, and are respected as such. Read the chapter

Courage

A Scrum value: having the courage to do the right thing and to work on tough problems — including raising bad news. Read the chapter

The Scrum Team

Scrum Team

One Scrum Master, one Product Owner and Developers. No sub-teams or hierarchies; focused on one objective at a time, the Product Goal. Typically 10 or fewer people. Read the chapter

Cross-functional

The team members together have all the skills needed to create value each Sprint. Read the chapter

Self-managing

The team decides internally who does what, when and how. Replaced 'self-organizing' in the 2020 Scrum Guide. Read the chapter

Accountability

Scrum defines three accountabilities — Developers, Product Owner and Scrum Master — rather than job titles. Read the chapter

Developers

Everyone committed to creating any aspect of a usable Increment each Sprint. They create the Sprint Backlog, adhere to the Definition of Done, adapt the plan daily and hold each other accountable. Read the chapter

Sprint Backlog

The Sprint Goal (why), the selected Product Backlog items (what) and the plan for delivering the Increment (how). A plan by and for the Developers, updated throughout the Sprint. Read the chapter

Definition of Done

The formal description of the state of the Increment when it meets the required quality measures. The commitment for the Increment; undone work can't be released or presented. Read the chapter

Holding each other accountable

A Developer accountability: team members hold each other to professional standards, rather than relying on a manager to do it. Read the chapter

Product Owner

One person accountable for maximizing the value of the product, through effective Product Backlog management. The only one who can cancel a Sprint. Read the chapter

Product Goal

A future state of the product the team plans against; the commitment for the Product Backlog. One Product Goal at a time — fulfilled or abandoned before the next. Read the chapter

Product Backlog management

Developing and communicating the Product Goal, creating and communicating items, ordering them, and keeping the Product Backlog transparent, visible and understood. Read the chapter

Stakeholders

People with an interest in the product. They influence the Product Backlog through the Product Owner and collaborate with the team at the Sprint Review. Read the chapter

Scrum Master

Accountable for establishing Scrum as defined in the Scrum Guide and for the Scrum Team's effectiveness. Serves the team, the Product Owner and the organization. Read the chapter

True leaders who serve

How the Scrum Guide describes Scrum Masters: leading by serving the Scrum Team and the wider organization, not by commanding. Read the chapter

Impediment

Anything blocking the team's progress that it can't easily resolve itself. The Scrum Master causes its removal — often by helping the team solve it. Read the chapter

Scrum Team effectiveness

The Scrum Master is accountable for it, by enabling the team to improve its practices within the Scrum framework. Read the chapter

Scrum Events

Sprint

A fixed-length event of one month or less that contains all the other events. A new Sprint starts immediately after the previous one ends. Read the chapter

Timebox

A maximum duration. For a one-month Sprint: Sprint Planning 8 h, Daily Scrum 15 min (always), Sprint Review 4 h, Sprint Retrospective 3 h. Read the chapter

Sprint cancellation

Only the Product Owner can cancel a Sprint, and only when the Sprint Goal becomes obsolete. Read the chapter

Sustainable pace

Working at a pace the team can keep up indefinitely, rather than through constant overtime. Read the chapter

Sprint Planning

Starts the Sprint. The whole Scrum Team plans why the Sprint is valuable, what can be Done and how. Max 8 hours for a one-month Sprint. Read the chapter

Sprint Goal

The single objective for the Sprint; the commitment for the Sprint Backlog. Set in Sprint Planning and fixed during the Sprint, with flexibility in the exact work. Read the chapter

Forecast

The Developers' selection of work for the Sprint, based on past performance, capacity and the Definition of Done — not a guarantee. Read the chapter

Capacity

How much work the Developers can take on in the upcoming Sprint, considered when they select items in Sprint Planning. Read the chapter

Daily Scrum

A 15-minute event for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog, every working day at the same time and place. Read the chapter

Actionable plan

The output of the Daily Scrum: a plan for the next day of work toward the Sprint Goal. Read the chapter

Re-planning

Developers can adjust their plan at any time, not only at the Daily Scrum, as they learn more during the Sprint. Read the chapter

Sprint Review

Inspects the outcome of the Sprint with key stakeholders and decides future adaptations. A working session, not a sign-off. Max 4 hours for a one-month Sprint. Read the chapter

Working session

How the Sprint Review should run: collaboration on what to do next, not just a presentation. Read the chapter

Key stakeholders

The people invited to the Sprint Review to inspect the Increment and help decide what to do next. Read the chapter

Sprint Retrospective

Plans ways to increase quality and effectiveness by inspecting individuals, interactions, processes, tools and the Definition of Done. Concludes the Sprint; max 3 hours. Read the chapter

Continuous improvement

Improving the way of working all the time. The Retrospective is the formal opportunity, but improvement can happen whenever it helps. Read the chapter

Improvement action

A change chosen in the Retrospective. The most impactful are addressed as soon as possible and may be added to the next Sprint Backlog. Read the chapter

Artifacts and Commitments

Product Backlog

An emergent, ordered list of what is needed to improve the product — the single source of work for the Scrum Team. One per product. Read the chapter

Product Backlog refinement

An ongoing activity of breaking down and adding detail (description, order, size) to items. Not an event; the Developers size the items. Read the chapter

Product Backlog item

A single entry in the Product Backlog. Its format is up to the team; user stories are one popular option. Read the chapter

Ready for selection

A Product Backlog item that can be Done by the team within one Sprint, so it can be selected in Sprint Planning. Read the chapter

Sprint Backlog

The Sprint Goal (why), the selected Product Backlog items (what) and the plan for delivering the Increment (how). A plan by and for the Developers, updated throughout the Sprint. Read the chapter

Sprint Goal

The single objective for the Sprint; the commitment for the Sprint Backlog. Set in Sprint Planning and fixed during the Sprint, with flexibility in the exact work. Read the chapter

Negotiating scope

When work turns out different than expected, the Developers and Product Owner adjust the Sprint Backlog's scope without affecting the Sprint Goal. Read the chapter

Increment

A concrete stepping stone toward the Product Goal: usable, verified and additive to all previous Increments. Born the moment an item meets the Definition of Done. Read the chapter

Definition of Done

The formal description of the state of the Increment when it meets the required quality measures. The commitment for the Increment; undone work can't be released or presented. Read the chapter

Releasing value

An Increment may be delivered before the Sprint ends. The Sprint Review is never a gate to releasing value. Read the chapter

The Scrum Master in Practice

Coaching

Asking questions that help people find their own answers — a core Scrum Master stance for building self-management. Read the chapter

Facilitation

Helping a group reach its outcome — in an event or discussion — without deciding for it. Read the chapter

Teaching

Explaining Scrum theory and practice when people don't yet understand it. Read the chapter

Mentoring

Sharing one's own experience to help someone grow. Read the chapter

Multiple Scrum Teams

Teams working on the same product share one Product Goal, one Product Backlog and one Product Owner, and the same Definition of Done. Read the chapter

Integrated Increment

One usable Increment combining the work of all teams on a product each Sprint; without it, transparency is lost. Read the chapter

Shared Definition of Done

When several teams work on one product, they must mutually define and comply with the same Definition of Done. Read the chapter

Dependencies

Work that relies on other work or teams. Reduced by ordering and splitting Product Backlog items and coordinating as often as needed. Read the chapter

Complementary practices

Useful practices that aren't part of Scrum, such as user stories, story points, velocity, burndown charts and a Definition of Ready. Read the chapter

Velocity

A team's own measure of work completed per Sprint, used for forecasting. Not in the Scrum Guide, and not comparable between teams. Read the chapter

Burndown chart

A chart of remaining work over time. A complementary forecasting practice; Scrum doesn't require it. Read the chapter

User stories

A popular format for Product Backlog items ('As a…, I want…, so that…'). Optional in Scrum. Read the chapter

Story points

A relative sizing unit some teams use. Optional; the Scrum Guide only says the Developers size the work. Read the chapter

Definition of Ready

A checklist some teams use before selecting items. Not part of Scrum — the Guide only says items that can be Done within one Sprint are ready for selection. Read the chapter

CAPM key terms

Project Management Fundamentals and Core Concepts

Project

Temporary work that creates a unique result. Distinguishes from operations (ongoing, repetitive) — a core first-question distinction on the exam. Read the chapter

Program

A group of related projects managed together for combined benefits unavailable from managing them separately — not just 'a big project.' Read the chapter

Portfolio

Projects, programs and other work grouped to meet a strategic business goal. Broader than a program; organized around strategy, not relatedness. Read the chapter

Operations

Ongoing, repetitive work — keeping things running, not creating something new. The opposite pole from 'project' in CAPM's first distinction. Read the chapter

Predictive approach

Plans the work in detail up front and executes to that plan. Fits stable, well-understood requirements and hierarchical structures best. Read the chapter

Adaptive approach

Plans in short cycles and adjusts as the team learns. Fits evolving requirements and flatter, faster-deciding structures best. Read the chapter

Issue

A problem that has already happened and needs a decision now — distinct from a risk, which hasn't happened yet and may never happen. Read the chapter

Risk

An uncertain future event that may or may not occur. If it's already happened, it's an issue, not a risk. Read the chapter

Assumption

Something believed true without proof. Needs validating — don't confuse with a constraint (a limit) or a risk (an uncertainty). Read the chapter

Constraint

A limiting factor on your project's options (budget, timeline, resources). Should be respected unless formally changed, not ignored when inconvenient. Read the chapter

Project management plan

Describes how the project itself will be managed — schedule, cost, risk, communication. Distinct from the product management plan. Read the chapter

Product management plan

Describes the product being built and its lifecycle. Answers a different question than the project management plan. Read the chapter

Milestone

A significant point in time with zero duration — not a span of effort. 'The milestone takes two weeks' is always a contradiction. Read the chapter

Risk register

Documents identified risks, their owners, and planned responses. A living document, actively maintained, not created once and filed away. Read the chapter

Stakeholder register

Documents who stakeholders are and their interest/influence. Check it first when a stakeholder-engagement question comes up. Read the chapter

Project closure

Includes transitioning the result to operations, releasing resources, and capturing lessons learned — not just shipping the deliverable. Read the chapter

Project sponsor

Champions the project, secures funding, and removes organizational-level obstacles the PM can't clear alone. Read the chapter

Project manager

Runs the day-to-day — planning, coordinating, delivering — playing several situational roles: initiator, negotiator, listener, coach, working member, facilitator. Read the chapter

Leadership vs. management

Management plans/organizes/controls toward defined objectives; leadership inspires and sets direction, often without formal authority. Read the chapter

Emotional intelligence (EQ)

Recognizing and managing your own emotions and reading others'. Tested as a practical skill — noticing and addressing team friction constructively. Read the chapter

Communication plan

Defines who needs what information, when, and how. Deviating from an agreed plan should be deliberate and documented, not quiet. Read the chapter

Risk response strategy

A planned reaction to an identified risk, prepared in advance — distinct from a workaround, which is improvised on the spot. Read the chapter

Benefit planning

Being explicit about what business value a project should deliver and how that value will be measured — paired with project initiation. Read the chapter

Project initiation

The point a project is formally authorized to begin, typically marked by a charter. Read the chapter

Stand-up meeting

Short, frequent, focused on progress and blockers — not a forum for deep design discussion. The classic 'wrong tool' exam scenario misuses it for that. Read the chapter

Focus group

Gathers targeted stakeholder or customer input on a specific question — a smaller, more targeted tool than a survey. Read the chapter

Brainstorming

Generates a wide range of new ideas quickly, deferring judgment. Misused when a team reaches for it to retrieve one already-known answer. Read the chapter

Meeting effectiveness

Judged by clear purpose, the right people, and a recorded decision or output — not by attendance or duration alone. Read the chapter

Predictive, Plan-Based Methodologies

Predictive approach

Plans the work in detail up front and executes to that plan. Fits stable, well-understood requirements and hierarchical structures best. Read the chapter

Organizational structure

Virtual, co-located, matrix, or hierarchical. Predictive approaches tend to fit hierarchical structures better; adaptive fits flatter ones better. Read the chapter

Process

A predictive-project grouping of activities (e.g., planning, executing). Each process has typical, recognizable activities within it. Read the chapter

Project component

A distinct piece of the project plan (scope statement, schedule, budget) — each answers a different question and is managed separately. Read the chapter

Critical path method (CPM)

Finds the longest sequence of dependent tasks through the project — the critical path — which sets the minimum possible duration. Read the chapter

Schedule variance (SV)

SV = EV − PV. Positive means ahead of schedule, negative means behind. One of the exam's most reliable calculation questions. Read the chapter

Work breakdown structure (WBS)

Decomposes total scope into smaller pieces down to work packages. Shows everything that must be done — not time or sequence (that's the schedule's job). Read the chapter

Work package

The lowest-level WBS piece, small enough to realistically estimate, schedule and assign. Read the chapter

Quality management plan

Describes how quality will be managed and verified — without a defined acceptance standard, stakeholders can later disagree over acceptability. Read the chapter

Integration management plan

Ties every other piece of the project plan together into one coherent whole, so a scope change is reflected in schedule and budget too. Read the chapter

Cost variance (CV)

CV = EV − AC. Positive means under budget, negative means over budget — calculated the same simple way every time. Read the chapter

Project artifact

A predictive control document — status report, variance analysis, change log — that lets anyone see whether the project is on track. Read the chapter

Status report

Summarizes current progress against the plan. One of the named predictive control artifacts. Read the chapter

Agile Frameworks/Methodologies

Adaptive approach

Plans in short cycles and adjusts as the team learns. Fits evolving requirements and flatter, faster-deciding structures best. Read the chapter

Organizational process assets (OPAs)

An organization's existing templates, historical data, and lessons learned — can support or conflict with adopting an adaptive approach. Read the chapter

Enterprise environmental factors (EEFs)

Broader conditions like culture or marketplace conditions that influence whether an approach (especially adaptive) takes hold. Read the chapter

Iteration

A fixed-length, repeatable cycle of planning, building and reviewing a slice of the product. Called a sprint specifically in Scrum. Read the chapter

Sprint

Scrum's name for an iteration — a fixed-length cycle with planning, daily check-ins, review and retrospective. Read the chapter

Backlog

A living, re-prioritized list of everything that might go into the product, refined close to when items will actually be worked on. Read the chapter

Adaptive tracking

Velocity, burndown — reflects incremental, iteration-based progress better than percent-complete against a fixed predictive baseline. Read the chapter

Product backlog

The full, prioritized list of everything that might be built — distinct from the sprint backlog's smaller, committed slice. Read the chapter

Sprint backlog

The smaller slice of the product backlog committed to the current iteration. Read the chapter

Burndown chart

Tracks remaining work against time within the current iteration — shows at a glance whether the team is on pace to finish. Read the chapter

Increment

The actual, potentially shippable piece of product produced by the end of an iteration. Read the chapter

Scrum

An adaptive framework with fixed-length sprints, defined roles (Scrum Master, Product Owner, Developers), and named events. Read the chapter

Extreme Programming (XP)

Shares Scrum's iterative cadence but adds engineering practices: pair programming, test-driven development, continuous integration. Read the chapter

Kanban

Continuous flow against a work-in-progress (WIP) limit — no fixed-length iterations, unlike Scrum, XP or SAFe. Read the chapter

Scaled Agile Framework (SAFe)

Coordinates many agile teams working toward one larger program or portfolio goal — a scaling framework, not a single-team method. Read the chapter

Definition of Done

The team's consistent, shared bar for what 'finished' means for any item — prevents repeated, item-by-item disagreement. Read the chapter

Acceptance criteria

Conditions a specific item must meet to be considered satisfied, defined in advance — turns 'is this done?' into a checklist. Read the chapter

Backlog prioritization

Weighs business value, risk, and dependencies together — an item that unblocks other work often jumps ahead of a higher-value one. Read the chapter

Business Analysis Frameworks

Business analyst (BA)

Understands what the business needs and translates it into requirements the team can build against — distinct from the PM's role. Read the chapter

Process owner

Accountable for a business process overall — distinct from the process manager, who runs it day-to-day. Read the chapter

Process manager

Runs a business process's day-to-day operation — distinct from the process owner's overall accountability. Read the chapter

Product owner

Owns and prioritizes a single Scrum team's backlog — narrower in scope than a product manager's broader strategic ownership. Read the chapter

Internal vs. external stakeholder

Internal: employees, internal teams. External: customers, regulators, vendors. Each may need different engagement. Read the chapter

Communication channel

Should match the message's scale, audience, and need for discussion vs. a quick update — a workshop and a one-line message solve different problems. Read the chapter

Status report

Summarizes current progress against the plan. One of the named predictive control artifacts. Read the chapter

Stakeholder presentation

Fits a group decision or discussion moment — a heavier channel than a quick update, lighter than a full detailed document. Read the chapter

User story

A short, outcome-focused requirement format ('As a [role], I want [goal], so that [benefit]') — fits adaptive work well. Read the chapter

Use case

A detailed, step-by-step description of a user-system interaction, including alternate paths — fits complex or predictive work. Read the chapter

Requirements traceability matrix (RTM)

Links each requirement to its source and to the deliverable that satisfies it — the product backlog plays an overlapping role on adaptive projects. Read the chapter

Stakeholder interview

A one-on-one gathering method — suits nuanced, individual input better than broad-reach tools like a survey. Read the chapter

Requirements workshop

Brings multiple stakeholders together to align on requirements in real time — fits contentious, multi-party trade-offs. Read the chapter

Product roadmap

Shows high-level direction and major capabilities over time, release by release — trades detail for a shared forward-looking picture. Read the chapter

Release plan

Determines which components go into which release — guided by dependencies and whether each release's theme holds together coherently. Read the chapter

Release

A planned delivery point on the roadmap — components that depend on each other must be sequenced into the correct release order. Read the chapter

BA role in predictive projects

Typically gathers and documents requirements comprehensively up front, producing specifications the team builds against with limited expected change. Read the chapter

BA role in adaptive projects

Works continuously alongside the team, refining and re-prioritizing the backlog as it learns — not a single upfront phase. Read the chapter

Acceptance criteria

Conditions a specific item must meet to be considered satisfied, defined in advance — turns 'is this done?' into a checklist. Read the chapter

Delivery readiness

Confirming every committed requirement was delivered and verified against its acceptance criteria — not just that development stopped. Read the chapter

Validation

Confirming, after delivery, that what was built actually satisfies what was asked — distinct from gathering, which captures what's needed upfront. Read the chapter

PMI-PBA key terms

Needs Assessment

Problem analysis

Techniques used to get past a vague complaint and identify the real underlying business problem before any solution is scoped. Read the chapter

Opportunity analysis

Parallel to problem analysis, but for a positive opening rather than a pain point — both feed a solution scope statement and business case. Read the chapter

Solution scope statement

Bounds what the eventual solution will and won't cover, built directly from the defined business problem or opportunity. Read the chapter

Business case

The justification for an initiative — why the organization should invest, grounded in the value proposition a BA helps determine. Read the chapter

Valuation technique

Tools like cost-benefit analysis or SWOT used to help determine an initiative's value proposition from collected data. Read the chapter

Value proposition

The specific, measurable value an initiative is meant to create — a vague claim with no measurable component can't be evaluated later. Read the chapter

Cost-benefit analysis

A valuation technique comparing an initiative's expected costs against its expected benefits to support a funding decision. Read the chapter

SWOT analysis

A valuation technique assessing strengths, weaknesses, opportunities, and threats as input to a value proposition. Read the chapter

Project goals and objectives

Set collaboratively, with the BA clarifying business needs and solution scope so the product stays aligned with organizational goals. Read the chapter

Solution scope

What the eventual solution will and won't cover — established early and checked for alignment throughout Analysis and validation. Read the chapter

Strategic alignment

Checking that a project's objectives still map to the organization's broader goals, not just its own narrower stated targets. Read the chapter

Stakeholder identification

An ongoing review of goals, objectives, and requirements — not a one-time list — to catch stakeholders whose relevance emerges later. Read the chapter

Internal stakeholder

A stakeholder inside the organization — an employee, internal team, or process owner. Read the chapter

External stakeholder

A stakeholder outside the organization — a customer, regulator, or vendor — classified by interest/influence, not formal relationship. Read the chapter

Representation

Making sure identified stakeholders are actually represented, informed, and involved — not just logged in a register and left there. Read the chapter

Stakeholder values

What each stakeholder actually cares about regarding the product, drawn out through elicitation and used as a prioritization baseline. Read the chapter

Elicitation technique

A method for drawing requirements out of stakeholders — individual (interviews) or group (workshops), matched to the situation. Read the chapter

Prioritization baseline

The documented record of elicited stakeholder values, referenced later whenever competing requirements need to be prioritized. Read the chapter

Planning

Business case

The justification for an initiative — why the organization should invest, grounded in the value proposition a BA helps determine. Read the chapter

Project context

What reviewing the business case and goals/objectives provides before detailed planning — grounding planning decisions in why the project exists. Read the chapter

Scope of BA work

How much formal process a BA's planning and analysis work actually needs — should scale to the business case's real stakes. Read the chapter

Traceability strategy

Decided during Planning: how rigorously each requirement will be linked source-to-delivery, scaled to the project's actual risk. Read the chapter

Requirements traceability matrix (RTM)

Links every requirement back to its source and forward to its delivery evidence — formal, predictive-style traceability. Read the chapter

Level of traceability

How much traceability rigor a given project actually needs — a regulated initiative needs more than a small internal one. Read the chapter

Requirements management plan

The operating agreement for a project's BA work: stakeholders, roles, communication protocols, and elicitation/approval methods. Read the chapter

Roles and responsibilities

Who is involved in requirements work and in what capacity — defined upfront in the requirements management plan to prevent later disputes. Read the chapter

Elicitation method

The specific technique chosen to draw out a requirement — matched to the situation, not defaulted to one method for everything. Read the chapter

Approval process

The defined path a requirement follows to be formally approved — should be documented upfront, not improvised mid-project. Read the chapter

Change control

The defined channels and processes for submitting, reviewing, and managing requirement change requests. Read the chapter

Change request channel

A specific, known intake point for change requests — without one, requests arrive informally and are easy to lose track of. Read the chapter

Change management plan

The project's broader change process, into which requirements-specific change control methods feed standard protocols. Read the chapter

Document control

Tools and conventions — versioning, approval stamps, a shared repository — that keep a clean, traceable requirements-document history. Read the chapter

Version control

Conventions (numbering, approval stamps, a shared repository) that prevent team members from working off diverged document versions. Read the chapter

Documentation management tool

A tool used to implement document control, keeping requirements document versions clear and current. Read the chapter

Business metric

A measurable, overall target defined collaboratively with stakeholders during Planning — the broader bar the initiative aims for. Read the chapter

Acceptance criteria

Specific, measurable conditions a requirement or solution must meet — set broadly during Planning, elaborated item-by-item in Analysis. Read the chapter

Stakeholder collaboration

Working directly with stakeholders — not unilaterally — to define business metrics, acceptance criteria, and prioritization. Read the chapter

Analysis

Elicitation technique

A method for drawing requirements out of stakeholders — individual (interviews) or group (workshops), matched to the situation. Read the chapter

Individual elicitation

Techniques like interviews, observation, or document analysis suited to deep, one-on-one or sensitive input. Read the chapter

Group elicitation

Techniques like workshops or focus groups suited to surfacing a wide range of input or resolving disagreement in real time. Read the chapter

Requirement rationale

The origin and justification behind a requirement — why it exists — captured alongside the requirement text for later evaluation. Read the chapter

Dependency analysis

Examining what relies on what among requirements, used both during decomposition and later allocation/sequencing decisions. Read the chapter

Interface analysis

Examining how a system or process connects to and interacts with other systems — prototyping and storyboarding are common techniques. Read the chapter

Data modeling

Visualizing how information flows and is structured, used during requirements decomposition to clarify product options. Read the chapter

Process modeling

Visualizing how work flows, used during requirements decomposition alongside data and dependency analysis. Read the chapter

Decision-making technique

Tools like multi-voting or weighted criteria used to evaluate product options and reach a defensible, structured choice. Read the chapter

Accepted requirement

A requirement that evaluation determined belongs in the solution — distinct from deferred (valid, not now) or rejected (doesn't fit). Read the chapter

Deferred requirement

A requirement with real merit that doesn't fit the current baseline — stays visible for a future release, not discarded. Read the chapter

Rejected requirement

A requirement determined not to fit the solution scope or value proposition — unlike deferred, not expected to be built later. Read the chapter

Requirements baseline

The agreed, documented set of requirements a project will actually build against — the output of allocation. Read the chapter

Allocation

Deciding which accepted requirements fit the current baseline, balancing scope/schedule/budget/resources against value. Read the chapter

Prioritization technique

Tools like weighted criteria or MoSCoW used during allocation to decide which requirements take precedence given constraints. Read the chapter

Sign-off

Genuine stakeholder consensus and approval, obtained through decision-making techniques — not a rushed approval with an objection waved off. Read the chapter

Stakeholder consensus

Real agreement reached by working through disagreement, not simply approval from whoever happened to be in the room. Read the chapter

Baseline approval

See Sign-off — the formal, genuine stakeholder agreement that locks in a requirements baseline. Read the chapter

Use case

A detailed, step-by-step interaction between a user and a system, including alternate paths — fits complex or predictive work. Read the chapter

User story

A short, outcome-focused requirement format ('As a..., I want..., so that...') — fits adaptive work and simpler requirements. Read the chapter

Requirements specification

The written, buildable form of a requirement — process detail (use case/user story), data detail, and interface detail together. Read the chapter

Measurable requirement

A requirement specific enough that two people can't reasonably disagree about what it means — the real bar 'actionable' requires. Read the chapter

Requirements validation

Checking written requirements for completeness, accuracy, and alignment with goals/objectives/value proposition before development. Read the chapter

Prototype

A concrete artifact stakeholders can react to, often surfacing misalignment earlier than a written description alone. Read the chapter

Demo

A live walkthrough used to validate requirements, letting stakeholders react to something tangible before full development. Read the chapter

Documentation review

A validation method suited to textual or process-based requirements where a visual demo wouldn't add significant clarity. Read the chapter

Detailed acceptance criteria

Item-level, specific conditions elaborated during Analysis — more granular than Planning's broader business metrics. Read the chapter

Measurement tool

A technique (such as a service level agreement) used to specify detailed, measurable acceptance criteria for a requirement. Read the chapter

Given-when-then

A format for writing precise, testable acceptance criteria: a triggering condition and an expected, checkable outcome. Read the chapter

Traceability and Monitoring

Traceability artifact

A tool (often an RTM) that records a requirement's status, sources, and relationships — maintained on an ongoing basis. Read the chapter

Requirement status

A requirement's current lifecycle state — needs to be kept genuinely in sync with reality, not left stale in the tracking tool. Read the chapter

Requirement dependency

A relationship where one requirement relies on another — captured during tracking and critical to later change-impact assessment. Read the chapter

Requirement lifecycle

The stages a requirement moves through — elicited, analyzed, approved, built, tested, delivered — tracked toward a definite closure. Read the chapter

Supporting artifact

A model, document, or test case expected at a specific lifecycle stage — a requirement can look 'on track' while one is quietly missing. Read the chapter

Lifecycle monitoring

Checking that required supporting artifacts (models, documentation, test cases) exist and are approved at each lifecycle stage. Read the chapter

Lifecycle state

A requirement's specific point in its lifecycle — updates should be both recorded in the tool and communicated to stakeholders. Read the chapter

Status update

Recording a requirement's new lifecycle state and communicating it — a status change without communication misses the point. Read the chapter

Closure

A requirement reaching a definite final lifecycle state — delivered and verified, or formally withdrawn — rather than lingering ambiguously. Read the chapter

Status communication

Proactively informing the project manager and stakeholders of requirements issues, conflicts, changes, risks, and overall status. Read the chapter

Requirements issue

A problem with a requirement needing communication and resolution — distinct from simply logging it and hoping someone checks. Read the chapter

Requirements risk

A potential problem affecting requirements that needs proactive, not just logged, communication to the project manager. Read the chapter

Change impact assessment

Evaluating a proposed change's impact, dependencies, and risk against the change control plan before it's approved. Read the chapter

Requirements baseline comparison

Comparing a proposed change against the existing baseline to understand exactly what would actually change. Read the chapter

Requirements integrity

Keeping a requirement and every associated artifact consistent after a change — nothing left half-updated or out of sync. Read the chapter

Evaluation

Test evidence

Actual test results, reports, and other proof reviewed against acceptance criteria to determine whether a solution satisfies requirements. Read the chapter

Acceptance criteria validation

Checking actual test results and evidence against documented acceptance criteria — not accepting a developer's word alone. Read the chapter

Solution satisfaction

Whether the solution genuinely satisfies its requirements, confirmed through validated test evidence, not assumption. Read the chapter

Gap analysis

Analyzing a solution's identified gaps and deltas using QA tools, to enable stakeholders to resolve discrepancies. Read the chapter

Delta

The specific, measurable difference between what was required and what was actually delivered, surfaced during gap analysis. Read the chapter

Quality assurance tool

A method used specifically to analyze a solution's gaps and deltas against requirements — not informal, undocumented conversation. Read the chapter

Solution sign-off

Formal stakeholder agreement that the developed, validated solution is ready — the gate that enables proceeding with deployment. Read the chapter

Deployment decision

The decision to proceed with deployment, enabled by (and only after) genuine stakeholder sign-off on the developed solution. Read the chapter

Post-deployment evaluation

Checking the deployed solution against the original business case and value proposition, not just individual requirements. Read the chapter

Business case comparison

Measuring a deployed solution's actual results against what the original business case promised — where real value gaps surface. Read the chapter

Value proposition realization

Whether the value an initiative promised during Needs Assessment actually materialized after deployment. Read the chapter