PMI-DASM Practice Questions

A Minimum Viable Product (MVP) is a core concept in lean and agile approaches, including Disciplined Agile. Its primary purpose is twofold: to deliver immediate value to early adopters and, more importantly, to function as an experiment to gather validated learning. By releasing a product with a minimal feature set, the team can test its core business hypotheses with real users. The feedback collected is crucial for guiding future development, ensuring that subsequent iterations are based on actual user needs and behavior rather than assumptions. This "build-measure-learn" feedback loop minimizes wasted effort and maximizes the chances of building a successful product.

B. Is used for demonstration only.

This describes a prototype or a proof-of-concept, which is used for demonstration, not a functional product released to customers for real-world use and feedback.

C. Will be the last iteration of development.

An MVP is the first releasable version of a product, designed to start an iterative cycle of feedback and improvement, not end it.

D. Is not yet ready to be sold.

The "V" in MVP stands for "Viable." This means it must provide enough value that customers are willing to use it or even pay for it, distinguishing it from an incomplete or non-functional prototype.

1. Ambler, S. W., & Lines, M. (2020). Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. Project Management Institute.

Page 360 (Glossary): Defines MVP as, "A version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort." This directly supports the feedback and learning purpose.

Page 79: Discusses MVP as a key part of a lean startup strategy, emphasizing the goal is to "get something into the hands of our stakeholders quickly so that we can get their feedback."

2. Project Management Institute. (2017). Agile Practice Guide.

Section 5.2.5, "Minimum Viable Product (MVP)": States, "The team can build the smallest piece of work that can be delivered for value and, most importantly, for feedback. This smallest deliverable is known as the minimum viable product."

3. Project Management Institute. (n.d.). Disciplined Agile Browser.

Process Goal: "Explore Scope" > Decision Point: "Explore Usage" > Option: "Minimum Viable Product (MVP)": The description states the purpose of an MVP is to "get feedback from them [stakeholders] so that we can evolve the product to better meet their actual needs."

In Disciplined Agile (DA), team estimation is a collaborative process focused on determining the size of work items, such as user stories. The most common and recommended approach is relative estimation. This technique involves the team first comparing stories to each other to understand their relative sizes (e.g., "Story X is about twice as complex as Story Y"). After establishing this relative scale, the team assigns numerical values, typically story points from a sequence like Fibonacci, to represent that size. This leverages the collective wisdom of the team to create a shared understanding of the work involved, rather than focusing on precise time-based predictions.

B: This describes team or task prioritization, which is a separate activity from estimating the size or effort of the work itself.

C: This describes the creation of the "Definition of Done," a quality standard that clarifies when work is truly complete, not an estimation technique.

D: This is part of resource planning or identifying required skills for the team, not the process of estimating the size of user stories.

1. Ambler, S. W., & Lines, M. (2019). Choose Your WoW!: A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. Project Management Institute.

Page 111, Section 5.10, Estimate Work: The text describes the trade-offs of estimation and highlights relative estimation as a key strategy. It states, "A common way to estimate relatively is to size work items using story points... The basic idea is that you estimate the size of a work item, such as a user story, relative to the size of other items." This directly supports the two-step process in option A.

Page 112, Figure 5.22: The decision point "How to Estimate?" explicitly lists "Relative (story points, ...)" as a primary option for agile teams, contrasting it with absolute estimates in ideal time. This reinforces the concept of relative sizing before assigning points.

The Disciplined Agile (DA) toolkit emphasizes pragmatism and the principle of "Start Where You Are." The team's context is the primary driver for selecting a lifecycle. In this scenario, the team's lack of an agile mindset and their explicit desire for infrequent releases (every six months) are the dominant factors. While rapidly changing requirements suggest an adaptive approach, forcing an Agile or Lean lifecycle on an unwilling and unprepared team would be counterproductive and likely lead to failure. The DA toolkit includes a Traditional (also called Serial) lifecycle specifically for situations where it is the most appropriate fit for the team's current skills, culture, and context.

A. Program: A Program lifecycle is designed to coordinate a "team of teams" working on a large, integrated solution, not for a single project team as described.

B. Lean: The Lean lifecycle is an agile approach focused on continuous flow and delivering value as quickly as possible, which directly contradicts the team's preference for infrequent releases.

D. Agile: The Agile lifecycle is iterative and requires an agile mindset to deliver value in short cycles (sprints), which is misaligned with the team's stated culture and release cadence.

1. Ambler, S. W., & Lines, M. (2020). Choose Your WoW!: A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. Project Management Institute.

Page 60, Section 4.5, The Serial/Traditional Lifecycle: This section explicitly states, "It is also a good option for teams that are not yet skilled in agile or lean techniques or for teams that are organizationally unable to adopt these more modern ways of working." This directly supports choosing the Traditional lifecycle based on the team's lack of an agile mindset.

Page 38, Chapter 3, Choosing the Right Lifecycle: The text emphasizes that context counts and that the choice of lifecycle depends on the situation the team faces. The team's skills and culture are key contextual factors.

Page 61, Section 4.6, The Program Lifecycle: This section defines the Program lifecycle as being for a "team of teams," making it inappropriate for the single team in the scenario.

Disciplined Agile (DA) categorizes team roles into two types: primary and supporting. Primary roles are essential for the team's day-to-day function throughout the initiative. Supporting roles, however, are engaged on an as-needed, often temporary, basis to provide specific skills or expertise that the core team lacks. A Specialist, such as a security expert or database administrator, is a classic example of a supporting role, brought in to address particular challenges or tasks before disengaging.

A. Team Lead: This is a primary role, responsible for facilitating the team, removing impediments, and ensuring the DA process is followed.

B. Architecture Owner: This is a primary role that owns the architecture decisions and guides the team on technical and design strategies.

C. Stakeholder: This is a primary role representing the individuals for whom the solution is being built and who will be affected by it.

1. Ambler, S. & Lines, M. (2019). Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. Project Management Institute.

Page 38, Table 3.1 "The Roles on a Disciplined Agile Team": This table explicitly lists "Specialist" under the "Supporting Roles" category. It lists "Team Lead," "Architecture Owner," and "Stakeholder" under the "Primary Roles" category.

Page 47, Section "Supporting Roles": This section details the nature of supporting roles, stating, "The supporting roles are played on a temporary, as-needed basis... A specialist is someone with a specific skillset that is required by the team for a short period of time."

The Disciplined Agile (DA) framework describes a full, goal-driven delivery life cycle that is common across various approaches. This life cycle consists of three distinct phases. The Inception phase focuses on envisioning the project, securing funding, and forming the team. The Construction phase is where the team incrementally produces a potentially consumable solution. Finally, the Transition phase ensures the solution is successfully deployed or released to stakeholders and the business is prepared to receive it. These three phases provide a lightweight governance structure for agile and lean projects from initiation to delivery.

A. Inspiration: This is not a formal phase in the Disciplined Agile life cycle; it typically occurs before a project is formally initiated, within portfolio management.

B. Modulation: This term is not used within the Disciplined Agile framework to describe a project life cycle phase.

1. Ambler, S. & Lines, M. (2019). Choose Your WoW!: A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. Project Management Institute. See Chapter 3, "The Disciplined Agile Delivery (DAD) Process Framework," particularly Figure 3.1 and the section "The Phases of a DAD Project," pp. 40-41, which explicitly names and details the Inception, Construction, and Transition phases.

2. Project Management Institute. (2021). Introduction to Disciplined Agile. This official PMI courseware for the DASM certification introduces the three phases (Inception, Construction, Transition) as the fundamental structure of the Disciplined Agile Delivery (DAD) life cycle in Module 2: Foundations of Disciplined Agile.

Guided Continuous Improvement (GCI) is a fundamental concept in the Disciplined Agile (DA) toolkit that enhances the traditional Kaizen (Plan-Do-Study-Act) loop. Instead of relying on unstructured experimentation, GCI provides teams with a framework of process goals, decision points, and a curated list of proven techniques with their associated trade-offs. This guidance helps teams make more informed choices about which new practices are likely to succeed in their specific context, thereby accelerating and focusing their improvement efforts. It extends the Kaizen strategy by providing a "guardrail" of options rather than leaving teams to discover them on their own.

A. Explicit workflow policies: This is a core practice of Kanban used to make process rules visible, not a method for identifying new techniques to try.

C. Communities of practice: These are groups for sharing knowledge and can be a source of ideas for improvement, but they are not the structured method itself.

D. Cross-team learning: This is a valuable activity for sharing experiences but lacks the structured, context-sensitive guidance that defines GCI.

1. Ambler, S., & Lines, M. (2019). Choose Your WoW!: A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. Project Management Institute.

Page 32, Section "Guided Continuous Improvement": "DA provides light-weight guidance to help you choose the techniques that are most likely to work for you in your context. We call this guided continuous improvement (GCI)." This section explicitly contrasts GCI with the traditional Kaizen approach, highlighting how DA's guidance extends it.

Page 23, Principle "Choice is Good": This principle underpins GCI, stating, "Different contexts require different strategies... DA provides you with choices and helps you to make better choices."

The primary purpose of a coordination meeting, often referred to as a daily stand-up or daily scrum in agile contexts, is for the project team to synchronize their activities. During this brief, recurring event, team members share progress, discuss any impediments they are facing, and align on the plan for the immediate future (typically the next 24 hours). This ensures that the team remains aligned, can quickly address issues, and can self-organize effectively to meet their iteration goals. It is a meeting for the team, by the team, to facilitate collaboration and maintain momentum.

A. This describes a review or demonstration meeting, which is a separate event focused on showcasing completed work to stakeholders, not a daily coordination meeting.

C. While stakeholders may occasionally observe, the meeting's primary purpose is internal team coordination, not a performance review for external parties.

D. Reassessing the backlog is the focus of backlog refinement (or grooming) and iteration planning meetings, not the brief, daily coordination meeting.

1. Ambler, S. & Lines, M. (2020). Choose Your WoW!: A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. Project Management Institute.

Page 101, Section 4.5, "The Inception Phase," Process Goal: Coordinate Activities: The text describes the goal of coordinating activities as essential for team members to "remain in sync." It lists the "Daily stand-up (Scrum)" as a primary tactical option to achieve this, emphasizing its role in daily synchronization.

Page 102, Table 4.5: This table outlines the trade-offs for different coordination strategies. The description for daily meetings highlights their purpose is to "Share what you're doing," "Get help," and "Coordinate with others," which directly supports the concept of the team staying in sync.

2. Project Management Institute. (2017). Agile Practice Guide.

Page 56, Section 5.2.3, "Daily Standups": The guide states, "The purpose of the daily standup is for the team to inspect progress toward the iteration goal and to adapt the plan for the current day's work." This act of inspecting and adapting is the mechanism through which the team stays in sync.

In Disciplined Agile (DA), teams are self-organizing and empowered. During iteration planning, the Product Owner presents the prioritized backlog of work. However, it is the responsibility of the entire delivery team to determine how much of that work they can realistically commit to completing within the iteration. This decision is based on their collective understanding of their current capacity, historical performance (velocity), and the complexity of the prioritized items. The team "pulls" work from the backlog into the iteration plan, rather than having work "pushed" onto them. This fosters ownership, accountability, and a sustainable pace.

A. The product owner prioritizes the work ("what") but does not dictate the amount; the team determines its own capacity and commitment.

B. The quality tester is a member of the team, and their capacity is a factor, but they do not make this decision for the entire team.

C. The team lead acts as a servant leader and facilitator, not a manager who dictates the team's workload or commitments.

1. Ambler, S. W., & Lines, M. (2019). Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. Project Management Institute.

Page 101, "Plan the Iteration" section: "The team decides how much work to bring into the iteration. They do this by considering their velocity... and the relative size of the work items at the top of the work item list."

Page 40, "Principle: Empowered Teams": "DA teams are self-organizing in that they determine their own way of working (WoW)... They own their process and they are accountable for their results."

2. Project Management Institute. (2017). Agile Practice Guide.

Section 5.2.4, "Iteration Planning": "The team determines its capacity for the iteration... The team pulls the number of stories from the top of the backlog that they forecast they can complete in the iteration." This principle is foundational to the DA toolkit.

Disciplined Agile (DA) milestones are a fundamental component of its lean governance framework. Unlike traditional, documentation-heavy phase gates, DA milestones are lightweight, risk-based checkpoints. They provide key stakeholders with visibility into the initiative and opportunities to make critical decisions at opportune times. Milestones such as "Proven Architecture," "Continued Viability," and "Sufficient Functionality" are explicitly designed to mitigate common project risks (technical, financial, market) early and ensure the team remains focused on delivering consumable solutions that provide real business value. This approach embodies the lean principles of minimizing waste and maximizing value, which are central to DA's governance strategy.

A. Continuous integration: This is a technical practice for frequently merging code. While it supports achieving milestones, it is not the basis for defining what those governance milestones are.

B. Documentation: Documentation is a work product. DA promotes lean, pragmatic documentation, but the milestones themselves are based on mitigating risk and proving value, not on producing documents.

D. Lifecycle: A lifecycle (e.g., Agile, Lean) is the end-to-end process framework a team adopts. The milestones are governance points within a lifecycle, but their existence and purpose are dictated by lean governance principles.

1. Ambler, S. W., & Lines, M. (2019). Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. Project Management Institute.

Page 315, Chapter 19, Section "Governing Disciplined Agile Teams": "A lean governance approach is risk and value driven... To govern DAD teams effectively, you need to look at the key risks that they face. The DAD lifecycle explicitly includes several risk-based milestones that your governance function can and should leverage." This passage directly links DA milestones to a lean, risk-based governance strategy.

Page 316, Figure 19.2: This figure explicitly lists the "Risk-Based Milestones of DAD" as part of the governance chapter, reinforcing their role as a governance mechanism.

In a Lean paradigm, management's role shifts from command-and-control to that of a coach and enabler. Their primary responsibility is to foster an environment where teams can thrive and continuously improve. This aligns with the Disciplined Agile (DA) principle of "Be Awesome," which includes creating psychological safety and a productive, collaborative atmosphere. By creating an "awesome team environment," management empowers teams, removes impediments, and supports the system of work, which is the essence of Lean leadership. This enables teams to focus on delivering value and eliminating waste, which are the core goals of Lean.

A. Ensure documentation is completed.

Lean principles aim to eliminate waste (Muda), and excessive or unnecessary documentation is a common form of waste. The focus is on value, not just completing documentation.

B. Provide minimum viable products to the team.

The development team, in collaboration with the product owner and stakeholders, is responsible for creating the Minimum Viable Product (MVP). Management's role is to support this process, not to provide the MVP itself.

C. Ensure decisions are not made regionally.

This contradicts the Lean and Agile principle of decentralized decision-making. Teams closest to the work are empowered to make local, operational decisions to improve flow and responsiveness.

1. Ambler, S. W., & Lines, M. (2020). Choose Your WoW!: A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. Project Management Institute.

Chapter 2, The Disciplined Agile Mindset, Section: Be Awesome: This principle explicitly states that a key goal is to "create psychological safety and embrace diversity." This is a foundational element of an awesome team environment and a key responsibility of leadership.

Chapter 3, People, Roles, and Team Structures, Section: Team Lead: The Team Lead (a management role) is described as a servant leader who "facilitates the team in their work" and "removes impediments," which are activities that contribute directly to creating a positive and effective environment.

Chapter 1, Introduction, Section: The Foundations of Disciplined Agile: This section explains that DA has a foundation in Lean principles, including "Respect for People." Creating an awesome team environment is a direct application of this principle.