Up next in 10
150 Agile Questions & Review: #21-30 (Agile Frameworks)
Aug 19, 2025
This is the third video in our 15-part Agile Review & Question series, designed to help you master Agile concepts and prepare for the PMP® exam. In this video, we focus on the most widely used Agile frameworks — Scrum, Kanban, Extreme Programming (XP), Feature-Driven Development (FDD), Dynamic Systems Development Method (DSDM), and Agile Unified Process (AgileUP). You’ll reinforce your understanding through 10 practice questions (Questions 21 to 30) with detailed explanations. ✅ You’ll learn how to: • Apply Agile frameworks in real-world project scenarios • Differentiate between Scrum, Kanban, XP, FDD, DSDM, and AgileUP • Identify the correct PMI-aligned choice among plausible options • Strengthen your Agile knowledge for both the PMP exam and the workplace By practicing with scenario-based questions, you’ll not only remember the frameworks, you’ll know how to apply them effectively under exam conditions. Chapters: 0:00 Agile Frameworks Overview 5:00 Question 21 7:15 Question 22 9:15 Question 23 11:24 Question 24 13:32 Question 25 15:38 Question 26
View Video Transcript
0:00
Now that we've talked about agile
0:01
mindset and principles, let's take a
0:03
closer look at how agile is actually
0:06
implemented through frameworks and
0:08
approaches that teams used to plan,
0:10
build, and deliver value. In this topic,
0:12
we'll cover the most widely used
0:14
nonscaled agile frameworks, including
0:17
scrum, conbon, extreme programming,
0:20
feature-driven development, dynamic
0:22
systems development method, and agile
0:24
unified process. The PMP exam expects
0:27
you to understand what each of these
0:28
frameworks is designed for, how they
0:31
differ, and when to use them. Not to
0:33
memorize every detail, but to apply the
0:35
concepts in realistic project scenarios.
0:38
Let's start with scrum, the most popular
0:41
agile framework. You'll want to be
0:43
familiar with the three roles. The scrum
0:45
master is the servant leader who removes
0:48
obstacles and helps the team follow
0:50
agile principles. The product owner is
0:53
responsible for maximizing value by
0:56
managing the product backlog. The
0:58
developers are a self-managing team who
1:00
plan and deliver the work during the
1:02
sprint. Scrum uses fixedlength time box
1:06
sprints typically ranging from 1 to four
1:09
weeks long where teams deliver a usable
1:11
product increment. Key scrum events
1:14
include sprint planning to define the
1:17
goal and select backlog items. Daily
1:20
scrum or standup for team coordination,
1:23
sprint review to gather feedback, and
1:26
sprint retrospective to reflect and
1:28
improve the process. The core artifacts
1:30
are the product backlog which holds all
1:32
desired features prioritized by the
1:34
product owner and the sprint backlog
1:36
which contains the selected work for the
1:38
current sprint. You'll also want to
1:40
understand the definition of done which
1:42
sets the standard for when work is
1:44
considered complete.
1:46
Next, let's look at Conbon, a flow-based
1:49
agile method that focuses on visualizing
1:51
work, limiting work in progress, and
1:54
improving flow efficiency. Unlike Scrum,
1:56
Conbon doesn't use sprints or time
1:58
boxes. Instead, teams use a conbon board
2:01
to track work as it moves through stages
2:03
like to-do, in progress, and done. This
2:06
helps identify bottlenecks and manage
2:07
work more effectively. The key concept
2:10
in conbon is setting work in progress
2:12
limits which prevents overload and
2:14
encourages teams to finish work before
2:16
starting new tasks. Work is delivered
2:19
continuously and teams track metrics
2:21
like cycle time and throughput to
2:23
improve predictability. Conbon is
2:25
lightweight and flexible. It doesn't
2:27
introduce new roles or ceremonies making
2:29
it easy to apply within existing
2:31
workflows for the exam. Be ready for
2:33
questions about visualizing flow work in
2:36
progress limits and incremental
2:37
improvement.
2:39
The next one is extreme programming. XP
2:42
is one of the most technically
2:43
disciplined agile frameworks. It's
2:45
designed to improve software quality and
2:48
responsiveness to change through a set
2:50
of engineering best practices. These
2:52
include pair programming, test-driven
2:54
development, continuous integration,
2:56
refactoring, and maintaining a simple
2:58
design. XP values frequent releases,
3:01
customer involvement, and collective
3:02
code ownership. It's especially useful
3:05
when requirements are expected to change
3:07
rapidly and technical quality is a top
3:10
priority. Another framework to know is
3:13
feature-driven development. FDDD is a
3:15
modeldriven architecture ccentric
3:17
process that focuses on delivering
3:19
tangible working software in the form of
3:22
features which are small client valued
3:24
functions. It follows a five-step
3:26
process. Develop an overall model, build
3:28
a features list, plan by feature, design
3:31
by feature and build by feature. FDD
3:34
emphasizes strong upfront design, domain
3:36
modeling, and frequent short iterations.
3:39
While it's more prescriptive than other
3:41
agile approaches, it works well in
3:43
larger teams that benefit from a clear
3:45
structure. You should also be familiar
3:47
with dynamic systems development method,
3:49
DSDM, emphasizing delivering on time and
3:52
within budget by fixing schedule and
3:54
cost while allowing scope to vary. One
3:57
of its signature practices is Moscow
3:59
prioritization, which stands for must
4:02
have, should have, could have, and won't
4:05
have. A structured way to prioritize
4:07
requirements based on business value.
4:09
DSDM also promotes active user
4:11
involvement in frequent delivery with
4:14
clearly defined roles and strong
4:15
governance. Another framework you may
4:17
encounter is agile unified process or
4:20
agile up. It adapts the rational unified
4:23
process to be more agile by focusing on
4:26
iterative development, discipline, team
4:28
roles, and producing just enough
4:30
documentation. Agile upbreaks work into
4:32
phases like inception, elaboration,
4:35
construction, and transition, but
4:37
applies agile practices like time boxing
4:40
and evolving requirements throughout.
4:42
It's especially useful in environments
4:43
that require structure, but still want
4:45
to stay responsive to change. Now, we'll
4:48
go through 10 agile practice questions
4:50
that will challenge your knowledge of
4:52
framework mechanics, team roles,
4:54
engineering practices, delivery flow,
4:56
and feedback loops in fastm moving agile
4:59
environments. Let's get started with our
5:01
next question. Question 21. A scrum team
5:05
has completed three sprints delivering
5:07
working increments each time. However,
5:09
the product owner reports that
5:11
stakeholders still seem unclear about
5:13
the overall project direction and worry
5:15
the team may be building functionality
5:16
that will not meet end-user
5:18
expectations. The team feels confident
5:20
in their process and delivery pace. What
5:23
is the most appropriate response? A.
5:26
Encourage the product owner to provide
5:28
more detailed acceptance criteria and
5:30
scope definitions before sprint
5:32
planning. B. Recommend that the product
5:34
owner engage stakeholders to gather
5:37
feedback and revalidate backlog
5:39
priorities.
5:40
C. Suggest adding a formal stakeholder
5:43
review midway through each sprint to
5:44
verify the team is on track. D. Ask the
5:48
team to increase velocity by delivering
5:50
more features per sprint to build
5:52
stakeholder confidence. You can pause
5:54
the video here if you need more time to
5:56
work on the question. The correct answer
5:58
is B. This question is testing your
6:01
ability to assess how Scrum supports
6:03
transparency, stakeholder engagement,
6:05
and feedbackdriven iteration. Even when
6:07
a Scrum team is delivering working
6:09
software, stakeholders may still feel
6:11
disconnected if the feedback loop isn't
6:13
strong enough. The best way to fix that
6:15
isn't more documentation or speed, it's
6:17
more meaningful collaboration. Choice B
6:20
encourages the product owner to actively
6:22
reconnect with stakeholders, gather
6:24
feedback, and use that insight to
6:26
refocus backlog priorities. It respects
6:29
team autonomy while strengthening
6:31
alignment. Choice A is incorrect. It
6:34
focuses too much on upfront scope detail
6:37
which is more predictive than agile.
6:39
Scrum teams expect evolving
6:41
requirements, not fully locked ones.
6:44
Voice C is incorrect. It introduces a
6:46
formal stakeholder checkpoint mid-sprint
6:49
which breaks Scrum's cadence. Scrum
6:51
already includes a sprint review for
6:53
stakeholder feedback and mid-sprint
6:55
interventions risk disrupting flow.
6:58
Choice D is incorrect. It assumes that
7:01
faster delivery will solve the alignment
7:03
issue. But increasing velocity for the
7:05
sake of perception undermines
7:07
sustainable pace and does nothing to
7:09
address stakeholder concerns about
7:11
value. Let's move on to the next
7:14
question if you're ready. Question 22.
7:17
Midway through a sprint, a team member
7:19
asks the scrum master to reassign a
7:22
user's story to another developer
7:23
because they feel it's outside their
7:25
expertise and don't want to risk
7:27
delaying the sprint goal. The scrum
7:28
master agrees and begins rearranging the
7:31
assignments to balance the workload.
7:33
What should the project manager do? A
7:36
support the scrum master's decision to
7:38
reassign tasks, ensuring the team meets
7:41
the sprint commitment. B. Advise the
7:44
scrum master that the team should
7:46
self-organize and collectively decide
7:48
how to handle the user story. C. Ask the
7:51
product owner to update the backlog and
7:53
create a new task that better matches
7:55
each team member's skill set.
7:58
D. Recommend holding a mid-sprint
8:01
planning session to redistribute work
8:03
based on availability and expertise. You
8:07
can pause the video here if you need
8:08
more time to work on the question. The
8:11
correct answer is B. This question is
8:13
testing your understanding of scrum team
8:15
structure, especially around the
8:17
principle of self-organization. Scrum
8:19
teams are self-managing, meaning they
8:22
decide how to deliver the work without
8:23
micromanagement or top- down task
8:25
assignments. Choice B is the best option
8:29
because it encourages the scrum master
8:30
to empower the team, not take control.
8:33
Rather than reassigning work, the team
8:35
should discuss the issue and decide
8:37
together how to move forward. Choice A
8:40
is incorrect. While it might sound
8:42
reasonable, it reinforces the wrong
8:44
behavior. The scrum master isn't a task
8:46
manager. Their role is to facilitate,
8:48
not direct. Choice C is incorrect. It
8:51
involves the product owner whose
8:52
responsibility is managing the what, not
8:55
the how. They don't assign or tailor
8:57
tasks to individual team members. Choice
9:00
D is incorrect. It introduces a
9:02
mid-sprint planning session which
9:04
disrupts the cadence and violates
9:06
Scrum's respect for the sprint
9:08
structure. Planning happens at the start
9:11
and a team adapts within the sprint.
9:14
Let's move on to the next question if
9:15
you're ready. Question 23. During a
9:19
sprint review, stakeholders express
9:21
concern that some key features
9:23
demonstrated do not align with current
9:25
market needs. They propose changes that
9:27
could significantly impact the next
9:29
sprint. The product owner wants to
9:31
incorporate the feedback, but the
9:32
developers are unsure how to adjust
9:34
their work without disrupting the sprint
9:36
process. What is the most appropriate
9:39
action for the team? A. Schedule an
9:43
additional backlog refinement session
9:45
during the current sprint to rep
9:47
prioritize work mid-sprint. B. Review
9:50
the stakeholder feedback during the
9:52
retrospective to identify ways to
9:54
improve stakeholder alignment. C. Use
9:57
the upcoming sprint planning session to
9:59
incorporate the feedback and adjust the
10:01
backlog accordingly. D. Invite
10:04
stakeholders to attend the next daily
10:05
scrum to help clarify their expectations
10:07
and promote transparency. You can pause
10:10
the video here if you need more time to
10:12
work on the question. The correct answer
10:14
is C. This question tests your
10:17
understanding of scrum events,
10:19
particularly how to incorporate
10:21
stakeholder feedback without disrupting
10:23
the current sprint. Scrum encourages
10:25
adaptation but within the boundaries of
10:28
its structured cadence. The sprint
10:30
planning session is the appropriate
10:32
event to evaluate new insights and
10:34
adjust the backlog in a focused and
10:36
timeboxed way. Using sprint planning to
10:39
respond to stakeholder concerns allows
10:42
the product owner and team to
10:43
collaboratively realign priorities
10:46
without compromising the current sprint
10:47
goal or breaking the rhythm of delivery.
10:50
It upholds scrum's balance of
10:51
flexibility and discipline. Choice A is
10:54
incorrect. It suggests mid-sprint rep
10:57
prioritization which violates the
10:59
principle of sprint commitment and
11:00
introduces instability. Choice B is
11:03
incorrect. The retrospective is focused
11:05
on process improvement not on backlog
11:08
refinement or stakeholder alignment.
11:10
Choice D is incorrect. The daily scrum
11:13
is meant for the development team only
11:15
including stakeholders disrupts its
11:17
purpose and breaks the team's autonomy
11:20
and focus. Let's move on to the next
11:22
question if you're ready. Question 24.
11:26
During a mid-sprint sync, the product
11:28
owner notices that several backlog items
11:30
marked as done by the team are missing
11:32
key documentation and integration
11:34
testing. The team argues that the items
11:36
meet their definition of done and that
11:38
documentation can be added later. What
11:40
should the project manager do? A propose
11:43
reviewing the definition of done during
11:45
the next retrospective to identify
11:47
documentation and testing gaps. B.
11:51
Recommend that the scrum master revise
11:53
the team's workflow to include
11:54
documentation as a required final task.
11:58
C. Encourage the product owner to
12:00
clarify documentation expectations with
12:02
each developer during backlog
12:03
refinement. D. Work with the scrum
12:06
master and team to revisit and clarify
12:08
the definition of done to ensure shared
12:10
understanding. You can pause the video
12:12
here if you need more time to work on
12:14
the question. The correct answer is D.
12:17
This question is testing your
12:19
understanding of how scrum promotes
12:21
transparency through welldefined
12:23
artifacts, especially the definition of
12:25
done. A shared understanding of what
12:28
done means is essential for ensuring
12:30
quality and consistency. If there's
12:33
misalignment or conflicting
12:34
interpretations that signals the need
12:37
for clarification. Working with the
12:39
scrum master and team to revisit and
12:41
align on the definition of done helps
12:43
ensure that everyone is on the same page
12:45
regarding documentation, testing, and
12:48
completion criteria. This collaborative
12:50
approach reinforces quality without
12:53
assigning blame. Choice A is incorrect,
12:56
waiting until the retrospective delays
12:58
resolution of a known quality issue when
13:00
it should be addressed promptly to avoid
13:02
recurring problems. Choice B is
13:04
incorrect. It places responsibilities
13:06
solely on the scrum master to revise the
13:09
workflow which contradicts the
13:11
teamdriven nature of scrum. The scrum
13:13
master facilitates they don't dictate
13:16
process steps. Choice C is incorrect. It
13:19
inappropriately places responsibility on
13:22
the product owner to manage team level
13:23
execution details. The team owns the
13:26
definition of done, not the product
13:28
owner. Let's move on to the next
13:30
question if you're ready. Question 25. A
13:34
conbon team has recently implemented a
13:36
work in progress limit of three items
13:38
per workflow state. However, team
13:40
members are frequently starting new work
13:43
instead of helping to finish items
13:44
already in progress, causing delays and
13:47
uneven flow. What should the project
13:50
manager do? A increase the work in
13:53
progress limit to accommodate the team's
13:55
preference for multitasking.
13:57
B. Ask the team to review how work in
14:00
progress limits are supporting
14:01
collaboration and flow. C. Assign
14:04
specific team members to monitor and
14:06
enforce work in progress limits daily.
14:09
D. Have each team member complete their
14:11
own tasks until all current tasks are
14:14
complete. You can pause the video here
14:17
if you need more time to work on the
14:19
question. The correct answer is B. This
14:22
question tests your understanding of
14:24
conbon principles, particularly how work
14:26
in progress limits are used to improve
14:28
flow and promote team collaboration.
14:31
When team members start new work instead
14:33
of finishing what's already in progress,
14:36
it leads to delays, bottlenecks, and
14:39
uneven workflow, defeating the purpose
14:42
of work in progress limits. Choice B is
14:45
the best option because it asks the team
14:47
to reflect on how their workin progress
14:49
limits are supporting collaboration and
14:51
flow. This aligns with conbon's emphasis
14:54
on inspect and adapt thinking where the
14:56
team takes ownership of improving its
14:58
own system based on real observations
15:00
and outcomes. Choice A is incorrect.
15:03
Increasing the work in progress limit
15:05
undermines the whole purpose of having
15:07
limits in the first place. It encourages
15:10
multitasking and prolongs delivery
15:12
cycles. Choice C is incorrect. Assigning
15:16
team members to enforce work in progress
15:18
limits daily introduces a command and
15:20
control approach that contradicts
15:22
conbon's philosophy of decentralized
15:24
decision-making and team ownership.
15:27
Choice D is incorrect. It promotes
15:29
individual task ownership instead of
15:31
encouraging the team to swarm on
15:33
unfinished work which is essential for
15:35
improving flow and completing tasks
15:37
efficiently in conbon. Let's move on to
15:40
the next question if you're ready.
15:42
Question 26. A development team using
15:45
extreme programming practices is
15:47
struggling with frequent integration
15:48
conflicts and unstable builds. Team
15:50
members are committing code at the end
15:52
of the day without coordination. What
15:54
should the project manager do to improve
15:56
integration stability? A. Encourage the
16:00
team to pair program only during
16:02
high-risk features to save time. B.
16:04
Introduce test-driven development to
16:06
identify conflicts earlier. C. implement
16:10
continuous integration and require
16:11
multiple daily commits. D. Ask the scrum
16:16
master to assign specific integration
16:18
windows for each developer. You can
16:21
pause the video here if you need more
16:22
time to work on the question. The
16:24
correct answer is C. This question tests
16:27
your understanding of extreme
16:29
programming engineering practices,
16:31
particularly around maintaining
16:33
integration stability. Frequent
16:35
integration conflicts and unstable
16:37
builds are classic signs that the team
16:39
is not integrating code regularly
16:41
enough, which hinders rapid feedback and
16:44
increases rework. Choice C is the best
16:47
option because it recommends
16:49
implementing continuous integration. A
16:52
core XP practice that involves
16:54
integrating code multiple times a day
16:56
and running automated tests with each
16:58
commit. This ensures that issues are
17:00
caught early and the codebase remains
17:02
stable, which is vital for high quality
17:04
incremental delivery. Choice A is
17:07
incorrect. Pair programming only during
17:09
high-risk features dilutes one of XP's
17:11
fundamental practices. Pairing is meant
17:13
to be applied consistently, not
17:15
selectively. Choice B is incorrect.
17:18
While test-driven development is
17:19
valuable for improving code quality and
17:22
test coverage, it does not directly
17:24
address the issue of integration timing
17:26
and coordination. Choice D is incorrect.
17:29
Assigning specific integration windows
17:31
creates a top- down structure that
17:33
limits collaboration and agility. XP
17:35
favors a shared continuous integration
17:37
approach, not rigid scheduling. Let's
17:40
move on to the next question if you're
17:42
ready. Question 27. An agile coach
17:45
observes that a team following XP values
17:48
rarely reflects on feedback from
17:49
customers and relies heavily on upfront
17:52
planning. As a result, the product is
17:54
not evolving to meet user needs. What
17:57
should the project manager do? A
17:59
recommend simplifying documentation to
18:02
focus on executable specifications.
18:05
B. Introduce weekly customer demos to
18:07
gather early feedback and guide
18:09
development. C. Invite customers to
18:12
submit feedback via surveys before
18:14
starting each release. D. Schedule
18:17
customer walkthroughs during project
18:19
planning to finalize detailed
18:21
requirements. You can pause the video
18:24
here if you need more time to work on
18:25
the question. The correct answer is B.
18:29
This question tests your understanding
18:31
of extreme programming values,
18:33
especially the importance of customer
18:35
feedback and responsiveness to change.
18:37
The team in this scenario is relying too
18:40
heavily on upfront planning and not
18:42
engaging users frequently, which limits
18:45
their ability to adapt the product based
18:47
on evolving needs. Choice B is the best
18:50
option because it recommends introducing
18:52
weekly customer demos which creates a
18:55
regular opportunity to gather early
18:57
feedback. This aligns directly with XP's
19:00
emphasis on continuous collaboration
19:02
with the customer and ensures the
19:04
product evolves in line with real world
19:06
usage and expectations.
19:08
Choice A is incorrect. Simplifying
19:10
documentation supports XB's value of
19:13
simplicity, but it doesn't address the
19:15
core issue, which is the lack of
19:17
customer input during development.
19:19
Choice C is incorrect. Collecting
19:22
surveys before each release introduces
19:24
delayed feedback and lacks the
19:26
immediiacy and interactivity that XP
19:29
promotes. Choice D is incorrect.
19:33
Scheduling walkthroughs during upfront
19:35
planning reinforces a predictive mindset
19:38
which runs counter to XP's adaptive
19:41
feedbackdriven approach. Let's move on
19:44
to the next question if you're ready.
19:46
Question 28. A product development team
19:49
is working in an environment that
19:51
emphasizes modeling, planning, and
19:53
delivering features every few days. The
19:56
team is organized around delivering
19:58
business value in small functional
20:00
increments. Stakeholders want visibility
20:02
into both planning and results. What
20:05
should the project manager emphasize to
20:07
align with FDD practices? A. Organize
20:11
work around client value features and
20:13
deliver them iteratively. B. Prioritize
20:16
responding to change over following a
20:18
detailed upfront design. C. Use feature
20:22
burndown charts to track delivery
20:24
progress and performance. D. Focus on
20:27
achieving team consensus before modeling
20:30
or designing features. You can pause the
20:32
video here if you need more time to work
20:34
on the question. The correct answer is
20:37
A. This question is testing your
20:40
understanding of feature-driven
20:41
development which emphasizes delivering
20:44
small client valued features
20:46
iteratively. FDD blends modeling and
20:49
planning with regular meaningful output
20:51
giving stakeholders visibility into both
20:54
design and delivery. Choice A is the
20:57
best option because it reflects the core
20:59
of FDDD, organizing work around features
21:01
that deliver business value and
21:03
delivering them in a structured
21:05
iterative manner. This practice ensures
21:07
that planning and progress stay tightly
21:10
linked to stakeholder priorities. Choice
21:12
B is incorrect. While responding to
21:15
change is a key agile value, FDD is more
21:18
model and designdriven than frameworks
21:20
like Scrum or XP. It favors some upfront
21:24
structure over pure adaptability. Choice
21:27
C is incorrect. Feature burndown charts
21:29
are not a standard FDD artifact. While
21:32
tracking progress is important, this
21:33
choice leans more towards scrum style
21:35
monitoring than true FDD practice.
21:38
Choice D is incorrect. Requiring team
21:41
consensus before modeling can slow down
21:43
progress and is not specific to FDD.
21:45
FDDD relies on subject matter experts
21:48
and class owners, not full team
21:50
consensus, to lead design efforts.
21:51
efficiently. Let's move on to the next
21:54
question if you're ready. Question 29. A
21:58
project team is working under tight
21:59
budget and timeline constraints. Senior
22:01
stakeholders have requested several new
22:03
features during delivery, putting
22:05
pressure on the schedule. The team
22:06
follows the dynamic systems development
22:08
method to ensure delivery remains on
22:10
track. What should the project manager
22:12
do first to stay aligned with DSDM
22:15
principles? A. Reassess the schedule and
22:18
adjust the delivery milestones to
22:20
accommodate new requests. B. Organize a
22:23
formal change control board to review
22:26
and approve the new features. C. Apply
22:29
Moscow prioritization and collaborate
22:31
with stakeholders to defer lower
22:33
priority features. D. Recommend adding a
22:37
short iteration to explore feasibility
22:40
before adjusting the plan. You can pause
22:43
the video here if you need more time to
22:44
work on the question. The correct answer
22:46
is C. This question is testing your
22:49
ability to apply the principles of DSDM
22:52
in a constrained project environment.
22:54
DSDM assumes that time and cost are
22:56
fixed. So the way to handle changing
22:58
demands is by adjusting scope, not
23:01
deadlines or budget. The core technique
23:03
used in DSDM is Moscow prioritization,
23:06
which ensures that must-have items are
23:08
delivered while could have or should
23:10
have items may be deferred if needed.
23:12
Choice C is the best option because it
23:14
directly applies Moscow prioritization
23:17
and encourages stakeholder
23:19
collaboration, both of which are aligned
23:21
with DSDM principles and help maintain
23:23
delivery discipline. Choice A is
23:26
incorrect. In DSTM, adjusting the
23:29
schedule undermines the fixed time box
23:32
principle. The framework is built on
23:34
predictable timelines and budgets.
23:37
Choice B is incorrect. While governance
23:40
is important, DSDM emphasizes active
23:43
stakeholder involvement and lightweight
23:45
processes over formal change control
23:48
structures. Choice D is incorrect.
23:51
Adding an iteration could stretch the
23:53
timeline or impact delivery cost, which
23:56
contradicts DSDM's emphasis on fixed
23:59
time and cost. Let's move on to the next
24:02
question if you're ready. Question 30. A
24:05
project manager is leading an agile team
24:08
that must meet internal audit standards,
24:10
maintain traceability across iterations,
24:13
and support post-release maintenance.
24:15
The team values agility but faces
24:18
pressure to align with organizational
24:20
policies and quality gates. What is the
24:23
most appropriate approach for the
24:25
project manager to take? A. Adopt agile
24:29
unified process to tailor agile
24:31
practices while meeting compliance
24:33
needs. B. Use Scrum with minor
24:36
adaptations and document deviations
24:38
separately for audits. T. Apply
24:41
feature-driven development to focus on
24:43
rapid delivery of prioritized features.
24:46
D. Use DSDM to fix cost and time while
24:49
allowing flexibility in scope delivery.
24:52
You can pause the video here if you need
24:54
more time to work on the question. The
24:57
correct answer is A. This question
25:00
assesses your ability to apply agile in
25:02
regulated or structured environments
25:04
where compliance, traceability, and
25:07
governance are essential. In these
25:09
contexts, teams often need more than
25:11
lightweight frameworks. They require a
25:14
disciplined agile approach that supports
25:17
both flexibility and formal oversight.
25:20
Choice A is the best option because
25:22
agile unified process offers a blend of
25:24
iterative delivery and structured life
25:26
cycle phases. It provides enough
25:28
formality to meet compliance standards
25:31
such as traceability and auditability
25:34
while still supporting agile values like
25:36
adaptability and customer collaboration.
25:39
Choice B is incorrect. Adapting Scrum
25:42
and documenting exceptions may work
25:44
temporarily, but it's a reactive
25:46
workaround, not a robust or sustainable
25:48
strategy for regulated environments.
25:51
Choice C is incorrect. While FDD
25:53
emphasizes delivery of features, it
25:55
doesn't provide the governance structure
25:58
needed to address audit trails,
26:00
traceability, or maintenance planning.
26:02
Choice D is incorrect. DSDM allows for
26:06
flexibility and scope and can work well
26:08
with fixed time and cost, but it lacks
26:10
the specific traceability and
26:12
post-release support structures that
26:13
this scenario demands. Amazing job in
26:17
finishing 10 agile framework questions.
26:19
That's a total of 30 agile questions
26:21
mastered. So far, every question you
26:23
tackle sharpens your exam readiness.
26:26
When you're ready, I will see you in the
26:27
next topic.