Overview
Solving Team Challenges teaches a team to diagnose before it prescribes. PMI's course uses tools such as the DA Team Canvas, a shared one-page view the team builds together, to make its context and current challenges visible. With the picture on one page, the team looks for where work actually gets stuck: queues before a hand-off, too much work in progress, frequent blocking, rework from unclear requirements, or dependencies on other teams.
Candidates must understand the difference between a symptom and its cause. Missed sprint goals are a symptom; the cause might be unplanned support work, a testing bottleneck or oversized items. Flow measures such as cycle time, throughput and work in progress help separate the two. Once the cause is clear, the team returns to the knowledge base from module 2 to find options for the specific decision at fault, and module 4 turns those choices into a prioritized improvement backlog.
How it's tested
Questions on this module present a struggling team and ask for the FIRST or BEST step. Expect symptoms such as missed commitments, long lead times or growing queues, sometimes with simple flow numbers. The right answer usually makes the work visible or finds the root cause before changing the process, and when a fix is called for, it targets the bottleneck rather than adding effort everywhere.
-
Diagnose before you fix
A team reports a vague problem and you choose the step that exposes the cause, such as mapping its workflow on a canvas or board, over an immediate process change.
-
Find the constraint
Flow data shows where work waits and you pick the improvement that acts on that stage, not the busiest-looking one.
-
Symptom versus cause
Several answers fix the visible symptom; one addresses the underlying cause, such as unplanned work entering mid-iteration.
A team's cycle time has doubled, yet everyone reports being busy. Ask where work waits. If items pile up in 'ready for test' while developers start new work, the constraint is testing and work in progress is too high. The targeted response is to lower the WIP limit and have developers help clear testing. Adding developers or longer iterations adds more work to the queue and makes the wait worse.
Module topics 3
Official module topics from the PMI outline, in outline order.
3.1 The DA Team CanvasA one-page shared view of the team's context and challenges.
- What it means
- The DA Team Canvas is a visual tool the team completes together so that its context, way of working and current challenges are visible on one page before anyone proposes a change.
- What to understand
- The canvas works because the whole team builds it, so it surfaces problems that individuals see differently and creates shared ownership of the diagnosis. It is a conversation tool, not a status report for management.
- How it shows up
- A team disagrees about why delivery is slow, and the BEST first step is to build a shared picture of context and challenges before choosing a fix.
- Common confusion
- Treating the canvas as a document the team lead fills in alone, which loses the shared understanding it is meant to create.
3.2 Diagnosing workflow problemsUsing visibility and flow measures to find the real constraint.
- What it means
- Diagnosis means making all work and workflow visible, measuring how work flows (cycle time, throughput, work in progress, blocked time) and finding the stage where work waits longest.
- What to understand
- Little's Law links the measures: average cycle time equals average WIP divided by average throughput, so cutting WIP shortens cycle time when throughput holds. Root-cause techniques such as asking 'why' repeatedly turn a symptom into a cause the team can act on.
- How it shows up
- A scenario gives WIP and throughput figures or describes a growing queue, and you identify the bottleneck or predict the effect of a WIP change.
- Common confusion
- Equating busy people with good flow; high utilization usually lengthens queues and cycle time.
3.3 Identifying targeted solutionsMatching a diagnosed cause to specific options and testing them.
- What it means
- A targeted solution addresses the specific cause the diagnosis found, using options from the relevant process goal, and is introduced as a small, measurable experiment.
- What to understand
- Decide in advance what measure should change and by how much, so the experiment can succeed or fail clearly. Address one constraint at a time; fixing a non-bottleneck stage rarely improves overall flow.
- How it shows up
- Several improvement ideas are offered and you pick the one that acts on the diagnosed cause with a clear way to measure its effect.
- Common confusion
- Choosing a broad framework switch when the evidence points to one decision point.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
DA Team Canvas
The DA Team Canvas is a one-page visual tool the team builds together to capture its context, way of working and current challenges before choosing improvements.
- Remember
- Built collaboratively, it creates a shared diagnosis and the ownership needed to act on it.
- Tested as
- Often the correct first step when a team disagrees about what is wrong.
- Trap
- Using it as a management report filled in by one person.
-
Make all work and workflow visible
This DA promise means showing every piece of work, including unplanned and support work, and every workflow stage, typically on a board.
- Remember
- Hidden work, such as side requests from stakeholders, is a frequent cause of missed commitments.
- Tested as
- Appears when a team's plan looks reasonable but delivery still slips.
- Trap
- Making only planned feature work visible and ignoring interruptions.
-
Work in progress (WIP) and WIP limits
WIP is the number of items started but not finished; a WIP limit caps how many items a stage or team may hold at once.
- Remember
- Lower WIP shortens cycle time and exposes bottlenecks; stop starting, start finishing.
- Tested as
- Central to flow questions and to the keep workloads within capacity promise.
- Trap
- Raising WIP limits to look more productive.
-
Little's Law
Little's Law states that average cycle time equals average WIP divided by average throughput, for a reasonably stable system.
- Remember
- With 20 items in progress and 5 finished per week, average cycle time is about 4 weeks; halving WIP to 10 brings it to about 2 weeks if throughput holds.
- Tested as
- Used in simple calculation or prediction questions about WIP changes.
- Trap
- Expecting more WIP to raise throughput; past a point it only lengthens cycle time.
-
Cycle time vs. lead time
Cycle time runs from when work starts to when it finishes; lead time runs from when it is requested to when it is delivered, including the wait before work starts.
- Remember
- Customers feel lead time; teams control cycle time most directly.
- Tested as
- Questions ask which measure reflects a customer's wait.
- Trap
- Using cycle time to describe how long a requester waited from asking.
-
Throughput
Throughput is the number of work items completed per unit of time, such as items per week.
- Remember
- It measures completion, not effort or items started.
- Tested as
- Paired with WIP and cycle time in flow calculations.
- Trap
- Counting started items or hours worked as throughput.
-
Bottleneck (constraint)
The bottleneck is the workflow stage with the least capacity relative to demand, visible as the queue that grows in front of it.
- Remember
- Improving any stage other than the bottleneck does not raise overall flow.
- Tested as
- Questions show a growing queue and ask where to act.
- Trap
- Improving the busiest-looking stage rather than the one where work waits.
-
Root cause analysis
Techniques such as asking 'why' repeatedly or a cause-and-effect (fishbone) diagram trace a visible symptom back to an underlying cause.
- Remember
- Fix the cause, not the symptom: missed commitments are rarely solved by longer iterations.
- Tested as
- Distinguishes the targeted answer from the symptomatic one.
- Trap
- Stopping at the first plausible explanation.
-
Measured experiment
A targeted change introduced for a set period with a stated expected effect on a measure, such as cutting cycle time by a quarter in four weeks.
- Remember
- Decide the measure and success threshold before starting.
- Tested as
- The default way DA introduces a fix.
- Trap
- Changing several things at once so no one knows which one helped.
-
Goal Question Metric (GQM)
GQM is a way to choose measures by stating a goal, asking the questions that show progress toward it, and only then picking metrics that answer those questions.
- Remember
- Start from the goal; never collect metrics just because they are available.
- Tested as
- Appears when a team must decide how to measure an improvement.
- Trap
- Adopting a standard metric dashboard that does not answer the team's question.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Cycle time vs. lead time vs. throughput
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Cycle time | Time from starting work on an item to finishing it | Excludes the wait before work starts | Quoting it as the customer's total wait |
| Lead time | Time from request to delivery | Includes queue time before work begins | Ignoring the backlog wait that customers feel |
| Throughput | Items completed per unit of time | A rate, not a duration | Counting items started instead of finished |
Symptom vs. root cause
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Symptom | The visible effect, such as missed iteration goals | Tells you something is wrong | Fixing it directly, for example by lengthening iterations |
| Root cause | The underlying reason, such as unplanned support work entering mid-iteration | Tells you what to change | Stopping analysis at the first plausible reason |
Targeted fix vs. framework switch
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Targeted fix | A change to one decision point that addresses the diagnosed cause | Small, measurable and reversible | Skipping it because it looks too small to matter |
| Framework switch | Replacing the whole way of working with another method | Large, slow and hard to attribute results to | Choosing it when the evidence points to one constraint |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Add people
- What candidates pick
- Adding developers to a team whose items wait in testing.
- Why it looks right
- More capacity sounds like faster delivery.
- Why it's wrong
- Extra development capacity feeds more work into the testing queue; the bottleneck, and cycle time, get worse.
Clue to watch for A queue is growing in front of one specific stage.
-
Longer iterations
- What candidates pick
- Extending iterations because the team keeps missing its goals.
- Why it looks right
- More time per iteration seems to make goals reachable.
- Why it's wrong
- It hides the cause, such as unplanned work or oversized items, and slows feedback.
Clue to watch for The scenario mentions interruptions, support requests or large items.
-
Busy means productive
- What candidates pick
- Starting more items so nobody is idle.
- Why it looks right
- Idle time looks wasteful.
- Why it's wrong
- Higher WIP lengthens cycle time under Little's Law and hides blockers; DA's promise is to keep workloads within capacity.
Clue to watch for Many items in progress, few finished.
-
Leader-only diagnosis
- What candidates pick
- The team lead analyses the problem alone and announces a fix.
- Why it looks right
- It is quick and decisive.
- Why it's wrong
- A shared canvas surfaces perspectives the lead lacks and builds ownership of the change.
Clue to watch for Team members disagree about what the problem is.
-
Switch frameworks
- What candidates pick
- Moving from one method to another to fix slow delivery.
- Why it looks right
- A fresh start promises fresh results.
- Why it's wrong
- Without a diagnosis the same constraint follows the team into the new method.
Clue to watch for Evidence points to one stage, decision or type of work.
-
Metrics first
- What candidates pick
- Rolling out a full metrics dashboard before agreeing what the team wants to learn.
- Why it looks right
- Data sounds objective.
- Why it's wrong
- GQM starts from a goal and questions; unfocused metrics cost effort and can drive the wrong behavior.
Clue to watch for The scenario asks how to measure an improvement, not how to report status.
Answer framework
Use this sequence whenever a question describes a struggling team and asks for the first or best step.
- Make the work visible, including unplanned and support work, so the whole team sees the same picture of what is in progress.
- Build a shared view of context and challenges, for example with the DA Team Canvas, before proposing any change.
- Measure flow with WIP, throughput and cycle time, and locate the stage where work waits longest before moving on.
- Trace the symptom to its root cause by asking why until you reach something the team can change.
- Pick one option from the relevant process goal that targets that cause, set a measure and threshold in advance, and run it as an experiment.
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
Begin with flow, because it gives you evidence for every other step. Learn the definitions of WIP, throughput, cycle time and lead time until you can draw a board and point to each one. Then practise Little's Law with a few simple numbers until predicting the effect of a WIP change takes seconds.
Next, study the DA Team Canvas as a facilitation tool: who builds it, when, and what conversation it is meant to start. Pair it with root-cause practice. Take three common symptoms, such as missed iteration goals, rising defects and long waits for small requests, and trace each to two possible causes and the process goal you would search for each.
Commonly underestimated areas are hidden work, which quietly breaks plans, and the idea that only the bottleneck matters. Afterwards, practise FIRST and BEST step questions, and check that your answer diagnoses before it prescribes. Then move to Accelerating Value Delivery, where your diagnosed problems become a prioritized improvement backlog.
FAQ
What exactly is on the DA Team Canvas?
PMI's public course page describes the canvas only as a tool for diagnosing workflow problems and identifying solutions, without listing its sections. Treat it as a shared one-page view of the team's context and challenges, and use the version provided in the course.
Do I need to calculate anything for this module?
Expect simple flow reasoning at most, such as applying Little's Law to WIP and throughput figures. Understanding the direction of change matters more than precise arithmetic.
Why not just adopt a proven practice right away?
A practice that fixes the wrong problem wastes effort and can hide the real constraint. Diagnosis first makes the chosen option targeted and its effect measurable.
How is this different from a retrospective?
A retrospective is one place where diagnosis happens. This module adds structure: a shared canvas, flow evidence and root-cause analysis, then a link back to DA options.
What if the bottleneck is outside the team?
Make the dependency visible and work with the other team or enterprise group, which is enterprise awareness in action. Local fixes elsewhere will not raise overall flow.
How does this module relate to value acceleration?
The problems diagnosed here become items in the improvement backlog that module 4 builds and prioritizes.
How long should I spend on this module?
Plan for about two to three hours, including a few practice diagnoses from symptom to root cause to process goal.
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 3 knowledge
You have just practised diagnosing team problems with a shared canvas, flow measures and root-cause analysis. Check whether you can spot the real constraint in scenario questions.