Overview
Scenario 1 – Enhancement Team applies everything from modules 1 to 4 to one team. An enhancement team evolves a product already in use: it adds features, adjusts behavior and fixes some defects, all on top of an existing codebase with existing users. That context brings particular pressures: regression risk every time something changes, technical debt that slows new work, stakeholders who expect a steady stream of improvements, and releases that must not disrupt people already relying on the product.
Candidates must understand how those pressures shape the right way of working. Planned, prioritizable feature work often suits the Agile lifecycle or, as automation matures, a continuous delivery lifecycle. Practices that protect the existing product, such as automated regression testing, continuous integration and refactoring, become high-value options. The scenario ends with an improvement plan: an ordered set of experiments chosen for this team's context, which module 6 then contrasts with a maintenance team's very different needs.
How it's tested
Questions on this module describe an enhancement team in some detail, then ask for the most appropriate lifecycle, practice or first improvement. Read the context clues carefully: existing users, legacy code, regression problems, release cadence or stakeholder expectations. The right answer fits those clues and is realistic for the team now, and it usually protects the existing product while speeding delivery of new value.
-
Fit the lifecycle
The team's work pattern and automation maturity are described, and you choose between the Agile lifecycle and a continuous delivery lifecycle.
-
Protect what exists
A change keeps breaking existing functionality, and you pick the practice that reduces regression risk, such as automated regression tests.
-
First item in the plan
Several improvements are listed and you choose the one that addresses this team's largest constraint first.
An enhancement team releases every quarter because each release needs two weeks of manual regression testing, and stakeholders want features sooner. Ask what constrains release frequency: manual regression effort. The first improvement is to automate the most-used regression paths and integrate continuously, measured by regression time per release. Shortening iterations alone would not help, because each release would still carry the same two-week manual test.
Module topics 3
Official module topics from the PMI outline, in outline order.
5.1 Understanding the enhancement team's contextWhat makes enhancing an existing product different.
- What it means
- An enhancement team adds and changes features on a product already in use, so its context includes an existing codebase, existing users, regression risk, accumulated technical debt and stakeholders expecting continuing improvements.
- What to understand
- Context factors such as team size, skills, codebase quality, release constraints and compliance determine which options fit. Capture them with the Team Canvas before choosing anything, because the same feature request costs more on fragile code.
- How it shows up
- A scenario lists details about the product and team, and you identify which detail should drive the next decision.
- Common confusion
- Treating enhancement work as greenfield development and ignoring existing users and regression risk.
5.2 Applying the knowledge base and value acceleration processChoosing options and improvements for this team.
- What it means
- The team maps its diagnosed problems to process goals such as Improve Quality, Accelerate Value Delivery and Evolve WoW, compares options in the DA Browser, and uses the value acceleration process and Quick Starts to list candidate improvements.
- What to understand
- High-value options for enhancement teams typically protect the existing product while speeding change: automated regression testing, continuous integration, refactoring as part of the work, and smaller, more frequent releases. Choose among them by the team's largest constraint.
- How it shows up
- A problem such as frequent regressions or slow releases is described, and you choose the option whose trade-offs fit this team.
- Common confusion
- Choosing an option because it is advanced, such as continuous deployment, before the automated testing it depends on exists.
5.3 Creating an improvement planAn ordered set of experiments with measures.
- What it means
- The improvement plan is the team's ordered improvement backlog for the near term: a few experiments, each with its expected effect, measure and review point.
- What to understand
- A good plan addresses the biggest constraint first, limits how many experiments run at once, reserves capacity for improvement, and states when the team will review results and re-plan.
- How it shows up
- You are asked which plan or first experiment is most appropriate for a described enhancement team.
- Common confusion
- Writing a plan as a list of practices to adopt rather than experiments with measures.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Enhancement team
A team that evolves an existing product in production by adding features, changing behavior and fixing some defects, rather than building a new product from scratch.
- Remember
- Existing users, existing code and regression risk are always part of its context.
- Tested as
- Every question in this module depends on recognizing these context features.
- Trap
- Answering as if the team were building a new product.
-
Regression risk
The risk that a change breaks functionality that already worked, which grows with codebase size and the amount of manual testing.
- Remember
- Automated regression tests run on every change are the main control.
- Tested as
- Frequent breakage in scenarios points here.
- Trap
- Adding more manual test phases, which slows releases without scaling.
-
Technical debt
Technical debt is the accumulated cost of shortcuts in code and design that makes each future change slower and riskier.
- Remember
- Pay it down continuously as part of feature work, through refactoring, rather than in a one-off rewrite.
- Tested as
- Appears when new features take longer and longer to deliver.
- Trap
- Proposing a full rewrite, which stops value delivery and carries large risk.
-
Continuous integration (CI)
Team members integrate their changes into a shared mainline frequently, with an automated build and tests run on each integration.
- Remember
- CI finds integration and regression problems within hours instead of at release time.
- Tested as
- A common first improvement for enhancement teams with late integration pain.
- Trap
- Thinking a nightly manual merge counts as continuous integration.
-
Refactoring
Refactoring improves the internal structure of code without changing its external behavior, protected by automated tests.
- Remember
- Refactor in small steps as part of normal work; tests make it safe.
- Tested as
- Appears with technical debt and slowing velocity.
- Trap
- Refactoring without tests, which turns cleanup into new defects.
-
Agile vs. continuous delivery lifecycle choice
Teams with planned, prioritizable feature work often start with the Agile lifecycle; teams with strong automation can move to Continuous Delivery: Agile or Continuous Delivery: Lean and release far more often.
- Remember
- Continuous delivery lifecycles depend on mature automated testing and deployment.
- Tested as
- Lifecycle questions turn on automation maturity and release frequency.
- Trap
- Choosing continuous delivery for a team that still tests manually.
-
Release cadence
How often new versions reach users, constrained by testing effort, deployment process and how much change users can absorb.
- Remember
- Smaller, more frequent releases carry less risk each, if the release process is automated.
- Tested as
- Scenarios ask how to release sooner without disrupting users.
- Trap
- Assuming a bigger, rarer release is safer.
-
Feature toggles
Feature toggles let incomplete or risky features be deployed but switched off, separating deployment from release to users.
- Remember
- They allow frequent integration and deployment while controlling exposure.
- Tested as
- Appears when a team must merge often but cannot show unfinished work.
- Trap
- Leaving old toggles in place indefinitely, which adds technical debt.
-
Improvement plan
An ordered, near-term set of improvement experiments for a specific team, each with an expected effect, a measure and a review point.
- Remember
- Biggest constraint first, few experiments at a time, review and re-plan.
- Tested as
- The output the scenario asks you to produce.
- Trap
- Listing many practices to adopt with no order or measure.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Enhancement team vs. new product team
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Enhancement team | Evolves a product already in use | Must protect existing users and code; regression risk and technical debt shape choices | Ignoring existing users when choosing release practices |
| New product team | Builds a solution that does not yet exist | Faces vision, scope and architecture uncertainty more than regression risk | Copying its lengthier Inception activities into an enhancement context |
Refactoring vs. rewrite
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Refactoring | Small structural improvements, behavior unchanged, protected by tests | Continuous and low risk; value delivery continues | Doing it without automated tests |
| Rewrite | Replacing the codebase with a new one | Large, risky and pauses new value for months | Choosing it as the first response to technical debt |
Manual regression testing vs. automated regression testing
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Manual regression testing | People re-test existing features before each release | Effort grows with the product and limits release frequency | Adding more manual test time to fix regressions |
| Automated regression testing | Tests run automatically on every change | Fast, repeatable feedback that enables frequent release | Trying to automate everything at once instead of the most-used paths first |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Rewrite the product
- What candidates pick
- Starting a full rewrite because the code is hard to change.
- Why it looks right
- A clean codebase sounds like the permanent fix.
- Why it's wrong
- A rewrite halts new value for months and carries large risk; DA favors incremental refactoring protected by tests.
Clue to watch for Stakeholders still need features while the debt is addressed.
-
Jump to continuous deployment
- What candidates pick
- Moving straight to a continuous delivery lifecycle.
- Why it looks right
- It is the most advanced and fastest option.
- Why it's wrong
- Without automated testing and deployment, frequent releases multiply regressions.
Clue to watch for The scenario mentions manual testing or manual deployment.
-
More manual testing
- What candidates pick
- Adding a longer manual test phase after regressions escape.
- Why it looks right
- More testing sounds safer.
- Why it's wrong
- It slows every release and still does not scale with product size; automation of key paths is the sustainable fix.
Clue to watch for Regression effort grows release after release.
-
Ignore existing users
- What candidates pick
- Releasing large changes as soon as they are built.
- Why it looks right
- Faster release sounds like faster value.
- Why it's wrong
- Existing users need stability; techniques such as feature toggles and small releases manage exposure.
Clue to watch for The product has many active users or critical workflows.
-
Plan without order
- What candidates pick
- An improvement plan that starts six practices at once.
- Why it looks right
- It looks comprehensive.
- Why it's wrong
- Too many simultaneous experiments overload the team and hide which change worked.
Clue to watch for Limited team capacity or a single dominant constraint.
-
Copy another team
- What candidates pick
- Adopting the WoW of a successful new-product team.
- Why it looks right
- It already works in the organization.
- Why it's wrong
- Context counts: that team does not carry the regression risk and existing users this team does.
Clue to watch for The scenario contrasts the two teams' work.
Answer framework
Use this sequence when a question asks how to tailor or improve an enhancement team's way of working.
- List the context clues: existing users, codebase condition, test automation, release constraints, team skills and compliance needs.
- Identify the constraint that most limits safe, frequent delivery, often manual regression testing, manual deployment or technical debt in heavily changed areas.
- Find options in the relevant process goal and prefer those that protect the existing product while speeding change.
- Check that each option's prerequisites exist, such as automated tests before continuous delivery; if not, the prerequisite becomes the first improvement.
- Write a short improvement plan with the biggest constraint first, a measure for each experiment, limited parallel work, reserved capacity and a review date.
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
Treat this module as a rehearsal of the whole course on one team. Start by listing the context clues that define an enhancement team and, for each one, the decision it affects: existing users affect release practices, codebase condition affects refactoring and testing, automation maturity affects lifecycle choice.
Next, walk the scenario in order: capture context, diagnose the main constraint, look up options in the relevant process goals, and build a three-to-five item improvement plan. Write a measure beside each item, such as regression testing days per release or escaped defects per month. Doing this once on paper teaches more than rereading the scenario.
Commonly underestimated areas are prerequisites, since advanced options fail without the automation beneath them, and the stability needs of existing users. Afterwards, practise questions that ask for the FIRST improvement and justify each answer by the constraint it removes. Then move to the maintenance team scenario and note every point where your answer changes.
FAQ
What is the difference between an enhancement team and a maintenance team?
An enhancement team mostly delivers planned new capability on an existing product; a maintenance team mostly handles unpredictable fixes and small requests. Module 6 explores how that difference changes the right way of working.
Which lifecycle should an enhancement team use?
There is no single answer. Planned, prioritizable feature work often starts on the Agile lifecycle, and teams with mature automation can move to a continuous delivery lifecycle.
Why is test automation such a frequent answer here?
Manual regression testing grows with the product and limits how often a team can safely release. Automating the most-used paths removes that constraint and enables later improvements.
Should technical debt be fixed before new features?
Usually neither all first nor ignored. DA favors paying it down continuously through refactoring as part of feature work, focusing on the areas that slow change most.
What makes a good improvement plan?
A few ordered experiments targeting the biggest constraint first, each with a measure and a review date, within a capacity the team can sustain.
Do scenario questions have one right answer?
Practice questions are written so one answer fits the stated context best. Look for the clue that rules out the other options, such as manual testing ruling out continuous deployment.
How long should I spend on this scenario?
Plan for about two to three hours, including building your own short improvement plan for the described team.
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 5 knowledge
You have just tailored a way of working and an improvement plan for an enhancement team. Test whether you can pick the right lifecycle and first improvement in new scenarios.