Overview
Exploring the DA Knowledge Base teaches you to find guidance rather than memorize it. The DA Browser is PMI's online view of the DA toolkit; PMI describes it as a way to search hundreds of agile, lean and serial techniques to choose a fit-for-purpose WoW. Content is layered: the Foundation layer (mindset and core concepts), Disciplined Agile Delivery (DAD), Disciplined DevOps, Value Streams and the Disciplined Agile Enterprise. Within delivery, process goals are grouped by Inception, Construction, Transition and ongoing work, and each goal opens into decision points and options, each with a description, trade-offs and references.
Candidates must understand how to move from a problem to the right goal, then to the decision point, then to the options worth trying. The course pairs the Browser with a microsite of supporting material. This module is the bridge between the mindset in module 1 and the diagnosis and improvement work in modules 3 and 4, which depend on finding the right options quickly.
How it's tested
Questions here test whether you know where guidance lives and how to use it. Expect a team problem followed by 'where should the team look first', 'which process goal addresses this' or 'what should the team consider before adopting this option'. The right answer moves from problem to goal to decision point to options, and weighs trade-offs against context rather than picking a favorite practice.
-
Map problem to goal
A symptom is described, such as escaped defects, and you pick the process goal that addresses it, here Improve Quality.
-
Right layer
A concern belongs to delivery, DevOps, value streams or the enterprise; you choose where in the toolkit to look.
-
Read the trade-off
Two options are both valid and you choose the one whose trade-offs best fit the stated constraint.
A team keeps discovering late that its solution does not integrate with a shared platform. Translate the symptom into a decision: this is about technical strategy and architecture risk, so look at Identify Architecture Strategy in Inception and Prove Architecture Early in Construction. Compare options such as an architecture spike or an early end-to-end skeleton by their trade-offs. An answer that adds a manual integration sign-off reaches for a control instead of the toolkit.
Module topics 3
Official module topics from the PMI outline, in outline order.
2.1 The DA BrowserPMI's searchable online view of the DA toolkit.
- What it means
- The DA Browser presents DA's layers, process goals, decision points and options online, each option with a description, its trade-offs and references for further reading.
- What to understand
- You navigate by layer and goal, or search by technique, and you read options in context: who is it for, what does it cost to adopt, what does it give up. Goals are grouped by phase in the delivery layer, so knowing the phase narrows the search.
- How it shows up
- A team names a problem and you choose where in the Browser to start, typically the process goal that the problem threatens.
- Common confusion
- Thinking the Browser lists only Scrum and Kanban practices; it spans agile, lean and serial techniques from many sources.
2.2 The DA micrositeSupporting web content that accompanies the toolkit.
- What it means
- The course pairs the Browser with a DA microsite that hosts supporting guidance, examples and explanations of how the toolkit's concepts fit together.
- What to understand
- Use the Browser to compare options for a specific decision and the microsite to understand the concepts behind them, such as the mindset or lifecycle choices. Knowing which source answers which question saves time.
- How it shows up
- A team member needs background on a concept rather than a list of options, and you pick the supporting material over the goal diagram.
- Common confusion
- Treating the microsite and the Browser as interchangeable; one explains, the other helps you choose.
2.3 Finding proven practices and guidanceFrom problem to goal to option, judged by trade-offs.
- What it means
- Finding guidance means translating a team problem into the process goal it affects, locating the relevant decision point and short-listing options whose trade-offs suit the team's context.
- What to understand
- Proven means the practice has worked for others in some context, not that it will work for you. Short-list two or three options, consider adoption cost and skills, then run one as an experiment and measure the result.
- How it shows up
- A scenario lists several candidate practices and asks which the team should try first, given a named constraint such as skills or regulation.
- Common confusion
- Adopting the first well-known practice found rather than comparing trade-offs for the decision point.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
DA toolkit layers
The DA toolkit is organized into layers: the Foundation layer (mindset, roles and core concepts), Disciplined Agile Delivery (DAD), Disciplined DevOps, Value Streams and the Disciplined Agile Enterprise.
- Remember
- Team-level delivery guidance sits in DAD; funding, portfolio and enterprise-wide concerns sit in outer layers.
- Tested as
- Questions ask where guidance for a given concern belongs.
- Trap
- Searching delivery process goals for portfolio or funding guidance that lives in an outer layer.
-
Process goal
A process goal names an outcome every team must address, such as Explore Scope, Improve Quality or Coordinate Activities, without saying how.
- Remember
- Goal, then decision point, then option: the hierarchy you navigate in the Browser.
- Tested as
- Mapping a symptom to the right goal is the first step in most knowledge base questions.
- Trap
- Naming a practice, such as daily stand-up, when the question asks for the goal it supports, Coordinate Activities.
-
Decision point
A decision point is one specific choice within a goal, such as the level of detail for initial scope or the test strategy within Improve Quality.
- Remember
- Each decision point has its own set of options; a team chooses per decision point, not per goal.
- Tested as
- Scenarios narrow a broad goal down to the one decision a team must make now.
- Trap
- Changing everything under a goal when only one decision point is causing the problem.
-
Option and trade-off
Each option is a technique with a description of its advantages, disadvantages and the situations where it fits, which DA calls its trade-offs.
- Remember
- Trade-offs, read against context, decide the choice; there is no universally best option.
- Tested as
- Most 'BEST option' questions are resolved by one stated constraint matching one trade-off.
- Trap
- Choosing an option because it is popular or advanced while ignoring the disadvantage that the scenario's constraint makes fatal.
-
Ordered options
Where a goal diagram shows an arrow beside a list, the options are ranked so those nearer the top are generally more effective.
- Remember
- Generally more effective often means harder to adopt; moving up one step at a time is normal.
- Tested as
- Tests whether you suggest a realistic next step instead of the top option.
- Trap
- Reading every list as ranked; only lists with the arrow are ordered.
-
Phase grouping of delivery goals
DAD goals are grouped as Inception goals (such as Develop Common Vision and Explore Scope), Construction goals (such as Prove Architecture Early and Improve Quality), Transition goals (such as Ensure Production Readiness and Deploy the Solution) and ongoing goals (such as Coordinate Activities, Address Risk and Evolve WoW).
- Remember
- Knowing when a problem occurs narrows which group of goals to search.
- Tested as
- Questions ask which goal fits a problem that surfaces at a given point in delivery.
- Trap
- Treating ongoing concerns such as risk or WoW improvement as Inception-only.
-
Agile, lean and serial techniques
PMI describes the Browser as covering hundreds of agile, lean and serial techniques, so traditional practices appear alongside agile ones where they fit a context.
- Remember
- A serial (traditional) technique can be the right option in a heavily regulated or fixed-scope context.
- Tested as
- Tests whether you accept a non-agile option when the trade-offs support it.
- Trap
- Dismissing any traditional option as anti-agile.
-
Experiment, then adopt
After short-listing options, a team tries one as a time-boxed experiment, measures its effect and keeps or discards it.
- Remember
- The knowledge base supplies candidates; evidence from the experiment decides.
- Tested as
- The default next step after finding an option.
- Trap
- Rolling a newly found practice out to every team before testing it in one.
-
Roles in the toolkit
DA defines primary roles (team lead, product owner, architecture owner, team member, stakeholder) and supporting roles (specialist, independent tester, domain expert, technical expert, integrator).
- Remember
- In DA the team lead plays the servant-leader role a Scrum master plays, and the architecture owner guides technical decisions.
- Tested as
- Questions ask who should own a decision found in the knowledge base.
- Trap
- Assigning technical strategy decisions to the product owner instead of the architecture owner and team.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Process goal vs. decision point vs. option
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Process goal | An outcome the team must address, such as Improve Quality | Says what, not how | Treating it as a ceremony to perform |
| Decision point | A specific choice within the goal, such as the test strategy | Narrows the goal to one decision | Changing every decision when only one is broken |
| Option | A technique for that decision, with trade-offs | The concrete practice the team adopts | Choosing an option without reading its disadvantages |
DA Browser vs. DA microsite
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| DA Browser | Searchable view of layers, goals, decision points and options | Used to compare and choose options for a decision | Looking for broad conceptual explanations here first |
| DA microsite | Supporting guidance and explanations that accompany the toolkit | Used to understand concepts behind the options | Expecting it to rank options for a specific decision |
Team-level vs. enterprise-level guidance
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Disciplined Agile Delivery (DAD) | Guidance for teams producing solutions: lifecycles and delivery goals | Scope is one team or a team of teams | Looking here for portfolio funding decisions |
| Disciplined Agile Enterprise and value streams | Guidance for organization-wide capabilities such as portfolio management, finance and governance | Scope is the organization and its value streams | Applying enterprise guidance to a team-level testing problem |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Most popular practice
- What candidates pick
- The best-known agile practice for the problem.
- Why it looks right
- Familiarity feels like safety.
- Why it's wrong
- DA asks you to weigh trade-offs against context, and a familiar option may carry a disadvantage the scenario makes decisive.
Clue to watch for A stated constraint such as skills, distribution or regulation points to a different option.
-
Skipping the goal
- What candidates pick
- Jumping straight to a practice without identifying the process goal at risk.
- Why it looks right
- It feels faster.
- Why it's wrong
- Without the goal you cannot see the full set of options or check you are solving the right problem.
Clue to watch for The question asks where the team should look first or which goal applies.
-
Wrong layer
- What candidates pick
- Delivery guidance for a portfolio or funding problem.
- Why it looks right
- Delivery goals are the most familiar part of DA.
- Why it's wrong
- Funding and portfolio concerns are addressed in the enterprise and value stream layers.
Clue to watch for Words like budget, portfolio, investment or multiple value streams.
-
Anti-serial bias
- What candidates pick
- Rejecting a traditional technique because it is not agile.
- Why it looks right
- The course is about agility.
- Why it's wrong
- DA includes serial techniques because some contexts, such as strict regulatory regimes, make them the most effective option.
Clue to watch for An external regulator or contract requires a specific artifact or review.
-
Instant organization-wide rollout
- What candidates pick
- Mandating a newly found practice for all teams.
- Why it looks right
- If it is proven, why wait?
- Why it's wrong
- Proven elsewhere is not proven here; DA expects a measured experiment and other teams have different contexts.
Clue to watch for Only one team has the problem, or the practice has not yet been tried locally.
-
Change the whole goal
- What candidates pick
- Replacing all practices under Improve Quality because defects escaped.
- Why it looks right
- It looks thorough.
- Why it's wrong
- The problem usually traces to one decision point, and changing everything hides which change worked.
Clue to watch for The symptom is specific, such as integration defects only.
Answer framework
Use this sequence when a question asks how a team should use the DA knowledge base to address a problem.
- Restate the symptom as an outcome at risk, then find the process goal that owns that outcome and the layer it sits in.
- Narrow to the single decision point that is causing the problem rather than reworking the whole goal.
- Short-list two or three options and read each one's advantages, disadvantages and the contexts where it fits.
- Eliminate options whose disadvantages collide with a constraint stated in the scenario, such as skills, regulation or distribution.
- Choose the remaining option the team can realistically adopt now, run it as a measured experiment, and keep it only if the evidence supports it.
Practice question
Want more like this? The DASM practice test has questions for every domain.
Checklist
0 of 11
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Spend most of this module inside the DA Browser rather than reading about it. Start by opening each layer briefly so you know what kind of guidance lives where. Then work through the delivery goals phase by phase: Inception, Construction, Transition and ongoing. For each goal, write one symptom that would send you there, such as 'escaped defects' for Improve Quality or 'duplicated work' for Coordinate Activities.
Next, pick three decision points and read every option's trade-offs. Practise saying, for each option, 'this fits when...' and 'this fails when...'. That habit is what turns knowledge base questions into easy eliminations.
Commonly underestimated areas are the outer layers, which candidates skip because the course focuses on teams, and serial techniques, which candidates reflexively reject. Afterwards, practise scenario questions that ask where to look first and which option to try, then move to Solving Team Challenges, where you will use the same lookup skill on problems the Team Canvas uncovers.
FAQ
Do I need to memorize the options in the DA Browser?
No. The skill is navigation and judgment: map a problem to the right goal and decision point, then compare trade-offs. Know the goal names well and the options broadly.
Is the DA Browser free?
PMI lists the DA Browser as an online tool on its agile pages. Access terms can change, so check the current terms on pmi.org.
What is the difference between the Browser and the microsite?
The Browser helps you compare and choose options for a specific decision. The microsite supports the course with explanations of the concepts behind those options.
Does the knowledge base include non-agile practices?
Yes. PMI describes it as covering agile, lean and serial techniques, because some contexts call for traditional approaches.
How do I know which option is best?
There is no universal best. Read the trade-offs, eliminate options that conflict with your constraints, and test the strongest remaining option as an experiment.
How does this module connect to the scenarios later in the course?
Both team scenarios ask you to apply the knowledge base to a team's context, so the lookup and trade-off habits built here are what you use there.
How much study time does this module need?
Plan for about two to three hours, most of it spent navigating real goals and reading trade-offs rather than reading summaries.
Other Project Management certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
- PRINCE2 7 Practitioner Study guide
- PMI Risk Management Professional Study guide
- PMI Scheduling Professional Study guide
- Project Management Professional Study guide
- CompTIA Project+ Study guide
- PRINCE2 7 Foundation Study guide
- Portfolio Management Professional Study guide
- Program Management Professional Study guide
- Certified Associate in Project Management Study guide
- Agile Project Management Study guide
- PMI Agile Certified Practitioner Study guide
- Project Management Professional (PMBOK 7) Study guide
Test your Domain 2 knowledge
You have just learned how to move from a team problem to a process goal, a decision point and a short list of options. Test whether you can do it quickly under scenario conditions.