Overview
Scenario 2 – Maintenance Team asks you to design a way of working for a team whose demand you cannot plan far ahead. Maintenance teams fix defects, handle small changes and respond to production issues on products already in use. Work arrives continuously and unevenly, items are usually small, and some are urgent enough that waiting for the next iteration would be unacceptable. Those features point toward DA's Lean lifecycle: work pulled from a visible queue within work-in-progress limits, with planning and replenishment held on a regular cadence rather than tied to fixed iterations.
Candidates must understand how to make such a system predictable without forcing it into time-boxes: explicit policies for intake and triage, classes of service for different urgencies, service level expectations based on measured cycle time, and swarming on blockers. The module also asks you to contrast this design with the enhancement team in module 5 and other team types, which is where the context counts principle is tested most directly.
How it's tested
Questions on this module describe a team with unpredictable, often urgent work and ask for the most appropriate lifecycle, policy or response. Expect contrasts with an enhancement or new-product team. The right answer handles urgency without chaos: visible flow, WIP limits, explicit classes of service and expectations based on measured data, not iterations imposed on work that cannot wait.
-
Choose the lifecycle
Demand is unpredictable and items are small, and you choose a flow-based Lean lifecycle over an iteration-based one.
-
Handle the urgent item
A critical production defect arrives, and you choose the response defined by an expedite class of service rather than breaking all limits.
-
Contrast the teams
Two teams are described and you explain why their best WoWs differ, tying each to its context.
A maintenance team runs two-week sprints but abandons its plan most weeks because urgent defects arrive. Ask what the work is like: small, unpredictable and sometimes urgent. Iterations add delay and constant re-planning. The better fit is the Lean lifecycle with WIP limits, an expedite class of service capped at one item, and a regular replenishment meeting. Keeping sprints and simply adding buffer capacity treats the symptom, not the mismatch.
Module topics 2
Official module topics from the PMI outline, in outline order.
6.1 Designing a context-appropriate way of working for a maintenance teamA flow-based design for unpredictable, often urgent work.
- What it means
- The team designs a WoW that matches continuous, uneven demand: typically the Lean lifecycle with a visible board, WIP limits, explicit intake and triage policies, classes of service and a regular replenishment cadence.
- What to understand
- Predictability comes from measuring flow, not from fixing scope per iteration. Use cycle-time data to set service level expectations, such as most standard items finished within five working days, and cap expedited work so urgent items do not swamp everything else.
- How it shows up
- A scenario describes maintenance demand and asks for the most appropriate lifecycle, policy or way to set stakeholder expectations.
- Common confusion
- Believing flow-based means no planning; Lean teams still hold regular replenishment, review and retrospective sessions, just not tied to iterations.
6.2 Contrasting maintenance with other team needsWhy the same organization needs different WoWs.
- What it means
- The module compares the maintenance team with teams such as the enhancement team, whose planned feature work suits iterations, and new-product teams, whose uncertainty may suit the Exploratory lifecycle first.
- What to understand
- Differences in demand pattern, urgency, item size and uncertainty drive different lifecycle and practice choices, while shared governance and milestones keep the organization coherent. A team that both enhances and maintains may need explicit capacity allocation or separate classes of service.
- How it shows up
- Two teams in the same organization are described, and you identify which context factor justifies their different WoWs.
- Common confusion
- Thinking different WoWs across teams means inconsistent governance; DA governs outcomes and milestones, not identical practices.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Maintenance team
A team that keeps a product in use healthy by fixing defects, handling small changes and responding to production issues, with demand that arrives continuously and unpredictably.
- Remember
- Small, uneven, sometimes urgent work is the defining context.
- Tested as
- Recognizing this context is the first step in every question in the module.
- Trap
- Applying an iteration cadence designed for planned feature work.
-
Lean lifecycle
DA's Kanban-based lifecycle in which work is pulled from a queue as capacity frees up, within WIP limits, with meetings held on their own cadence rather than per iteration.
- Remember
- No iterations, but still disciplined: explicit policies, regular replenishment and continuous improvement.
- Tested as
- Usually the most appropriate starting lifecycle for a maintenance team.
- Trap
- Describing it as unplanned or ad hoc.
-
Classes of service
Classes of service are policies that treat work types differently by urgency and cost of delay, commonly expedite, fixed date, standard and intangible.
- Remember
- Expedite items jump the queue but are capped, often to one at a time.
- Tested as
- Appears whenever urgent and routine work compete.
- Trap
- Marking many items as expedite, which makes the class meaningless.
-
Expedite lane
A board lane for genuinely urgent items, such as a production outage, that may exceed normal WIP limits and get immediate attention.
- Remember
- Strict entry criteria and a cap keep it from eroding standard flow.
- Tested as
- The correct way to handle a critical defect in a flow system.
- Trap
- Dropping all WIP limits whenever something urgent arrives.
-
Service level expectation (SLE)
A forecast based on past cycle times, such as 85% of standard items finished within five working days.
- Remember
- It is derived from measured data and stated as a probability, not a promise for every item.
- Tested as
- Used to set stakeholder expectations without fixed iteration commitments.
- Trap
- Quoting average cycle time as a commitment for every item.
-
Replenishment cadence
A regular session where the team and stakeholders choose which queued items to pull next, decoupled from delivery timing.
- Remember
- Planning still happens on a rhythm; delivery happens whenever items finish.
- Tested as
- Answers the 'how do Lean teams plan' question.
- Trap
- Thinking work is chosen ad hoc by whoever shouts loudest.
-
Explicit policies
Written, visible rules for how work enters, moves and leaves the system, such as triage criteria, definitions of done per stage and WIP limits.
- Remember
- Making policies explicit lets the team improve them deliberately.
- Tested as
- Appears when the team argues about which item is next.
- Trap
- Relying on the team lead's judgment each time instead of agreed rules.
-
Swarming
Team members stop starting new work and collaborate on a blocked or urgent item until it moves.
- Remember
- Swarming applies stop starting, start finishing and shortens cycle time for the blocked item.
- Tested as
- A common correct response to a blocked item in a WIP-limited system.
- Trap
- Pulling a new item to stay busy while something stays blocked.
-
Capacity allocation
Reserving a share of a team's capacity for each work type, such as planned enhancements versus unplanned maintenance.
- Remember
- Useful for mixed teams so urgent work does not starve planned work, or the reverse.
- Tested as
- Appears when one team handles both enhancement and maintenance.
- Trap
- Letting maintenance silently consume all capacity, then missing feature commitments.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Maintenance team vs. enhancement team
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Maintenance team | Handles continuous, unpredictable fixes and small requests | Flow-based Lean lifecycle with classes of service usually fits | Forcing urgent defects to wait for the next iteration |
| Enhancement team | Delivers planned new capability on an existing product | Iteration-based Agile lifecycle or continuous delivery often fits | Assuming the maintenance team's flow design suits planned feature work equally well |
Expedite vs. fixed date vs. standard class of service
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Expedite | Urgent work with very high cost of delay, such as an outage | Pulled immediately, capped in number | Overusing it until everything is urgent |
| Fixed date | Work whose value drops sharply after a known date, such as a regulatory change | Scheduled so it finishes before the date | Starting it too late because it is not yet urgent |
| Standard | Routine work with steady cost of delay | Pulled in order under normal WIP limits | Letting it starve behind expedited items |
Iteration commitment vs. service level expectation
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Iteration commitment | Team forecasts a set of items for a time-box | Scope set at planning; fits predictable work | Constant breakage when urgent work arrives mid-iteration |
| Service level expectation | Probabilistic forecast of item cycle time from past data | Set per item type; fits continuous demand | Treating it as a guarantee for every item |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Keep sprints, add buffer
- What candidates pick
- Reserving sprint capacity for interruptions while keeping two-week iterations.
- Why it looks right
- It keeps a familiar structure and seems pragmatic.
- Why it's wrong
- When most work is unplanned, the mismatch remains; a flow-based lifecycle fits the demand pattern directly.
Clue to watch for Most of the team's work arrives unpredictably, not only occasional interruptions.
-
Drop all limits for urgency
- What candidates pick
- Suspending WIP limits whenever an urgent defect arrives.
- Why it looks right
- Urgent work clearly needs attention now.
- Why it's wrong
- An expedite class with a cap handles urgency without collapsing flow for everything else.
Clue to watch for Urgent items arrive regularly, not once in a crisis.
-
Everything is expedite
- What candidates pick
- Letting stakeholders mark their items expedite.
- Why it looks right
- It keeps stakeholders happy.
- Why it's wrong
- If every item is expedite, the class carries no meaning and standard work starves.
Clue to watch for The expedite lane is always full.
-
Promise every item by a date
- What candidates pick
- Committing to finish each request within the average cycle time.
- Why it looks right
- A firm promise sounds reassuring.
- Why it's wrong
- Half of items exceed the average; an SLE stated as a probability from measured data sets honest expectations.
Clue to watch for Stakeholders ask how long a typical request will take.
-
One WoW for consistency
- What candidates pick
- Making the maintenance team adopt the enhancement team's iterations.
- Why it looks right
- Uniform processes look easier to manage.
- Why it's wrong
- Context counts; DA keeps governance consistent through outcomes and milestones, not identical practices.
Clue to watch for The two teams' demand patterns are described differently.
-
Stay busy on new items
- What candidates pick
- Pulling new work while an item is blocked.
- Why it looks right
- Nobody sits idle.
- Why it's wrong
- It raises WIP and cycle time; swarming on the blocker is the flow-friendly response.
Clue to watch for An item has been blocked for days while new work starts.
Answer framework
Use this sequence when a question asks how to design or fix a maintenance team's way of working.
- Describe the demand pattern: arrival rate, predictability, typical item size and how often items are genuinely urgent.
- If demand is continuous and unpredictable, start from the Lean lifecycle with a visible board, explicit policies and WIP limits.
- Define classes of service with explicit entry criteria, capping expedite work so standard and fixed-date work keeps flowing.
- Measure cycle time, set service level expectations as probabilities, and hold regular replenishment sessions with stakeholders to choose what comes next.
- Contrast the design with other teams' contexts, keep governance consistent through shared outcomes and milestones, and improve policies such as WIP limits and triage rules through measured experiments.
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 by describing the maintenance context in your own words: small, uneven, sometimes urgent work on a product people rely on. Then learn the Lean lifecycle as the answer to that context, focusing on what replaces iteration planning: replenishment, WIP limits, explicit policies and service level expectations.
Next, study classes of service carefully, since most urgency questions turn on them. For each class, write one realistic example from a maintenance team and the policy that governs it. Practise setting a service level expectation from a small set of cycle times so the idea of a probabilistic forecast feels concrete.
Commonly underestimated areas are the contrast with other teams, which carries many of the scenario questions, and the discipline of a flow system, which candidates often mistake for no process at all. Afterwards, place your module 5 improvement plan beside a maintenance team plan and list every difference with its context reason. Then move to Exploring More Scenarios, which extends this contrast to complex delivery and non-IT teams.
FAQ
Must a maintenance team use the Lean lifecycle?
No. DA does not mandate it, but continuous, unpredictable demand usually fits a flow-based lifecycle better than fixed iterations. Context decides.
How does a Lean team plan without sprints?
It holds regular replenishment sessions to choose what to pull next, reviews and retrospectives on their own cadence, and uses measured cycle times to forecast.
How should urgent production issues be handled?
Through an expedite class of service with clear entry criteria and a cap, so urgent work starts immediately without collapsing normal flow.
What is a service level expectation?
A forecast from past data, such as 85% of standard items finished within five working days. It sets honest expectations without promising a date for every item.
What if a team does both enhancement and maintenance?
Make both work types visible, use capacity allocation or separate classes of service, and measure each so neither silently consumes the other.
Does using different WoWs across teams break governance?
No. DA keeps governance consistent through shared outcomes, milestones and guardrails while letting each team choose practices suited to its context.
How long should I spend on this module?
Plan for about two to three hours, including writing classes of service and comparing your design with the enhancement team scenario.
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 6 knowledge
You have just designed a flow-based way of working for a maintenance team and contrasted it with other team needs. Test whether you can handle urgency and set expectations in new scenarios.