Up next in 10
150 Agile Questions & Review: #11-20 (Agile Principles)
Aug 10, 2025
This is the second video in our 15 Agile Review & Question series, designed to help you master Agile concepts and prepare for the PMP® exam. In this video, we focus on the 12 Agile Principles from the Agile Manifesto and reinforce your understanding through 10 practice questions (Questions 11 to 20) with explanations. ✅ You’ll learn how to: • Apply Agile principles in real-world scenarios • Identify the correct PMI-aligned choice among plausible options • Strengthen your Agile mindset for the exam and the workplace By practicing with scenario-based questions, you’ll not only remember the concepts, you’ll know how to apply them under exam conditions. Chapters: 0:00 Agile Principles Overview 1:47 Question 11 3:53 Question 12 5:55 Question 13 8:00 Question 14 10:02 Question 15 12:00 Question 16 14:03 Question 17
View Video Transcript
0:00
Now that we've covered the mindset
0:01
behind agile, let's move into the core
0:03
principles that guide agile teams in
0:05
their day-to-day work. The agile
0:08
principles are the foundation of agile
0:10
practices. 12 guiding ideas that shape
0:13
how we deliver value, interact with
0:15
stakeholders, and build high-erforming
0:17
teams. You don't need to memorize all 12
0:19
for the PMP exam, but you do need to
0:21
understand how they show up in real
0:24
world scenarios. At the heart of these
0:26
principles is the commitment to
0:27
delivering customer value early and
0:29
often. Agile isn't about waiting until
0:32
the end of a project to show results.
0:34
It's about incremental delivery, getting
0:36
feedback fast, and adapting based on
0:39
what we learn. You'll also want to be
0:41
comfortable with the idea of welcoming
0:43
changing requirements even late in the
0:45
process. Agile teams know that change is
0:48
a competitive advantage, not a
0:49
disruption, and they build in
0:51
flexibility to respond quickly. Working
0:54
software over comprehensive
0:56
documentation is another core idea. That
0:59
doesn't mean no documentation. It means
1:01
we prioritize usable solutions over
1:03
paperwork that doesn't move the needle
1:05
for the customer. These principles
1:08
support daily collaboration with
1:09
stakeholders, empowered and motivated
1:11
teams, and maintaining a sustainable
1:13
pace of work. Agile isn't about speed
1:16
for the sake of speed. It's about
1:18
long-term consistent performance. Other
1:21
principles emphasize the importance of
1:23
technical excellence, simplicity, and
1:25
allowing teams the autonomy to
1:26
self-organize and make decisions. Now,
1:29
we'll go through 10 practice questions
1:31
that test your ability to apply these
1:33
principles in real PMP exam scenarios.
1:36
You'll see questions about value
1:37
delivery, stakeholder collaboration,
1:39
team empowerment, sustainable work
1:42
habits, and how agile principles
1:44
influence project decisions. Here is our
1:47
next question. Question 11. A product
1:50
owner is eager to release a major new
1:52
feature, but suggests waiting until all
1:54
components are fully built and tested
1:56
before deploying it. The agile team,
1:58
however, believes that part of the
1:59
feature could be released now to start
2:01
gathering feedback and delivering value.
2:03
What should the agile project manager
2:05
do? A support the product owner's plan
2:08
to wait and ensure the full feature
2:10
meets quality expectations.
2:12
B recommend releasing the full feature
2:14
in a single launch to provide a seamless
2:17
and complete user experience.
2:19
C. Encourage the product owner to
2:21
consider releasing the most valuable
2:23
part now to gain early feedback. D.
2:26
Suggest bundling the most complete parts
2:29
into a limited beta release to evaluate
2:31
user response before a broader launch.
2:34
You can pause the video here if you need
2:36
more time to work on the question. The
2:39
correct answer is C. This question is
2:41
testing your grasp of one of the core
2:43
agile principles. Delivering customer
2:46
value early and often. Agile isn't about
2:49
waiting until everything is perfect.
2:51
It's about getting valuable increments
2:53
into the hands of users quickly so you
2:55
can learn, adapt, and improve. In this
2:59
case, the team is ready to release a
3:01
portion that already provides value. The
3:04
best move is to support an incremental
3:06
release strategy that invites early
3:08
feedback. This reinforces
3:10
responsiveness, flexibility, and
3:12
customer focus. Choice A is incorrect.
3:16
While quality matters, waiting until
3:17
everything is perfect before delivering
3:19
can lead to delayed value and missed
3:21
learning opportunities. Choice B is
3:24
incorrect. A full release may feel
3:26
polished, but it delays feedback and
3:28
contradicts the principle of frequent
3:30
delivery of working solutions. Choice D
3:33
is incorrect. A beta release sounds
3:35
agile friendly, but it still reflects a
3:38
hesitancy to deliver value now. It adds
3:41
unnecessary caution and complexity
3:43
instead of embracing small valuable
3:46
increments. Congratulations on tackling
3:48
this first principle. Let's move on to
3:50
the next question when you're ready.
3:52
Question 12. Midway through a sprint, a
3:55
business stakeholder requests a change
3:57
to an inrogress feature based on new
4:00
market feedback. The team worries that
4:02
changing course might affect their
4:03
ability to complete the sprint as
4:05
planned. The product owner believes the
4:07
change adds value but is unsure whether
4:09
to act now or wait. How should the agile
4:12
project manager respond? A recommend
4:15
implementing the change now as agile
4:17
welcomes changes that improve customer
4:20
value at any stage. B. Advise waiting
4:23
until the sprint review to introduce a
4:25
change, ensuring minimal disruption to
4:27
current commitments. C. suggests
4:30
revisiting the sprint backlog with the
4:32
team and product owner to assess impact
4:33
and adjust scope if appropriate. D.
4:36
Encourage the product owner to document
4:38
the request and prioritize it in the
4:40
backlog for future sprints. You can
4:43
pause the video here if you need more
4:45
time to work on the question. The
4:47
correct answer is C. This question is
4:50
testing your ability to respond to
4:52
change while maintaining team alignment.
4:54
A hallmark of agile. Agile values
4:56
welcoming change even late in
4:58
development. But that doesn't mean
5:00
acting impulsively. It's about being
5:02
responsive and thoughtful. The agile
5:04
project manager's role here is to
5:06
facilitate collaboration between the
5:08
product owner and the team to evaluate
5:10
the change. If it's valuable and the
5:13
team agrees it's doable without
5:14
compromising the sprint goal, then
5:16
adjusting scope is perfectly
5:18
appropriate. Choice A is incorrect.
5:21
While agile embraces change,
5:23
recommending implementation without team
5:25
input or impact assessment undermines
5:27
team commitment and sustainable
5:29
planning. Choice B is incorrect. Waiting
5:32
until the sprint review delays feedback
5:34
and value delivery, which goes against
5:36
Agile's principle of fast response and
5:38
continuous adaptation. Choice D is
5:41
incorrect. Backlog documentation is
5:43
helpful, but postponing a value adding
5:45
change without discussion misses an
5:47
opportunity to deliver timely impact,
5:50
especially when the team is already
5:52
engaged in the work. Let's move on to
5:54
the next question if you're ready.
5:56
Question 13. An agile project is behind
5:59
schedule and a stakeholder requests a
6:01
detailed progress report with updated
6:03
risk logs and a revised communication
6:05
plan. The team is already preparing for
6:07
an upcoming product increment demo and
6:09
refining user stories for the next
6:11
sprint. What is the best way for the
6:13
agile project manager to address the
6:15
stakeholders request while supporting
6:17
agile principles? A propose creating a
6:20
brief summary document supported by
6:22
existing team metrics to meet the
6:25
stakeholders request. B recommend
6:27
providing a live product demonstration
6:30
and summary instead of detailed
6:32
documentation.
6:33
C. Work with the product owner to
6:35
prioritize documentation tasks alongside
6:38
backlog refinement to support
6:40
transparency.
6:42
D. Ask a team member to compile the
6:44
requested documents while others
6:45
continue with preparation for the demo.
6:48
You can pause the video here if you need
6:49
more time to work on the question. The
6:52
correct answer is a. This question tests
6:55
your ability to balance agile principles
6:57
with stakeholder expectations. Agile
6:59
promotes working software over
7:01
comprehensive documentation, but that
7:03
doesn't mean no documentation. It means
7:05
you provide just enough to support
7:07
transparency and collaboration without
7:10
getting bogged down. In this case, a
7:13
brief summary using existing team
7:14
metrics is an efficient way to give
7:16
stakeholders what they need while still
7:18
protecting team capacity and focus.
7:21
You're still communicating clearly.
7:22
You're just doing it with lightweight,
7:24
high value artifacts. Choice B is a
7:27
tempting option. While a demo is great,
7:29
some stakeholders, especially when
7:31
projects are behind, expect a structured
7:33
status update. A demo alone might feel
7:35
incomplete or informal. Choice C is
7:38
incorrect. Trying to formally prioritize
7:41
documentation in the sprint risks
7:43
derailing value delivery. It introduces
7:46
unnecessary overhead. Choice D is
7:49
incorrect. Assigning documentation to
7:52
one person may seem efficient, but it
7:54
creates work in progress that's outside
7:55
the sprint goal and fragments team
7:57
focus. Let's move on to the next
8:00
question if you're ready. Question 14.
8:03
During an agile project, business
8:05
stakeholders begin attending sprint
8:07
reviews but remain largely uninvolved
8:09
during the rest of the sprint. The team
8:11
delivers on commitments but feedback
8:13
often comes too late to influence
8:15
current work. What should the agile
8:17
project manager do? A. Encourage the
8:20
team to review all feedback during
8:23
retrospectives and incorporate it into
8:25
future sprints. B. Recommend inviting
8:29
stakeholders to daily standups to
8:30
increase visibility and promote ongoing
8:33
input. C. Ask the product owner to
8:36
collect stakeholder feedback weekly and
8:38
share it during backlog refinement. D.
8:41
Suggest scheduling additional review
8:43
sessions mid-sprint to ensure feedback
8:45
is captured earlier. You can pause the
8:48
video here if you need more time to work
8:50
on the question. The correct answer is
8:52
D. This question tests your ability to
8:56
promote meaningful real-time
8:57
collaboration with stakeholders, one of
8:59
the core agile principles. Agile isn't
9:02
just about delivering value. It's about
9:05
doing it in close partnership with the
9:07
people who define what value means.
9:10
Stakeholders attending sprint reviews is
9:12
a good start, but if feedback comes too
9:14
late to act on, the team misses the
9:16
chance to adapt in real time. By
9:18
introducing mid-sprint reviews or
9:20
informal demos, you create a natural
9:22
opportunity to gather insights earlier
9:24
when they can still shape the outcome.
9:27
Choice A is incorrect. Retrospectives
9:29
are useful, but they focus on team
9:31
process, not on product feedback.
9:33
Waiting until the end of the sprint is
9:35
already too late for course correction.
9:37
Choice B is incorrect. While daily
9:39
standups increase visibility, they're
9:41
not designed for stakeholder input.
9:43
Involving stakeholders in this ceremony
9:45
risks distracting the team and changing
9:47
its intent. Choice C is incorrect.
9:50
Having the product owner collect
9:52
feedback weekly is helpful, but passive
9:54
feedback collection isn't a substitute
9:57
for interactive engagement with the full
9:59
team. Let's move on to the next question
10:01
if you're ready. Question 15. A team
10:05
member shares in a retrospective that
10:06
they feel their input isn't being
10:08
considered during sprint planning. Other
10:10
members often dominate the conversation
10:12
and the product owner tends to
10:13
prioritize ideas from more senior team
10:15
members. The team delivers on time but
10:17
morale is starting to dip. What is the
10:20
most appropriate next step to strengthen
10:22
team trust and motivation? A speak
10:25
privately with the product owner to
10:26
ensure more balanced input in future
10:29
planning sessions. B. Encourage the team
10:32
to rotate facilitation responsibilities
10:34
to give everyone a chance to lead
10:36
discussions. C. Suggest the scrub master
10:39
hold individual check-ins to gather
10:41
input and address concerns privately. D.
10:44
Facilitate a team discussion on
10:46
inclusion and decisionmaking during the
10:48
next retrospective. You can pause the
10:50
video here if you need more time to work
10:52
on the question. The correct answer is
10:54
D. This question is testing your ability
10:58
to support psychological safety and
11:00
inclusive team behavior. Both essential
11:03
to building motivated, high-erforming
11:05
agile teams. Agile encourages team
11:08
ownership and open communication and
11:10
retrospectives are the perfect form to
11:12
address group dynamics. By facilitating
11:14
a discussion on inclusion, you help the
11:16
team raise awareness and establish norms
11:18
that support equal contribution and
11:20
trust. When people feel heard,
11:22
motivation naturally improves. Choice A
11:25
is incorrect. While speaking privately
11:28
with the product owner might help, it
11:30
removes the opportunity for team level
11:32
awareness and self-correction. Agile
11:34
favors transparency and collective
11:36
ownership. Choice B is a good practice.
11:40
Rotating facilitators is great, but it
11:42
doesn't directly address the core issue
11:44
of feeling excluded or dismissed during
11:47
decision-making. Choice C is incorrect.
11:50
Individual check-ins are useful for
11:52
sensitive topics, but private channels
11:54
can unintentionally hide systemic
11:56
problems that require team attention.
11:59
Let's move on to the next question if
12:00
you're ready. Question 16. Several agile
12:04
team members are working remotely across
12:06
different regions. While some overlap in
12:08
working hours exists, communication has
12:10
become inconsistent and
12:12
misunderstandings about user stories
12:13
have led to rework. What is the best
12:16
action the agile project manager can
12:18
take to improve communication? A.
12:21
Suggest that the team follow a
12:22
standardized communication checklist to
12:24
ensure consistency across time zones. B.
12:28
Encourage asynchronous communication
12:31
using collaborative documents to reduce
12:33
dependency on meetings. C. Facilitate
12:36
regular video enabled meetings during
12:39
overlapping hours to promote real time
12:41
interaction. D. Schedule regional sync
12:44
meetings to ensure clarity within time
12:46
zones and reduce miscommunication.
12:49
You can pause the video here if you need
12:51
more time to work on the question. The
12:53
correct answer is C. This question tests
12:57
your understanding of agile
12:58
communication principles, especially
13:01
when teams are distributed. Agile
13:03
strongly values individuals and
13:05
interactions over processes and tools
13:08
and emphasizes that face-to-face
13:10
communication is the most effective way
13:12
to convey information. Since the team
13:15
has overlapping hours, the best step is
13:17
to use that time for realtime video
13:19
meetings that improve understanding,
13:21
encourage collaboration, and reduce
13:23
rework caused by miscommunication.
13:26
Choice A is incorrect. A communication
13:28
checklist adds structure, but it
13:30
reinforces process instead of solving
13:33
the root issue. The lack of direct
13:35
interaction and immediate feedback.
13:37
Choice B is tempting but incorrect.
13:40
Asynchronous tools can support
13:41
collaboration, but when
13:43
misunderstandings are already happening,
13:45
relying on written only communication
13:47
can make the situation worse. Choice D
13:50
is plausible but suboptimal. Regional
13:53
syncs improve alignment within small
13:55
groups, but they missed the benefit of
13:57
whole team communication, which is
13:59
essential for shared understanding in
14:00
agile. Let's move on to the next
14:03
question if you're ready. Question 17.
14:06
An agile team has been working late
14:08
nights and weekends for the past few
14:10
sprints to meet aggressive delivery
14:12
deadlines. While the team is meeting its
14:14
goals, several members have started
14:16
expressing fatigue and declining morale.
14:19
What is the most effective action the
14:20
agile project manager should take to
14:23
support a sustainable pace? A. Celebrate
14:26
the team's dedication and encourage them
14:28
to maintain their momentum until the
14:30
next release. B. Recommend that future
14:33
sprint commitments be based on team
14:35
capacity and historical velocity.
14:38
C. Ask leadership to provide performance
14:41
incentives to keep morale high during
14:43
this intense period. D. raise the team's
14:46
work in progress limits to help them
14:48
multitask and reduce pressure over time.
14:51
You can pause the video here if you need
14:53
more time to work on the question. The
14:55
correct answer is B. This question tests
14:58
your ability to apply one of the core
15:00
agile principles, maintaining a
15:02
sustainable pace indefinitely. Agile
15:05
isn't just about short-term delivery.
15:07
It's about building a rhythm that the
15:09
team can sustain over time without
15:12
burnout. By basing future commitments on
15:14
team capacity and historical velocity,
15:17
you're ensuring that planning is
15:18
grounded in reality, not pressure. This
15:21
allows teams to deliver value
15:23
consistently and predictably, a key
15:25
agile goal. Choice A is incorrect. While
15:29
it may seem supportive to celebrate the
15:31
team's dedication, encouraging them to
15:33
keep pushing at this pace leads to
15:35
burnout, not sustainability. Choice C is
15:38
also incorrect. Incentives might raise
15:41
short-term morale, but they do not solve
15:43
the underlying issue of overwork. Agile
15:45
focuses on intrinsic motivation and
15:47
sustainable delivery, not rewards for
15:50
overexertion.
15:52
Choice D is incorrect. Raising work and
15:54
progress limits encourages multitasking
15:57
and context switching, which actually
15:59
reduces efficiency and worsens fatigue,
16:02
the opposite of promoting a sustainable
16:05
pace. Let's move on to the next question
16:07
if you're ready. Question 18. An agile
16:11
team frequently delivers functionality
16:13
that meets business needs, but technical
16:15
debt is growing due to shortcuts taken
16:18
during development. Refactoring is
16:20
rarely prioritized and code quality
16:23
issues are starting to slow future work.
16:26
What should the agile project manager do
16:29
to promote technical excellence? A. Hold
16:32
one-on-one meetings with developers to
16:34
understand their concerns about quality
16:35
and gather suggestions for improvement.
16:38
B. Ask the product owner to add
16:40
refactoring tasks as separate backlog
16:43
items in future sprints. C. Facilitate a
16:46
team discussion to establish quality
16:48
standards and incorporate technical
16:49
improvements into each sprint. D.
16:52
Suggest having senior developers conduct
16:54
periodic code reviews outside of sprint
16:56
work to catch quality issues early. You
16:59
can pause the video here if you need
17:01
more time to work on the question. The
17:04
correct answer is C. This question is
17:07
about promoting technical excellence.
17:09
One of the agile principles that
17:11
directly supports long-term speed,
17:13
quality, and sustainability. The best
17:15
way to improve code quality and reduce
17:18
technical debt is to address it
17:19
collaboratively and continuously, not
17:22
reactively. Facilitating a team
17:24
discussion allows everyone to align on
17:26
quality standards and bake improvements
17:28
into each sprint rather than treating
17:30
them as separate or optional tasks. This
17:33
promotes shared ownership and keeps
17:35
technical health part of the team's
17:37
regular rhythm. Choice A is incorrect.
17:40
One-on-one conversations may uncover
17:42
insights, but they don't promote
17:44
teamwide awareness or collective
17:45
accountability, which are essential in
17:47
agile environments. Choice B sounds
17:51
reasonable, but treats refactoring as
17:53
separate from regular sprint work rather
17:55
than something that should be integrated
17:56
into every increment that weakens the
17:59
commitment to continuous excellence.
18:02
Choice D is tempting, but scheduling
18:04
code reviews outside of sprint work
18:06
isolates quality efforts from the team's
18:08
flow. Agile encourages technical
18:11
excellence within the team's regular
18:12
process, not as an external add-on.
18:15
Let's move on to the next question if
18:17
you're ready. Question 19. During sprint
18:20
planning, the team proposes a complex
18:22
solution for a user story that involves
18:24
multiple integrations and automation
18:27
features. The product owner reminds them
18:29
that the customer needs a quick and
18:31
usable version to validate before
18:33
investing in advanced capabilities.
18:36
What is the best way for the agile
18:38
project manager to support simplicity in
18:40
this situation? A support delivering a
18:43
minimal viable version that allows
18:45
customer feedback before expanding the
18:47
solution. B suggest implementing the
18:50
core functionality now and deferring
18:52
integrations to a later sprint. C.
18:56
Recommend building the minimum viable
18:58
product with all intended components to
19:00
ensure a complete experience. D.
19:03
Encourage the team to focus on building
19:04
a demo that showcases the long-term
19:07
vision of the feature. You can pause the
19:09
video here if you need more time to work
19:11
on the question. The correct answer is
19:14
A. This question focuses on the agile
19:17
principle of simplicity, maximizing the
19:19
amount of work not done. When complexity
19:21
creeps in, agile teams are encouraged to
19:23
focus on delivering just enough value to
19:25
learn and adapt. And that's where the
19:27
concept of a minimum viable product
19:29
comes in. By supporting the delivery of
19:32
a minimum viable version that gets quick
19:34
feedback from the customer, the agile
19:36
project manager helps ensure that the
19:38
team is working on what truly matters,
19:40
not just building out unnecessary
19:42
features. Choice B is a good sounding
19:45
option, but it doesn't go far enough. It
19:47
defers some of the work, which is
19:49
helpful, but it doesn't center the
19:51
delivery around customer validation,
19:53
which is what the PO was emphasizing.
19:55
Choice C misrepresents the MVP. A true
19:59
minimum viable product is not about
20:01
building all components. It's about
20:04
delivering the smallest valuable thing,
20:07
not the most complete experience. Choice
20:09
D sounds creative, but focuses on a
20:12
demo, which is more of a presentation
20:14
than a usable increment. Agile teams
20:17
strive to deliver working software, not
20:19
just visuals of what's to come. Let's
20:21
move on to the next question if you're
20:23
ready. Question 20. The crossf
20:26
functional agile team has consistently
20:28
relied on the agile project manager to
20:30
resolve impediments and assigned tasks.
20:32
During a recent retrospective, the scrum
20:34
master notes that this habit may be
20:36
limiting the team's growth and
20:37
ownership. Some team members say they
20:39
feel unsure about stepping up without
20:41
formal direction. What approach should
20:44
the agile project manager take to foster
20:46
a more self-organizing team environment?
20:49
A. Facilitate a working agreement
20:52
session where the team defines how they
20:53
will manage impediments and collaborate
20:56
on task ownership. B. Coordinate with
20:59
the product owner to define clearer task
21:01
priorities before the next sprint
21:02
planning session. C. Ask the scrum
21:05
master to mentor team members on agile
21:07
roles and ensure they stop expecting
21:09
direction from leadership. D. Schedule
21:12
one- on-one coaching sessions with each
21:14
team member to encourage initiative and
21:16
reinforce agile values individually.
21:19
You can pause the video here if you need
21:21
more time to work on the question. The
21:24
correct answer is A. This question is
21:27
testing your understanding of empowering
21:29
teams to become self-organizing a core
21:32
agile principle. It's not just about
21:34
removing blockers for the team. It's
21:36
about creating an environment where they
21:38
learn to solve problems and take
21:40
ownership together. Facilitating a
21:43
working agreement session brings the
21:45
whole team into the conversation. It
21:47
lets them define how they'll handle
21:49
blockers, distribute work, and make
21:51
decisions together. This builds both
21:53
autonomy and accountability. Choice B is
21:57
a good sounding distraction. It uses the
21:59
right technique, clarifying priorities,
22:01
but does so with the wrong stakeholder
22:04
and at the wrong level. Task assignment
22:06
and ownership should come from the team,
22:08
not be dictated through product level
22:10
prioritization. Choice C shifts
22:13
responsibility to the scrum master,
22:15
which misses the mark. The agile project
22:17
manager should be helping enable the
22:19
team, not delegating cultural change to
22:22
someone else. Choice D also sounds
22:25
helpful, but one-on-one coaching
22:27
isolates the issue instead of addressing
22:29
it as a team dynamic, which is where the
22:31
problem lies. Great job finishing 10
22:34
agile principles questions. That's a
22:36
total of 20 agile questions mastered so
22:39
far. You're building a solid foundation
22:42
for your PMP exam. When you're ready, I
22:45
will see you in the next topic.