PMBOK 7 - Scope & Require - Free Practice Quiz

Question 1 of 150

A PM is initiating a project to develop a new mobile banking application. The sponsor asks for a product analysis before requirements gathering begins. What is the PRIMARY purpose of product analysis?

A To assign resources to the project team B To understand the product's purpose, features, and characteristics by analyzing product descriptions, market needs, and technical capabilities — forming the foundation for detailed requirements C To finalize the project budget D To create the project schedule

1 / 150

Question 2 of 150

A PM uses multiple requirements gathering techniques including interviews, focus groups, questionnaires, and observation. A stakeholder suggests adding 'benchmarking' to the mix. When is benchmarking MOST valuable for requirements gathering?

A Only when the budget allows for external consultants B Only for manufacturing projects C Benchmarking is never used in requirements gathering D When the organization wants to compare its planned product or process against industry best practices or competitors to identify requirements that ensure competitive parity or advantage

2 / 150

Question 3 of 150

A PM conducts interviews with 20 stakeholders and receives conflicting requirements. The marketing team wants maximum features for market appeal, while operations wants minimal complexity for maintainability. What should the PM do FIRST?

A Document all requirements with their sources, then facilitate a prioritization workshop where stakeholders collaboratively rank requirements against project objectives, constraints, and the business case B Escalate immediately to the sponsor without analysis C Choose the marketing team's requirements since they drive revenue D Implement all requirements from both groups

3 / 150

Question 4 of 150

A PM uses a focus group to gather requirements for a healthcare portal. The group includes doctors, nurses, administrators, and patients. The doctors dominate the conversation while patients remain quiet. What facilitation technique should the PM use?

A Use structured facilitation techniques such as round-robin input, anonymous submission, breakout groups by role, or nominal group technique to ensure all voices are heard equally B Remove patients from the focus group since they add no value C Accept the doctors' requirements since they are the experts D Conduct a separate focus group with only doctors

4 / 150

Question 5 of 150

A PM uses questionnaires to gather requirements from 500 end users across multiple locations. The response rate is 15%. What should concern the PM about this response rate?

A The 85% non-respondents may have different needs and priorities than the respondents, creating a self-selection bias that could result in requirements that do not represent the full user population B Questionnaires are not valid for requirements gathering C The PM should accept the 15% as representative D 15% is an excellent response rate for questionnaires

5 / 150

Question 6 of 150

A PM uses observation (job shadowing) to gather requirements for a warehouse management system. During observation, the PM notices that workers use unofficial workarounds not documented in standard procedures. What is the significance of this finding?

A Workarounds reveal gaps between official processes and actual needs — the new system should address the underlying problems that caused the workarounds, as they represent real but undocumented requirements B Only official procedures should inform requirements C Workarounds are irrelevant to system requirements D The workarounds should be reported as violations

6 / 150

Question 7 of 150

A PM collects requirements and organizes them into a requirements traceability matrix (RTM). What is the PRIMARY purpose of the RTM?

A To calculate the project budget based on requirements B To link each requirement to its business objective, track it through design, development, testing, and delivery, ensuring no requirement is lost and all deliverables map back to a valid need C To list requirements in alphabetical order D To assign each requirement to a specific team member

7 / 150

Question 8 of 150

A PM uses the technique of 'context diagrams' during product analysis. What does a context diagram show?

A The product scope boundary — showing the product/system at the center and all external entities (users, systems, organizations) that interact with it, clarifying what is inside and outside scope B The cost breakdown structure C The project organizational chart D The project schedule in diagram form

8 / 150

Question 9 of 150

Requirements can be classified as functional and non-functional. A stakeholder states: 'The system must process 10,000 transactions per second.' What type of requirement is this?

A Functional requirement B Business requirement C Non-functional requirement — it specifies a performance characteristic (how well the system must perform) rather than a specific behavior (what the system does) D Transitional requirement

9 / 150

Question 10 of 150

During requirements workshops, a technique called 'affinity diagrams' is used. The team generates 200 individual requirements on sticky notes. What does the affinity diagram technique accomplish?

A It prioritizes requirements by cost B It assigns requirements to team members C It eliminates duplicate requirements D It organizes large numbers of requirements into natural groupings or themes by having participants collaboratively sort items based on their relationships, revealing patterns and categories

10 / 150

Question 11 of 150

A PM must distinguish between product scope and project scope. A stakeholder asks for the difference. What is the MOST accurate distinction?

A Project scope is always larger than product scope B Product scope defines the features and functions of the deliverable (what it does); project scope defines the work required to create the deliverable (what work must be done) — product scope drives project scope C Product scope is only relevant in manufacturing D They are the same thing

11 / 150

Question 12 of 150

A PM uses value engineering as part of product analysis. What does value engineering seek to achieve?

A Increase the project budget to add premium features B Eliminate all non-essential features C Optimize the product's function-to-cost ratio by finding ways to maintain or improve required functionality while reducing cost, without sacrificing quality or performance D Maximize the number of features regardless of cost

12 / 150

Question 13 of 150

A PM is gathering requirements for a project that will span 18 months. Some requirements are well understood now, while others will emerge as the project progresses. What planning approach does PMBOK 7 recommend?

A Skip requirements gathering and let the team figure it out B Progressive elaboration — start with well-understood requirements at full detail and plan for iterative refinement of less-clear requirements as more information becomes available through the project lifecycle C All requirements must be finalized before any work begins D Only plan for the first 3 months of requirements

13 / 150

Question 14 of 150

A PM is collecting requirements and realizes that different stakeholders use different terminology for the same concepts. 'Report,' 'dashboard,' and 'analytics view' are used interchangeably. What should the PM create?

A Use only the sponsor's terminology B Let each team interpret terms as they see fit C A project glossary or data dictionary that standardizes terminology, ensuring all stakeholders share a common understanding of key terms to prevent semantic confusion during development D Ignore the terminology differences since the intent is similar

14 / 150

Question 15 of 150

A PM uses the Delphi technique to gather requirements from subject matter experts. What is the KEY characteristic of the Delphi technique that makes it useful for requirements gathering?

A It requires all experts to be in the same room B Expert opinions are gathered anonymously through iterative rounds, reducing groupthink and the influence of dominant personalities, until consensus emerges C It produces requirements in a single round D It only works for technical requirements

15 / 150

Question 16 of 150

What is the PRIMARY purpose of decomposition in scope management?

A To assign all work to individual team members B To increase the project budget through detailed cost estimation C To eliminate unnecessary project features D To break down the project scope into smaller, more manageable components — subdividing deliverables and work into progressively smaller pieces until they can be planned, estimated, and controlled effectively

16 / 150

Question 17 of 150

A PM is decomposing the project scope. At what level should decomposition stop?

A At the work package level — the lowest level of the WBS where work can be reliably estimated for cost and duration, assigned to a responsible party, and monitored for progress B Decomposition should continue until every individual task is listed C At the phase level only D At the activity level with detailed task descriptions

17 / 150

Question 18 of 150

A team member argues that more decomposition always leads to better control. The PM disagrees. What is the risk of EXCESSIVE decomposition?

A Over-decomposition creates excessive management overhead, obscures the big picture, increases documentation burden, and can lead to micromanagement that reduces team autonomy and productivity B The WBS standard requires exactly 5 levels C There is no risk; more detail is always better D Excessive decomposition only affects the budget

18 / 150

Question 19 of 150

The '100% rule' is a fundamental principle of WBS decomposition. What does it state?

A Decomposition must create exactly 100 work packages B 100% of team members must be assigned to WBS elements C The WBS must capture 100% of the project scope — the sum of all child elements must equal 100% of the work in the parent, and nothing should exist in the WBS that is not within the project scope D 100% of the budget must be allocated to WBS elements

19 / 150

Question 20 of 150

A PM is decomposing a software project. The team identifies a 'Research & Development' work package that involves exploring new technologies with uncertain outcomes. Why is this work package challenging to decompose further?

A R&D work packages should never appear in a WBS B R&D work is inherently uncertain — the outcomes are unknown, making it difficult to predefine specific deliverables or subdivide the work into predictable components; the PM may need to use rolling wave planning for this element C R&D requires exactly 3 levels of decomposition D All work packages must be decomposed to the same level

20 / 150

Question 21 of 150

A PM uses a 'deliverable-oriented' decomposition approach versus an 'activity-oriented' approach. What is the KEY difference and which does PMBOK recommend for WBS creation?

A There is no difference between the approaches B Activity-oriented is always superior C Both approaches are used interchangeably in the WBS D Deliverable-oriented decomposition breaks scope into tangible outputs (what is produced); activity-oriented breaks it into tasks (what is done). PMBOK recommends deliverable-oriented decomposition for the WBS, with activity decomposition occurring during schedule development

21 / 150

Question 22 of 150

During decomposition, a team member identifies work that does not fit under any existing WBS branch. The PM realizes this is legitimate project work that was overlooked. What should the PM do?

A Exclude it since it was not in the original scope B Create a separate project for this work C Hide it under an existing work package D Add a new WBS branch or element to capture the work, as the 100% rule requires that all authorized project work is represented — this discovery improves WBS completeness

22 / 150

Question 23 of 150

A PM is decomposing a construction project. The first level of decomposition is by project phase (Design, Build, Test). An alternative is to decompose by major deliverable (Foundation, Structure, Electrical, Plumbing). What are the trade-offs?

A Phase-based decomposition aligns with the project lifecycle but may scatter related deliverable work across phases; deliverable-based groups all work for each deliverable together, making it easier to assign responsibility and track completion of tangible outputs B The approaches produce identical WBS structures C Deliverable-based only works for software projects D Phase-based is always superior for construction

23 / 150

Question 24 of 150

A PM uses 'planning packages' in the WBS. What are planning packages and when are they appropriate?

A Planning packages are optional documentation B Planning packages are only used in agile projects C Planning packages are the same as work packages D Planning packages are WBS elements below a control account but above work packages — they represent known work content that has not yet been decomposed into work packages, used in rolling wave planning when future work details are not yet clear

24 / 150

Question 25 of 150

The team completes WBS decomposition and reviews it for quality. What verification checks should be performed to ensure the WBS is sound?

A Only the PM needs to review the WBS B Only check that the WBS fits on one page C Verify: 100% rule compliance (all scope captured), work packages are estimable and assignable, no duplicate work across branches, deliverable-oriented language, appropriate decomposition depth, and team consensus that the WBS is complete D Verification is not necessary for WBS

25 / 150

Question 26 of 150

A PM decomposes a project and creates WBS element numbering: 1.0, 1.1, 1.1.1, 1.1.2, 1.2, 1.2.1, etc. What is this numbering system called and why is it important?

A The WBS code of accounts — a unique identifier for each WBS element that enables cost tracking, work authorization, and traceability across schedules, budgets, and performance reports B Random numbering assigned by software C It is decorative formatting with no project management purpose D The numbering is only for the WBS dictionary

26 / 150

Question 27 of 150

An agile team does not create a traditional WBS. Instead, they use a product backlog with user stories decomposed into tasks during sprint planning. Is this consistent with decomposition principles?

A The product backlog replaces all scope management B Agile projects do not require any decomposition C Yes — the product backlog (epics → features → user stories → tasks) follows the same decomposition principle of breaking large scope into smaller, manageable units; the format differs but the concept is the same D No, agile teams must still create a traditional WBS

27 / 150

Question 28 of 150

A PM notices that one branch of the WBS is decomposed to 6 levels while another branch only has 2 levels. Is this acceptable?

A Yes — different branches may require different decomposition depths based on complexity, risk, and the level of detail needed for management; the key is that each work package is at an estimable and manageable level B No branch should exceed 3 levels C No, all WBS branches must have the same number of levels D The deepest branch determines the required depth for all branches

28 / 150

Question 29 of 150

A PM is determining work package size. The team suggests using the '8/80 rule.' What does this rule recommend?

A Decomposition should take between 8 and 80 hours B Work packages should require between 8 hours and 80 hours of effort — small enough to monitor and control effectively, but large enough to avoid excessive management overhead C Work packages should cost between $8,000 and $80,000 D The WBS should have between 8 and 80 work packages total

29 / 150

Question 30 of 150

During decomposition, the PM realizes that a deliverable crosses organizational boundaries — requiring contributions from Engineering, Marketing, and Legal. How should this be handled in the WBS?

A Assign it entirely to one department and let them coordinate B The cross-functional deliverable can remain as a single WBS element with sub-elements assigned to different departments, or it can be decomposed by functional contribution — the key is clear responsibility assignment through a responsibility assignment matrix (RAM/RACI) C Create separate WBS branches for each department D Exclude cross-functional deliverables from the WBS

30 / 150

Question 31 of 150

A PM decides to build a prototype before finalizing requirements. What is the PRIMARY purpose of prototyping in scope management?

A To replace the requirements document entirely B To deliver the final product early C To test the development team's technical skills D To create a tangible, working model that stakeholders can interact with, enabling them to refine and validate requirements before committing to full development — reducing the risk of building the wrong thing

31 / 150

Question 32 of 150

A PM must choose between a 'throwaway' prototype and an 'evolutionary' prototype. The project has high uncertainty about user interface requirements. Which approach is MOST appropriate?

A Throwaway prototypes are never appropriate B Skip prototyping and rely on written requirements C An evolutionary prototype that becomes the final product D A throwaway prototype built quickly to explore and validate UI concepts, then discarded — it is cheaper and faster than an evolutionary prototype when the goal is learning, not building toward production

32 / 150

Question 33 of 150

After reviewing a prototype, stakeholders provide feedback that significantly changes 40% of the original requirements. The development lead is frustrated by the rework. How should the PM frame this situation?

A The prototype was a waste of time since it led to requirement changes B The prototype succeeded — discovering that 40% of requirements were wrong before full development saved far more time and cost than it would have to rework a completed product; early rework is cheap rework C The stakeholders are being unreasonable with their changes D Prototyping should be avoided on future projects to prevent changes

33 / 150

Question 34 of 150

A PM uses storyboards as a prototyping technique. What is a storyboard in the context of requirements validation?

A A visual sequence of screens or user interactions that walks stakeholders through a process or workflow, showing how the user will experience the product step by step without building functional software B A project timeline displayed graphically C A comic strip about the project team D A detailed technical architecture diagram

34 / 150

Question 35 of 150

A PM conducts a formal requirements review (inspection) and discovers that 15 requirements are ambiguous — they can be interpreted in multiple ways. What is the PRIMARY risk of ambiguous requirements?

A Each person interpreting an ambiguous requirement may build something different from what was intended, leading to rework, scope disputes, and failed acceptance testing when the deliverable does not match stakeholder expectations B Ambiguous requirements only affect documentation quality C Ambiguous requirements save time because they give developers flexibility D Ambiguity is acceptable if the development team is experienced

35 / 150

Question 36 of 150

A PM uses 'validated requirements' as an input to scope definition. What makes a requirement 'validated'?

A It has been reviewed by stakeholders, confirmed to accurately represent their needs, verified as feasible, checked for conflicts with other requirements, and accepted as ready for inclusion in the scope baseline B It has been assigned to a developer C It has passed spell-checking D It has been written down in the requirements document

36 / 150

Question 37 of 150

A PM uses wireframes to validate requirements for a web application. Stakeholders approve the wireframes. During development, stakeholders see the actual application and say it 'doesn't feel right' despite matching the approved wireframes. What happened?

A Wireframes are low-fidelity and do not capture the full user experience — visual design, interaction behavior, and performance feel are absent from wireframes; higher-fidelity prototypes or iterative delivery with feedback would have caught this gap earlier B The stakeholders are being unreasonable C Wireframes are invalid as a validation technique D The development team deviated from the wireframes

37 / 150

Question 38 of 150

In agile, the sprint review serves as a requirements validation mechanism. How does this differ from prototype-based validation in a predictive approach?

A There is no difference B Sprint reviews replace all requirements activities C Sprint reviews validate working, potentially shippable software rather than prototypes — stakeholders provide feedback on actual functionality, and the product backlog is adjusted based on validated learning, creating a continuous validation loop D Sprint reviews are only for the development team

38 / 150

Question 39 of 150

A PM wants to validate that requirements are testable before including them in the scope baseline. What characteristic makes a requirement 'testable'?

A It includes specific, measurable acceptance criteria that allow an objective pass/fail determination — if you cannot define a test that proves the requirement is met, the requirement is not testable B It is written in technical language C It is included in the WBS D It has been approved by the sponsor

39 / 150

Question 40 of 150

A PM is deciding between investing in requirements prototyping versus proceeding directly to development with documented requirements. What factors should inform this decision?

A Prototype only if the sponsor explicitly requests it B Consider: the level of requirements uncertainty, the cost of potential rework if requirements are wrong, stakeholders' ability to articulate needs from documents alone, and whether the technology or domain is novel — higher uncertainty favors prototyping investment C Never prototype because it delays the project D Always prototype regardless of circumstances

40 / 150

Question 41 of 150

What is the PRIMARY purpose of the project scope statement?

A To serve as the project contract with the customer B To describe the project's major deliverables, assumptions, constraints, and boundaries in detail — defining what is included and explicitly what is excluded from the project scope C To list all project team members and their roles D To provide the detailed project schedule

41 / 150

Question 42 of 150

A scope statement includes explicit 'exclusions.' A stakeholder argues that listing what the project will NOT do is negative and unnecessary. Why are exclusions valuable?

A Exclusions are only needed for government projects B Exclusions prevent scope creep by explicitly documenting what stakeholders might reasonably assume is included but is NOT — eliminating ambiguity about boundaries and reducing future disputes about what was 'obviously' part of the project C Exclusions are indeed unnecessary padding D Exclusions weaken the project by highlighting gaps

42 / 150

Question 43 of 150

The scope statement documents 'assumptions.' An assumption states: 'The vendor will deliver hardware by March 15.' This assumption proves false — hardware arrives June 1. What should the PM have done with this assumption?

A Changed the assumption to a later date preemptively B Logged it in the assumption log, assessed its probability of failure, developed a contingency plan, and monitored it as a risk — because assumptions that prove false can significantly impact the project scope, schedule, and cost C Assumptions are always true if documented by the sponsor D Assumptions do not need to be tracked once documented

43 / 150

Question 44 of 150

The scope statement includes 'constraints.' A constraint states: 'The project must be completed within 12 months.' How does this constraint affect scope management?

A Constraints only affect the budget, not scope B Constraints have no impact on scope decisions C Constraints can be ignored if the team works overtime D Time constraints force scope trade-offs — if the full scope cannot be delivered in 12 months, the PM must negotiate scope reduction, phased delivery, or additional resources; the constraint bounds what is achievable

44 / 150

Question 45 of 150

The scope statement contains 'acceptance criteria' for major deliverables. A deliverable's acceptance criteria states: 'The system must support 500 concurrent users.' During scope validation, the system supports 480 concurrent users. What should happen?

A The deliverable does not meet the documented acceptance criteria and should not be formally accepted — the PM should document the gap, assess options (fix, waive, or negotiate), and follow the agreed acceptance process B Accept the deliverable since 480 is close enough to 500 C Change the acceptance criteria retroactively to 480 D Automatically reject the project as a whole

45 / 150

Question 46 of 150

What is the relationship between the project scope statement and the WBS?

A The WBS replaces the scope statement B They are the same document C The scope statement is created after the WBS D The project scope statement describes WHAT the project will deliver in narrative form; the WBS decomposes that narrative scope into a hierarchical structure of manageable components — the WBS is built FROM the scope statement

46 / 150

Question 47 of 150

A stakeholder reviews the scope statement and says: 'This reads like a wish list. How do I know what is actually committed versus aspirational?' What element of the scope statement addresses this concern?

A The scope statement is always aspirational B Acceptance criteria and the scope baseline formalization process — once the scope statement is baselined through formal approval, its contents become committed scope against which the project is measured C All items in the scope statement are automatically committed D The project title clarifies commitment level

47 / 150

Question 48 of 150

A PM is creating the scope statement for a project with both predictive and agile components (hybrid approach). How should the scope statement accommodate this?

A Document the predictive components with detailed deliverables and acceptance criteria, while describing the agile components at a higher level with product vision, initial epics, and the adaptive approach for requirements elaboration during iterations B Agile components cannot appear in a scope statement C Create two separate scope statements D Treat all components as predictive for the scope statement

48 / 150

Question 49 of 150

The scope statement for a software project includes the deliverable 'User Training.' A team member argues training is not part of the product and should be excluded from scope. Is training a valid scope element?

A Training should be in a separate project B Training should always be excluded from project scope C Training is a valid project deliverable if stakeholders and the business case identify it as necessary for value realization — the scope statement should include ALL work the project must deliver, not just the product itself D Training is only valid for external-facing projects

49 / 150

Question 50 of 150

A PM discovers that the scope statement uses the phrase 'and other similar features' in describing a deliverable. Why is this problematic?

A Open-ended phrases create unbounded scope — 'other similar features' can be interpreted to include virtually anything, making it impossible to determine when the deliverable is complete and opening the door to unlimited scope creep B This phrasing is standard and acceptable C Only legal projects need precise language D It adds helpful flexibility to the scope

50 / 150

Question 51 of 150

During scope definition, the PM identifies a significant gap between what stakeholders want and what the budget can support. The desired scope costs $2M, but the budget is $1.2M. What should the PM do?

A Accept the scope gap and deliver what the budget allows without stakeholder input B Facilitate a scope prioritization exercise with stakeholders to determine which deliverables are essential within the $1.2M constraint, potentially deferring lower-priority items to a future phase C Reduce quality standards to fit everything within budget D Commit to the full $2M scope and hope for additional funding

51 / 150

Question 52 of 150

A PM finalizes the scope statement and obtains formal approval from the sponsor and key stakeholders. Two weeks later, a senior stakeholder who was not involved in scope definition demands the addition of a major feature. What should the PM do?

A Acknowledge the request, explain that the scope has been baselined, and route the request through the formal change control process for impact analysis and governance decision B Add the feature but do not update the scope statement C Reject the request since the scope is finalized D Add the feature to accommodate the senior stakeholder

52 / 150

Question 53 of 150

The scope statement for a construction project does not include a 'product scope description.' A stakeholder asks why this is important. What should the PM explain?

A Product scope description is optional in scope statements B Product scope is only for software projects C The project charter already covers product scope D The product scope description details the characteristics, features, and functions of the deliverable — without it, the team does not know WHAT they are building, only that they are building something; it is the foundation for all other scope elements

53 / 150

Question 54 of 150

A PM reviews a scope statement that lists 15 assumptions but zero constraints. The PM suspects the constraints section was overlooked. What common project constraints should the PM investigate?

A Projects rarely have constraints B Constraints are the same as assumptions C Only external constraints need to be documented D Budget limitations, schedule deadlines, regulatory requirements, technology standards, resource availability, organizational policies, contractual obligations, and environmental or physical limitations — virtually all projects have constraints that bound scope decisions

54 / 150

Question 55 of 150

A PM is asked to explain how the scope statement differs from the project charter's scope description. What is the KEY difference?

A The charter is more detailed than the scope statement B They contain identical information C The scope statement is created before the charter D The charter provides a HIGH-LEVEL scope summary to authorize the project; the scope statement provides DETAILED scope definition including specific deliverables, acceptance criteria, exclusions, constraints, and assumptions — it is much more granular

55 / 150

Question 56 of 150

What is the WBS and what does it represent?

A A list of project activities in chronological order B The organizational chart for the project C A hierarchical decomposition of the total scope of work to be carried out by the project team — organized by deliverables, it represents ALL the work required to accomplish the project objectives D A risk breakdown structure

56 / 150

Question 57 of 150

A PM presents the WBS to stakeholders. A stakeholder asks: 'Where are the project management activities?' Should project management activities appear in the WBS?

A Project management work should never appear in the WBS B Yes — project management is legitimate project work (planning, monitoring, reporting, meetings) and should be included in the WBS, often as a separate branch, so that the management effort is estimated, budgeted, and tracked C Project management activities only appear in the schedule D Only administrative assistants track project management work

57 / 150

Question 58 of 150

What is the WBS Dictionary and why is it essential?

A A document that provides detailed descriptions for each WBS element — including scope of work, deliverables, acceptance criteria, responsible organization, schedule milestones, cost estimates, and references — ensuring everyone interprets WBS elements consistently B A separate copy of the WBS in text format C A dictionary provided to new team members during onboarding D A glossary of project management terms

58 / 150

Question 59 of 150

The WBS Dictionary entry for work package '3.2.1 — Database Design' should contain which of the following information?

A A complete design document B Only the assigned team member's name C Scope description, deliverables, acceptance criteria, responsible person/organization, estimated cost, schedule information, resource requirements, quality requirements, and any technical references or constraints specific to this work package D Only the work package name and number

59 / 150

Question 60 of 150

A team creates a WBS where work package '2.3 — Testing' appears under both the 'Development Phase' and the 'Quality Phase' branches. What WBS principle does this violate?

A No principle is violated; duplication ensures thoroughness B The 100% rule C The 8/80 rule D The mutual exclusivity principle — each work package should appear only once in the WBS to prevent double-counting of scope, cost, and effort

60 / 150

Question 61 of 150

A PM uses the WBS to create a 'control account.' What is a control account and how does it relate to the WBS?

A A management control point in the WBS where scope, schedule, and cost are integrated and measured — it represents the point where earned value is calculated and where performance is formally tracked against the plan B The top level of the WBS C A work package with a budget over $100,000 D A financial bank account for the project

61 / 150

Question 62 of 150

The scope baseline consists of three elements. What are they?

A The project management plan, scope statement, and charter B The schedule baseline, cost baseline, and quality baseline C The project charter, stakeholder register, and risk register D The project scope statement, the WBS, and the WBS Dictionary — together they define the approved project scope against which all scope changes are measured

62 / 150

Question 63 of 150

A team creates a WBS using a top-down approach. An alternative is the bottom-up approach. When is the bottom-up approach MORE appropriate?

A When the team has detailed knowledge of specific deliverables but lacks clarity on the overall structure — they brainstorm all known deliverables first, then organize them into a hierarchy, letting the structure emerge from the details B Top-down and bottom-up always produce identical results C Bottom-up is never appropriate for WBS creation D Bottom-up is only for agile projects

63 / 150

Question 64 of 150

A PM decides to use an organizational WBS template from a previous similar project. What is the advantage and risk of using templates?

A Templates should never be used; each WBS must be unique B Templates accelerate WBS creation and capture organizational learning, but they risk carrying forward irrelevant elements or missing unique requirements of the current project — the PM must customize the template to fit the specific project scope C Templates are only available for IT projects D Templates eliminate the need for team input in WBS creation

64 / 150

Question 65 of 150

A PM assigns responsibility for WBS work packages using a Responsibility Assignment Matrix (RAM). The most common form is the RACI chart. What do the letters RACI represent?

A Request, Authorize, Complete, Invoice B Review, Approve, Consult, Inform C Required, Assigned, Completed, Inspected D Responsible (does the work), Accountable (owns the outcome and has final authority), Consulted (provides input before the work), Informed (notified after the work or decisions)

65 / 150

Question 66 of 150

A team creates a WBS but does not create a WBS Dictionary, arguing that the WBS itself is sufficient. What risks does this create?

A The WBS Dictionary is only needed for government contracts B Without the dictionary, work package boundaries are ambiguous — team members may interpret scope differently, leading to gaps (undone work), overlaps (duplicate work), and disputes about what is included in each element C No risk; the WBS Dictionary is optional D The dictionary can be created at project closure

66 / 150

Question 67 of 150

A PM needs to estimate the cost and duration of the project. Why is the WBS considered the FOUNDATION of project planning?

A All other planning activities build on the WBS: schedule development decomposes work packages into activities, cost estimation aggregates from work packages to the project level, risk identification examines each WBS element, and resource planning assigns staff to work packages B The project charter is the foundation of all planning C The WBS is useful but not foundational to planning D The WBS only affects scope planning, not other knowledge areas

67 / 150

Question 68 of 150

During WBS creation, the team identifies work that falls outside the approved scope statement but would add value. This is known as 'gold plating.' What should the PM do?

A Include it but do not estimate the cost B Exclude it from the WBS — gold plating adds unauthorized scope beyond requirements, increasing cost and risk without approved justification; if the team believes the work adds value, they should submit it as a change request C Gold plating is encouraged in PMBOK 7 D Include it since it adds value

68 / 150

Question 69 of 150

A WBS element is labeled 'Miscellaneous' to capture various small tasks that do not fit elsewhere. Why is this problematic?

A Miscellaneous categories are standard WBS practice B Only one 'Miscellaneous' category is allowed C A 'Miscellaneous' category violates the principle that all WBS elements should be clearly defined deliverables — it becomes a dumping ground for poorly understood work, making estimation unreliable and accountability unclear D Small tasks do not need to be in the WBS

69 / 150

Question 70 of 150

A PM is creating a WBS for a large program with 5 sub-projects. Should the program have one integrated WBS or separate WBS documents for each sub-project?

A Typically each sub-project has its own WBS, with a program-level WBS showing how they integrate — this enables each sub-project team to manage their own scope while the program manager tracks cross-project integration and dependencies B Always one integrated WBS regardless of program size C Programs do not use the WBS concept D Only the largest sub-project needs a WBS

70 / 150

Question 71 of 150

After WBS creation, the PM conducts a 'WBS review workshop' with the team and key stakeholders. What is the PRIMARY objective of this review?

A To assign resources to each work package B To verify that the WBS is complete (100% rule), accurately represents the scope, contains no duplicate or out-of-scope elements, and that all participants agree the WBS captures what needs to be delivered C To calculate the project budget D To finalize the project schedule

71 / 150

Question 72 of 150

A PM creates a WBS for a construction project. The Level 1 elements are: 1.0 Site Preparation, 2.0 Foundation, 3.0 Structure, 4.0 Electrical, 5.0 Plumbing, 6.0 Finishing, 7.0 Project Management. A stakeholder asks why 7.0 is included. What is the PM's justification?

A Project management activities (planning, coordination, reporting, inspections, meetings, closeout) are real work consuming real resources and must be in the WBS to ensure they are planned, budgeted, and tracked alongside technical deliverables B Only large projects include project management in the WBS C Project management should not be in the WBS D It is included only for billing purposes

72 / 150

Question 73 of 150

A work package in the WBS Dictionary has no assigned acceptance criteria. The team argues that acceptance criteria will be defined during testing. What risk does this create?

A Acceptance criteria are only needed for the final project deliverable B Testing automatically defines acceptance criteria C No risk; acceptance criteria can be defined anytime D Without predefined acceptance criteria, the team and stakeholders may disagree on what constitutes 'done' — leading to rework, scope disputes, and failed deliverable acceptance at validation time

73 / 150

Question 74 of 150

A PM notices that the WBS has been created but the WBS Dictionary entries are inconsistent — some entries are detailed while others contain only a single sentence. What should the PM do?

A Delete the less detailed entries B Inconsistency is acceptable for different types of work C Only high-risk work packages need detailed dictionary entries D Standardize the WBS Dictionary entries using a template that ensures each work package has the same minimum required information: scope description, deliverables, acceptance criteria, responsible party, and estimates

74 / 150

Question 75 of 150

During project execution, the PM needs to add a new deliverable to the WBS that was not in the original scope. What process must be followed?

A New elements can be added to the WBS without change control B Add it directly to the WBS since the PM has authority over the WBS C Submit a change request through integrated change control — adding a WBS element changes the scope baseline, which requires formal approval from the change control board before the WBS, schedule, and budget are updated D Add it but do not change the budget

75 / 150

Question 76 of 150

A PM detects that team members are adding small enhancements to deliverables without change requests. Individual additions are minor, but collectively they have added 2 weeks to the schedule. What is this phenomenon called?

A Value engineering B Adaptive planning C Scope creep — the uncontrolled expansion of scope without corresponding adjustments to time, cost, and resources, typically through a series of small, unapproved changes that accumulate significantly D Progressive elaboration

76 / 150

Question 77 of 150

Scope validation (Validate Scope) and quality control (Control Quality) both involve checking deliverables. What is the KEY difference between them?

A Quality control verifies that the deliverable meets QUALITY STANDARDS (is it built right?); scope validation verifies that the deliverable meets SCOPE REQUIREMENTS with formal stakeholder acceptance (did we build the right thing?) B Quality control replaces scope validation C Scope validation occurs before quality control D They are the same process with different names

77 / 150

Question 78 of 150

During scope validation, a stakeholder inspects a deliverable and identifies defects. Should the PM record these as scope changes?

A Defects found during validation are typically rework items, not scope changes — they represent failure to meet existing requirements, not new requirements; they should be routed back to quality control for correction B Defects are ignored during scope validation C Defects automatically invalidate the entire deliverable D Yes, all defect fixes require change requests

78 / 150

Question 79 of 150

A PM uses variance analysis as part of scope control. What does scope variance analysis involve?

A Comparing actual costs to budgeted costs B Analyzing team performance ratings C Comparing the actual scope deliverables and work completed against the scope baseline to identify deviations — determining if scope has grown, shrunk, or shifted from the approved plan D Comparing the project to competitor projects

79 / 150

Question 80 of 150

The integrated change control process is the PRIMARY mechanism for scope control. What are the KEY steps in evaluating a scope change request?

A The PM decides all change requests independently B Approve all requests from the sponsor C Only schedule impacts need to be assessed D Document the request, assess impact on scope/schedule/cost/quality/risk/resources, present the analysis to the change control board, obtain approval or rejection, and update all affected baselines and plans if approved

80 / 150

Question 81 of 150

A PM discovers that a deliverable was completed but was never formally accepted by the stakeholder through scope validation. The project is now in the closing phase. What risk does this create?

A Formal acceptance is only needed for external clients B No risk if the deliverable was completed successfully C The PM can sign acceptance on behalf of the stakeholder D Without formal acceptance, the stakeholder may dispute the deliverable's completeness or quality during closing, creating last-minute conflicts that delay project closure and may require rework

81 / 150

Question 82 of 150

A stakeholder submits a change request that the PM believes will reduce the project's value rather than enhance it. The PM's analysis shows the change adds cost and schedule risk without meaningful benefit. What should the PM do?

A Implement the change since the stakeholder requested it B Reject the change without CCB involvement C Present the objective impact analysis to the change control board with a recommendation against the change, while respecting the stakeholder's right to have their request formally evaluated through governance D Ignore the change request

82 / 150

Question 83 of 150

A project has a formal change control process, but team members frequently implement minor changes informally because 'the process is too slow for small changes.' What should the PM do?

A Accept informal changes for minor items B Report team members for non-compliance C Create a tiered change process: a lightweight fast-track for small changes below a defined threshold (cost, schedule, risk impact) with PM approval authority, and a full CCB process for larger changes — maintaining governance while enabling agility D Eliminate the change control process entirely

83 / 150

Question 84 of 150

During scope control, the PM identifies 'scope creep' caused by a team lead who agreed to stakeholder requests without change control. How should the PM address both the immediate and systemic issues?

A Discipline the team lead and remove them from the project B Accept the changes since they are already implemented C Only address the immediate scope additions D Immediately: assess the impact of unauthorized changes and either formalize them through retroactive change requests or roll them back. Systemically: re-educate the team on change control, clarify authority boundaries, and reinforce that all scope changes must follow the process

84 / 150

Question 85 of 150

A project's scope baseline was approved 6 months ago. Since then, 15 change requests have been approved, each modifying the WBS and scope statement. What should the PM maintain to ensure scope clarity?

A Only the most recent change request matters B A verbal understanding of current scope is sufficient C Only the original baseline matters D An updated, current scope baseline that reflects all approved changes — maintaining both the original baseline (for historical comparison) and the current baseline (for ongoing management and control)

85 / 150

Question 86 of 150

A PM performs 'trend analysis' as part of scope control and notices that the rate of change requests has doubled in the last 3 months. What does this trend signal?

A Increasing change requests may indicate: evolving stakeholder understanding (scope was insufficiently defined initially), changing business conditions, requirements instability, or inadequate stakeholder engagement during scope definition — root cause investigation is needed B The PM should limit the number of change requests allowed C The change process is working efficiently D Higher change request volume is always positive

86 / 150

Question 87 of 150

Scope validation requires formal acceptance of completed deliverables. In an agile project with bi-weekly sprint deliveries, how does scope validation adapt?

A The sprint review serves as the scope validation event — the product owner and stakeholders inspect the increment, provide feedback, and formally accept or request changes to the delivered functionality each sprint B Agile projects do not perform scope validation C Scope validation only occurs at the end of the agile project D The Scrum Master validates scope on behalf of stakeholders

87 / 150

Question 88 of 150

A PM is controlling scope on a fixed-price contract. The client requests additional features beyond the contracted scope. The PM's team wants to accommodate the client for relationship reasons. What should the PM do?

A Route the request through formal change control — additional scope beyond the contract requires a contract amendment with associated cost, schedule, and terms adjustments; providing free work sets a dangerous precedent and erodes project margins B Add the features and bill the client without prior agreement C Refuse the request without discussion D Add the features for free to maintain the relationship

88 / 150

Question 89 of 150

At project closure, the PM compares the original scope baseline to the final delivered scope. The delivered scope includes 120% of the original planned scope. What does this indicate?

A The original scope was too small B 20% growth is within normal tolerance C The project over-delivered and should be celebrated D The project experienced 20% scope growth — the PM should analyze whether this was through approved changes (managed growth) or unauthorized additions (scope creep), and document lessons learned about scope control effectiveness

89 / 150

Question 90 of 150

A PM uses earned value management (EVM) as part of scope control. The project shows SPI = 0.85 and CPI = 0.90. What does this suggest about scope control?

A EVM does not relate to scope control B The project is ahead of schedule and under budget C Both values above 0.80 are acceptable D The project is behind schedule (SPI < 1.0 means only 85% of planned scope is being delivered on time) and over budget (CPI < 1.0 means spending more than planned for the scope delivered) — corrective scope control actions are needed

90 / 150

Question 91 of 150

What is the standard format for writing a user story?

A The system shall [function] when [condition] B As a [system], I want [feature], so that [technical requirement] C Given [condition], When [action], Then [result] D As a [type of user/role], I want [goal/desire], so that [benefit/value] — this format ensures every story captures who needs it, what they need, and why it matters

91 / 150

Question 92 of 150

A product owner writes: 'As a user, I want the system to be fast.' The development team says this story is not ready for sprint planning. What quality criterion does it violate?

A Only the development team can judge story quality B User stories do not need to be specific C It violates the 'Specific' and 'Testable' criteria — 'fast' is subjective and unmeasurable; the story should specify a measurable performance target like 'page loads in under 2 seconds on standard broadband' D It violates the 'Independent' criterion

92 / 150

Question 93 of 150

The INVEST acronym defines quality criteria for user stories. What does each letter represent?

A Inventoried, Named, Versioned, Evaluated, Stored, Tagged B Independent (minimal dependencies), Negotiable (details can be discussed), Valuable (delivers user value), Estimable (team can size it), Small (fits in a sprint), Testable (acceptance criteria can verify it) C Immediate, Necessary, Verified, Estimated, Scheduled, Tracked D Integrated, Normalized, Validated, Executed, Secured, Terminated

93 / 150

Question 94 of 150

Acceptance criteria for a user story are written in the Given-When-Then format. For the story 'As a customer, I want to reset my password, so that I can regain account access,' what is an appropriate acceptance criterion?

A The password reset feature should work properly B The system resets passwords C Users can reset passwords D Given the customer clicks 'Forgot Password' and enters their registered email, When they click 'Submit,' Then a password reset link is sent to their email within 60 seconds and expires after 24 hours

94 / 150

Question 95 of 150

A user story is too large to complete in a single sprint. The team estimates it at 40 story points, but their sprint velocity is 25 points. What should the team do?

A Extend the sprint to accommodate the large story B Carry the story across multiple sprints without splitting C Assign more developers to the story D Split the story into smaller, independently valuable stories that each fit within a sprint — for example, splitting by user workflow steps, data types, business rules, or interface elements

95 / 150

Question 96 of 150

A development team is writing acceptance criteria for user stories. The product owner provides only one acceptance criterion per story. A team member argues more are needed. What is the BEST guidance?

A Acceptance criteria are optional for user stories B One criterion per story is sufficient C Most stories need multiple acceptance criteria covering: the happy path (normal flow), edge cases (boundary conditions), error handling (what happens when things go wrong), and non-functional aspects (performance, security) relevant to the story D The team should write criteria without the product owner

96 / 150

Question 97 of 150

An epic is defined as 'Implement Customer Loyalty Program.' The product owner needs to decompose it into user stories. What decomposition approach is MOST effective?

A Create stories based on technical components only B The development team decomposes epics, not the product owner C Decompose by user journey: 'As a customer, I want to enroll in the loyalty program,' 'As a customer, I want to earn points on purchases,' 'As a customer, I want to redeem points for rewards,' etc. — each story represents a distinct, valuable capability D Create one large story for the entire loyalty program

97 / 150

Question 98 of 150

A stakeholder insists that user stories must include detailed technical specifications. The Scrum Master disagrees. What is the correct level of technical detail in a user story?

A User stories describe WHAT the user needs and WHY, not HOW it is implemented — technical decisions are made by the development team during sprint planning and implementation; the story focuses on the user's need and acceptance criteria B Only senior developers decide story content C Stories should contain no technical information at all D Full technical specifications are required in every story

98 / 150

Question 99 of 150

A PM on a hybrid project needs to bridge user stories (agile) with WBS work packages (predictive). How can these be connected?

A Only use user stories for the agile components B User stories can be mapped to WBS work packages through the requirements traceability matrix — epics align with higher WBS elements, and individual stories map to work packages, enabling both agile delivery and predictive scope tracking C User stories and WBS are incompatible and cannot coexist D Replace the WBS entirely with user stories

99 / 150

Question 100 of 150

A product owner consistently writes user stories from a single user persona (the customer). The development team notes that the system also serves administrators, support agents, and integration partners. What should the Scrum Master advise?

A Only the highest-revenue persona needs stories B User stories should represent ALL user personas — each persona has distinct needs, workflows, and acceptance criteria; neglecting non-customer personas results in an incomplete product that serves only part of its intended audience C Technical users do not need user stories D Customer stories are the only ones that matter

100 / 150

Question 101 of 150

A development team uses 'story mapping' to organize user stories visually. What does a story map show?

A The project's network diagram B A two-dimensional layout with user activities along the horizontal axis (the user's journey) and story details arranged vertically by priority, showing the full user experience and enabling release planning by drawing horizontal lines across priority levels C A geographic map of where users are located D A map of the development team's office locations

101 / 150

Question 102 of 150

A product owner writes stories with acceptance criteria but the team still produces different interpretations during development. What additional technique can help ensure shared understanding?

A 'Three Amigos' sessions — collaborative discussions between the product owner, developer, and tester before development starts, exploring examples, edge cases, and clarifying intent through conversation rather than relying solely on written criteria B More detailed written documentation C Eliminate acceptance criteria and let the team decide D Assign one person to interpret all stories

102 / 150

Question 103 of 150

A user story reads: 'As an admin, I want to manage users.' This story is too vague. How should it be refined?

A Split it into specific, actionable stories: 'As an admin, I want to create new user accounts,' 'As an admin, I want to deactivate user accounts,' 'As an admin, I want to reset user passwords,' 'As an admin, I want to assign user roles' — each with its own acceptance criteria B Add more technical details to the same story C Leave it vague so the team has flexibility D Add 'quickly and easily' to make it more descriptive

103 / 150

Question 104 of 150

A team debates whether non-functional requirements (security, performance, accessibility) should be written as user stories. What is the BEST approach?

A Non-functional requirements are only addressed in testing B Non-functional requirements cannot be expressed as stories C Non-functional requirements should be in a separate document only D Some non-functional requirements fit the story format ('As a user, I want the page to load in under 2 seconds so that I do not lose interest'); others are better expressed as constraints on the Definition of Done that apply to ALL stories

104 / 150

Question 105 of 150

A product owner asks the team to estimate a user story, but the team says they cannot estimate it because they do not understand the domain. What technique should the team use to gain understanding before estimating?

A Create a 'spike' — a time-boxed investigation or prototype to explore the unknown domain, technology, or approach; the spike's output provides the knowledge needed to write and estimate the actual story B Remove the story from the backlog C Ask the product owner to estimate for them D Estimate anyway and adjust later

105 / 150

Question 106 of 150

What is the product backlog and who owns it?

A A technical debt register owned by the Scrum Master B A list of completed features owned by the development team C An ordered list of everything that might be needed in the product, owned by the product owner — it is the single source of requirements and is continuously refined, reprioritized, and updated throughout the project D A fixed scope document owned by the project sponsor

106 / 150

Question 107 of 150

A product backlog contains 200 items. The product owner has detailed acceptance criteria for the top 20 items but only brief descriptions for the rest. Is this acceptable?

A No items need acceptance criteria until sprint planning B Yes — backlog refinement follows a 'just enough, just in time' principle; items near the top (upcoming sprints) should be well-defined, while items further down only need enough detail to understand their relative priority C No, all 200 items must have the same level of detail D Only the top 5 items need detail

107 / 150

Question 108 of 150

A product owner uses MoSCoW prioritization for the product backlog. What do the letters represent?

A Managed, Scheduled, Completed, Overdue, Withdrawn B Monday, Saturday, Collaboration, Overtime, Wednesday C Must have (essential for this release), Should have (important but not critical), Could have (desirable if time permits), and Won't have this time (explicitly deferred) — providing clear priority categories for scope decisions D Maximum, Standard, Conditional, Optional, Withheld

108 / 150

Question 109 of 150

A stakeholder asks the product owner to add 10 new items to the product backlog. The backlog already has 150 items and the team completes about 15 items per sprint. The product owner adds all 10 without removing or deprioritizing anything. What risk does this create?

A The team should increase velocity to handle the growth B An ever-growing backlog creates the illusion that all items will be delivered, leading to stakeholder disappointment; the product owner should balance additions with removals or explicit deferral of lower-priority items C 150 items is too few for a healthy backlog D No risk; more backlog items mean more options

109 / 150

Question 110 of 150

What is 'backlog refinement' (also called backlog grooming) and how much time should the team allocate to it?

A An ongoing activity where the product owner and team add detail, estimate, and reorder backlog items — Scrum recommends the team spend up to 10% of sprint capacity on refinement to ensure upcoming items are ready for sprint planning B An activity performed only by the product owner alone C A one-time activity at project initiation D A formal meeting that replaces sprint planning

110 / 150

Question 111 of 150

A product owner orders the backlog strictly by business value. A senior developer argues that some high-value items depend on low-value infrastructure work. How should the backlog be reordered?

A Ignore dependencies and let the team figure it out during the sprint B Consider both value AND dependencies — some enabling work (infrastructure, architecture) must be done first to unlock high-value features; the product owner should sequence the backlog to maximize value delivery while respecting technical dependencies C Always follow strict business value ordering D Let the development team order the backlog

111 / 150

Question 112 of 150

A product owner uses 'value vs effort' mapping (a 2x2 matrix) to prioritize backlog items. Where should the team start?

A High effort, low value items first B High effort, high value items to tackle the hardest work first C Low value, low effort items for easy completion D High value, low effort items first — these 'quick wins' deliver maximum value with minimum investment, building momentum and stakeholder confidence early

112 / 150

Question 113 of 150

The product backlog for a large product is shared across 3 Scrum teams. How should this be managed?

A Maintain one product backlog with a single product owner who determines priority and allocates work across teams, ensuring consistency, avoiding duplication, and managing cross-team dependencies B Each team maintains its own independent backlog C The three backlogs are merged at the end of each sprint D Only one team should work on the product

113 / 150

Question 114 of 150

A product owner receives 5 change requests from different stakeholders for the same sprint. How should these be handled in the context of the product backlog?

A Add all requests to the product backlog, prioritize them against existing items, and include them in a future sprint based on their relative priority — the current sprint's scope is protected unless the product owner negotiates a scope swap with the team B Reject all change requests during active sprints C Let the development team decide which requests to implement D Add all 5 to the current sprint immediately

114 / 150

Question 115 of 150

A product backlog has not been refined in 3 sprints. The team arrives at sprint planning and discovers that the top backlog items lack acceptance criteria, are too large for a sprint, and have unresolved dependencies. What is the consequence?

A The team should skip sprint planning and start working B The Scrum Master should refine the backlog during sprint planning C Sprint planning will fail or be highly inefficient — the team cannot commit to work they do not understand, cannot estimate, and cannot complete in a sprint; this unrefined backlog wastes the sprint planning session and may result in an uncommitted or undersized sprint D Sprint planning will proceed normally

115 / 150

Question 116 of 150

A team uses relative estimation (story points) for backlog items. A new team member asks why the team does not estimate in hours. What is the PRIMARY advantage of relative estimation over absolute estimation?

A Relative estimation is faster and more consistent — humans compare sizes more reliably than they predict absolute duration; story points account for complexity, effort, and uncertainty without false precision, and they normalize across team members with different skill levels B Story points eliminate the need for sprint planning C Story points are always more accurate than hours D Relative estimation is required by Scrum

116 / 150

Question 117 of 150

A product owner wants to track how much of the product backlog has been completed versus what remains. What artifact best visualizes this?

A A risk register B A Gantt chart showing task assignments C A product burndown chart (or release burnup chart) that plots total remaining work against time, showing whether the team is on track to deliver the target scope by the planned release date D A RACI matrix

117 / 150

Question 118 of 150

A product backlog contains both functional requirements (features) and non-functional requirements (performance, security). How should non-functional requirements be represented in the backlog?

A Non-functional requirements can be represented as standalone stories, acceptance criteria on functional stories, or as part of the Definition of Done — the approach depends on whether they apply to specific features or the entire product B The architect handles non-functional requirements outside the backlog C Non-functional requirements should be in a separate document, not the backlog D Non-functional requirements are only addressed during testing

118 / 150

Question 119 of 150

A team finishes a sprint but 3 of 8 committed stories are incomplete. The product owner asks what happens to these unfinished stories. What is the correct approach?

A Carry them over automatically to the next sprint B Extend the sprint until the stories are completed C Return the incomplete stories to the product backlog for reprioritization by the product owner — they are not automatically included in the next sprint; the product owner re-evaluates their priority relative to all other backlog items D Mark them as done since the sprint is over

119 / 150

Question 120 of 150

A product owner uses the WSJF (Weighted Shortest Job First) technique to order the backlog. How is WSJF calculated?

A WSJF = Effort divided by Team Size B WSJF = Business Value multiplied by Risk C WSJF = Cost of Delay minus Job Duration D WSJF = Cost of Delay divided by Job Duration (or size) — items with the highest ratio are scheduled first because they deliver the most value per unit of time invested, optimizing economic throughput

120 / 150

Question 121 of 150

What is the Definition of Done (DoD) in agile and who creates it?

A A project completion checklist created by the sponsor B A list of features the product owner wants completed C A testing protocol created by the QA department D A shared, transparent checklist of quality criteria that every increment must satisfy before it can be considered complete — the team creates and owns it (in Scrum, the developers), though organizational standards may set a minimum baseline

121 / 150

Question 122 of 150

A team's Definition of Done includes: code reviewed, unit tests passing, integration tests passing, documentation updated, and deployed to staging. A developer marks a story as done but skips documentation because 'it was a minor change.' What should happen?

A Accept the story since it was minor B Let the product owner decide whether to waive the requirement C Update the DoD to remove documentation D The story is NOT done — every item in the DoD must be satisfied regardless of story size; allowing exceptions erodes the DoD's integrity and creates technical debt; the story should be returned to In Progress

122 / 150

Question 123 of 150

A newly formed Scrum team is creating their first Definition of Done. They want to include 'all code deployed to production' but the organization requires a separate change approval board review before production deployment. How should the team handle this?

A Set the DoD to the highest achievable quality gate within their authority — 'deployed to staging and change request submitted for production' — and work over time to expand their DoD as organizational trust grows and processes evolve B Include it anyway and bypass the change approval board C Do not create a DoD until the organization removes the approval board D Let the change approval board define the team's DoD

123 / 150

Question 124 of 150

How does the Definition of Done differ from acceptance criteria?

A Acceptance criteria are specific to individual user stories (unique conditions that must be true for THAT story), while the DoD applies universally to ALL stories and increments — acceptance criteria define WHAT is correct, DoD defines WHEN work is truly complete B The DoD only applies to the final release, not individual stories C They are the same thing D Acceptance criteria replace the DoD in agile

124 / 150

Question 125 of 150

A team has been using the same Definition of Done for 6 months. During a retrospective, a developer notes that their testing practices have matured significantly and they can now add performance testing to every story. What should the team do?

A Add performance testing only for critical stories B Evolve the DoD to include performance testing — the DoD should be regularly reviewed and strengthened as the team matures, processes improve, and new quality practices become sustainable C Keep the DoD unchanged for consistency D Wait for management to mandate the change

125 / 150

Question 126 of 150

Three Scrum teams work on the same product. Each team has a different Definition of Done. What problem does this create?

A Only the fastest team's DoD matters B Different DoDs increase healthy competition between teams C No problem; each team knows their work best D Inconsistent quality across the integrated product — when teams have different standards, combining their increments creates integration risk; a shared minimum DoD across all teams ensures every component meets the same quality bar

126 / 150

Question 127 of 150

A product owner pressures the team to mark a story as done even though automated tests are failing because the release deadline is tomorrow. The PM agrees with the product owner. What should the team do?

A Mark it done but log a bug to fix tests later B Mark it as done to meet the deadline C Refuse to compromise the DoD — the team is accountable for quality and the DoD represents their professional commitment; they should explain the risks of releasing untested code and offer alternatives such as reducing scope while maintaining quality D Remove automated testing from the DoD retroactively

127 / 150

Question 128 of 150

A team's sprint produces an increment that meets all acceptance criteria for each story but does NOT meet the Definition of Done because code review was skipped. Is the increment potentially releasable?

A Yes, code review is optional if tests pass B The product owner decides whether it is releasable C Yes, acceptance criteria satisfaction is sufficient D No — an increment is only potentially releasable when it satisfies BOTH the acceptance criteria for each story AND the Definition of Done; skipping code review means the quality standard has not been met, regardless of functional correctness

128 / 150

Question 129 of 150

A team includes 'no critical or high-severity bugs' in their Definition of Done. During the sprint, they discover 2 high-severity bugs in a completed story. According to their DoD, what should happen?

A Ship anyway and fix bugs in the next sprint B Lower the bug severity classification so they are not high C The story reverts to not done — the team must fix the high-severity bugs before the story can satisfy the DoD; this is the DoD working as designed, preventing known defects from reaching users D Add the bugs to the product backlog as separate items

129 / 150

Question 130 of 150

A team transitioning from waterfall to agile creates an initial DoD that only includes 'code compiles and basic unit tests pass.' Their Scrum Master suggests this is too minimal. What is the Scrum Master's reasoning?

A The Scrum Master should define the DoD, not the team B Scrum requires a standardized DoD across all organizations C A minimal DoD creates a large amount of undone work that accumulates as hidden technical debt — each sprint appears to deliver value, but significant work (integration testing, documentation, security hardening) remains before the product is truly releasable D The DoD must include at least 20 items to be valid

130 / 150

Question 131 of 150

During sprint review, a stakeholder asks how they can trust that the demonstrated increment is truly complete. What artifact provides this transparency?

A The project charter B The Definition of Done — it is a transparent, shared document that everyone (team, product owner, stakeholders) can reference to understand exactly what standards each increment has met, providing confidence in the quality and completeness of delivered work C The sprint burndown chart D The team's velocity history

131 / 150

Question 132 of 150

A team's DoD includes 'documentation updated.' A developer argues that in agile, documentation is unnecessary because 'working software over comprehensive documentation.' How should the Scrum Master respond?

A Documentation should only be done at project end B The Agile Manifesto values working software MORE than comprehensive documentation but does not eliminate documentation — the DoD should include documentation that enables sustainable development, knowledge sharing, and user adoption; the team decides what level is appropriate C Only the product owner documents features D Remove documentation from the DoD since agile discourages it

132 / 150

Question 133 of 150

A team working on a safety-critical medical device has a DoD that includes regulatory compliance checks. Can the team remove this item from the DoD to increase velocity?

A Yes, if the product owner approves B The Scrum Master can waive regulatory requirements C Yes, regulatory checks can be done at the end of the project D No — regulatory and safety requirements are non-negotiable; the organizational or industry standards form a minimum DoD that the team cannot weaken; velocity gained by skipping safety checks is illusory and creates catastrophic risk

133 / 150

Question 134 of 150

A team has a DoD item: 'code passes static analysis with zero critical findings.' After adopting a new static analysis tool, every story fails because the tool detects legacy issues in unchanged code. What should the team do?

A Turn off the new tool and revert to the old one B Adjust the DoD to 'no new critical findings introduced by this story's changes' while creating a separate backlog item to address legacy findings — this prevents the new tool from blocking all progress while still preventing new technical debt C Ignore all static analysis findings until the legacy code is fixed D Abandon static analysis entirely

134 / 150

Question 135 of 150

At the end of a sprint, the team evaluates 10 completed stories against their DoD. Eight stories fully satisfy the DoD, but two stories are missing the 'accessibility testing' criterion. How should these be counted in velocity?

A Count all 10 stories toward velocity B Only count the 8 stories that fully satisfy the DoD — partially done work should not be counted as completed velocity because it misrepresents the team's actual delivery; the 2 incomplete stories return to the backlog C Count all 10 and do accessibility testing next sprint D Count them as half-done for velocity purposes

135 / 150

Question 136 of 150

A PM manages a hybrid project using both predictive and agile approaches. The compliance module uses waterfall with a formal scope baseline, while the user interface uses Scrum with a product backlog. A new regulatory requirement affects both. How should the PM handle scope changes across both approaches?

A Submit a formal change request through integrated change control for the compliance module's scope baseline, AND add the requirement to the product backlog for prioritization by the product owner for the UI module — each approach handles changes through its own governance mechanism B Apply the same change control process to both modules C Only update the compliance module since regulations don't affect UI D Pause both modules until a single scope document is created

136 / 150

Question 137 of 150

A project uses progressive elaboration to develop requirements. After three iterations, the scope has grown 40% beyond the original estimate. Stakeholders are concerned about scope creep. How does the PM distinguish between legitimate progressive elaboration and scope creep?

A Progressive elaboration adds detail and clarity to APPROVED scope (the requirements become more specific), while scope creep adds NEW work not originally envisioned and not processed through change control — the 40% growth should be analyzed to determine which category each addition falls into B Progressive elaboration and scope creep are the same thing C Any growth beyond the original estimate is scope creep D Progressive elaboration always increases scope by at least 30%

137 / 150

Question 138 of 150

A PM is validating scope with stakeholders. The formal scope validation process involves inspecting deliverables for acceptance. In an agile context, what ceremony serves a similar purpose to scope validation?

A Backlog refinement B The sprint review — stakeholders inspect the working increment, provide feedback, and accept or reject delivered functionality; this serves the same purpose as formal scope validation but occurs iteratively rather than at the end of the project C Daily standup D Sprint planning

138 / 150

Question 139 of 150

A team decomposes a large feature into a WBS for the predictive portion of a hybrid project AND into user stories for the agile portion. The WBS shows 50 work packages and the product backlog shows 80 user stories. A stakeholder asks: 'Is there overlap between the WBS and the backlog?' What is the correct answer?

A There should be no overlap in WORK CONTENT, but there may be dependencies between them — the WBS and product backlog should collectively cover 100% of the project scope without duplication; a requirements traceability matrix or cross-reference mapping helps verify completeness and identify gaps B The WBS replaces the product backlog in hybrid projects C Complete overlap is expected since they describe the same work D There should be no overlap; they cover different work

139 / 150

Question 140 of 150

A PM discovers that 30% of the requirements in the scope baseline have no traceability to business objectives in the business case. What risk does this represent?

A Traceability is only needed for agile projects B No risk; not all requirements need business justification C These requirements may represent gold plating (adding features that were never requested or do not deliver business value) — requirements without traceability to objectives should be challenged, validated, or removed to ensure the project delivers only what the business needs D 30% is a normal rate for untraceable requirements

140 / 150

Question 141 of 150

A team uses story mapping to organize their product backlog. How does story mapping improve scope management compared to a flat prioritized list?

A Story mapping is just another name for a flat backlog B Story mapping arranges stories along a horizontal narrative flow (user journey) and vertical priority slices, revealing gaps in the user experience, enabling release planning by horizontal slices, and providing a holistic view of scope that a flat list cannot convey C Story mapping is only useful for projects with fewer than 20 stories D Story mapping eliminates the need for a product backlog

141 / 150

Question 142 of 150

A project's scope baseline was approved 6 months ago. Since then, 15 change requests have been approved and integrated. A new team member asks to see the current scope. Where should the PM direct them?

A The original project charter B The updated scope baseline that reflects all approved changes — the scope baseline is a living document that is re-baselined each time approved changes are integrated, ensuring it always represents the current committed scope C The change request log only D The original scope baseline document only

142 / 150

Question 143 of 150

A PM is deciding between using a WBS and a product backlog for scope management. The project involves both known, stable requirements and emerging, uncertain requirements. What approach is MOST effective?

A Use only a WBS since it is more structured B Use both — a WBS for the well-understood, stable scope components that can be planned upfront, and a product backlog for the emerging, uncertain components that will be progressively refined; this hybrid approach matches the scope management tool to the nature of the requirements C Choose one approach and convert all requirements to fit it D Use only a product backlog since it is more flexible

143 / 150

Question 144 of 150

A team completes decomposition of a WBS down to 150 work packages. They also write INVEST-compliant user stories for the agile components. A quality auditor asks: 'How do you know the scope is complete?' What evidence should the PM provide?

A A statement from the project sponsor confirming completeness B Scope completeness cannot be verified C A requirements traceability matrix showing that every business requirement maps to at least one work package or user story, and every work package or story traces back to at least one requirement — forward and backward traceability validates that nothing is missing and nothing is extraneous D The total count of work packages and stories is sufficient evidence

144 / 150

Question 145 of 150

A product owner and a PM disagree about whether to use story points or work packages to estimate the remaining project scope. The project is 60% complete. What is the BEST approach?

A Convert everything to hours for consistency B Stop estimating since the project is 60% complete C Only the PM's estimation method should be used D Use the estimation method that matches each component's delivery approach — story points for agile components (velocity-based forecasting) and work package estimates for predictive components (earned value forecasting) — then integrate both into a unified project status report

145 / 150

Question 146 of 150

A team uses the 100% rule when creating their WBS. What does the 100% rule mean, and how does it differ from the approach used with a product backlog?

A The 100% rule states that the WBS must capture 100% of the project scope — nothing more, nothing less; a product backlog, by contrast, intentionally starts incomplete and grows through progressive elaboration; this reflects the fundamental difference between plan-driven and value-driven scope management B 100% of the team must agree on the WBS C Both WBS and product backlog must capture 100% of scope upfront D The 100% rule means 100% of work packages must have owners

146 / 150

Question 147 of 150

A PM notices that the project's earned value shows SPI = 0.85 and the agile team's velocity has dropped 20% over the last 3 sprints. Both metrics suggest the project is falling behind. What scope-related action should the PM consider FIRST?

A Ignore both metrics and continue as planned B Add more resources to increase velocity C Conduct a scope review with stakeholders to identify lower-priority items that can be descoped or deferred — reducing scope to match actual delivery capacity preserves quality while adjusting expectations to reality D Extend the schedule without changing scope

147 / 150

Question 148 of 150

A stakeholder submits a change request that would add significant scope. The change request includes a strong business justification. In a predictive project, the PM processes it through integrated change control. In an agile context, how would this same request be handled?

A The Scrum Master approves or rejects the request B Through the same formal change control board C The product owner adds the new requirement to the product backlog and prioritizes it against existing items — if it is high priority, lower-priority items are naturally deferred; the backlog's prioritization mechanism IS the agile equivalent of change control for scope D Agile projects cannot accept change requests

148 / 150

Question 149 of 150

A PM is preparing a scope management plan for a hybrid project. What key elements should differ between the predictive and agile portions of the plan?

A The scope management plan should be identical for both portions B The predictive portion should define requirements collection methods, WBS creation process, scope baseline approval, formal change control, and scope validation milestones; the agile portion should define product backlog management, refinement cadence, Definition of Done, sprint review acceptance, and adaptation triggers C Only the predictive portion needs a scope management plan D Agile projects do not plan scope management at all

149 / 150

Question 150 of 150

A project delivered all items in the WBS and all stories in the product backlog, yet stakeholders are dissatisfied because the product does not solve their underlying business problem. What scope management failure occurred?

A No failure — all scope items were delivered B Stakeholder dissatisfaction is unrelated to scope management C The project suffered from a scope definition failure — the requirements were technically complete but did not align with the actual business need; this happens when scope focuses on outputs (deliverables) rather than outcomes (business value), indicating insufficient requirements validation and stakeholder engagement D The project needed more scope items to succeed

150 / 150

PMBOK 7 - Scope & Requirements