PMI CAPM Actual Questions

In Agile/Scrum methodologies, as described in the Agile Practice Guide and the Scrum Guide, there is a critical distinction between getting a story " ready " to start and getting it " ready " for the customer (Done).

Why Choice D is correct:

The Definition of Done (DoD): This is a formal description of the state of the Increment when it meets the quality measures required for the product. It is a checklist of all the technical and quality criteria that a user story must meet before it can be considered complete (e.g., coded, unit tested, integrated, documented, and bug-free).

Customer Use: When a customer claims a story is " not ready for use " during a demo, it usually means a quality standard or a functional requirement was missed. The team reviews the DoD to see if they skipped a mandatory step (like security testing or user documentation) that would have caught the issue before the demo.

Transparency: The DoD ensures that everyone (the team and the stakeholders) has a shared understanding of what " complete " work means.

Analysis of other options:

A (Burndown chart): This is a trend tool that shows how much work is remaining in a sprint. It tracks progress over time but does not contain quality criteria or checklists for individual user stories.

B (Velocity chart): This tracks the amount of work (usually in story points) a team completes in each sprint. It is a capacity planning tool, not a quality or requirements checklist.

C (Definition of Ready - DoR): This is the checklist used to determine if a user story is well-defined enough to be taken into a sprint (e.g., it has clear acceptance criteria and dependencies are removed). Since the story in the question is already being demoed, it had already passed the DoR. The issue now is whether it was finished correctly, which is the role of the DoD.

Key Concept: The Project Management Institute (PMI) emphasizes that the Definition of Done is the primary tool for maintaining quality in an adaptive environment. If an increment is not " Ready for Customer Use, " it means it failed to meet the DoD, and therefore, cannot be considered part of the Increment or contribute to the team ' s Velocity for that sprint. Choice D is the governing document for this situation.

In accordance with the PMBOK® Guide (Project Integration Management), the Perform Integrated Change Control process is the process of reviewing all change requests; approving changes and managing changes to deliverables, project documents, and the project management plan; and communicating the decisions.

Meetings are a primary tool and technique specifically used for this process, often referred to as Change Control Board (CCB) meetings.

Role of the CCB: The Change Control Board is a formally chartered group responsible for reviewing, evaluating, approving, deferring, or rejecting changes to the project.

Meeting Function: During these meetings, the impact of each change request is discussed. The board reviews the configuration management activities and determines the feasibility of the change in relation to the project ' s scope, schedule, cost, and risk baselines.

Decision Documentation: The outcome of these meetings is recorded in the Change Log as approved or rejected change requests.

Other Tools and Techniques: This process also utilizes Expert Judgment, Change Control Tools (manual or automated), and Data Analysis (including Alternatives Analysis and Cost-Benefit Analysis).

Analysis of Distractors:

A. Decomposition: This is a tool and technique used in Create WBS and Define Activities. It involves breaking down project scope and deliverables into smaller, more manageable components.

B. Modeling techniques: These are typically used in Develop Schedule (e.g., Schedule Network Analysis or S Curve) or Estimate Costs to simulate different scenarios.

C. Resource optimization: This is a tool and technique used in Develop Schedule and Control Schedule (such as Resource Leveling or Resource Smoothing) to adjust the schedule model based on resource demand and supply.

According to the PMBOK® Guide (specifically the 4th and 5th editions, which use these specific process names), Define Activities and Estimate Activity Resources are core processes within the Project Time Management knowledge area (renamed to Project Schedule Management in later editions).

Define Activities: This process involves identifying and documenting the specific actions to be performed to produce the project deliverables. It takes the work packages from the WBS and breaks them down into schedule activities that provide a basis for estimating, scheduling, executing, monitoring, and controlling the project work.

Estimate Activity Resources: This process involves estimating the types and quantities of material, human resources, equipment, or supplies required to perform each activity. This is a critical step because the availability and type of resources directly impact the duration of the activities.

Knowledge Area Context: In the standard process mapping, Project Time/Schedule Management includes:

Plan Schedule Management

Define Activities

Sequence Activities

Estimate Activity Resources

Estimate Activity Durations

Develop Schedule

Control Schedule

Comparison with Other Domains:

Project Cost Management (B): Focuses on Estimate Costs, Determine Budget, and Control Costs.

Project Scope Management (C): Focuses on Collect Requirements, Define Scope, and Create WBS.

Project Human Resource Management (D): While this area (now Resource Management) deals with managing the team, the initial estimation of which resources are needed for specific tasks is traditionally housed within the Time/Schedule management processes to build the project timeline.