live_tv
Livestream Starting Soon
00
Hours
:
00
Minutes
:
00
Seconds
Up next in 10
Agile Review Series: Agile Planning & Estimation
Full 150 Agile Review & Questions Video: https://youtu.be/Z-teNScLspI
How do Agile teams plan without losing flexibility? In this video, we cover Agile planning & estimation techniques - story points, velocity, roadmaps, and more - with 10 PMP® practice questions to sharpen your exam readiness.
This is the ninth video in our 15-part Agile Review & Question series. You’ll learn how Agile teams use rolling wave planning, estimation techniques, user story mapping, velocity, capacity planning, and release roadmaps to stay aligned and deliver value. Then, you’ll test your knowledge with 10 scenario-based practice questions (Questions 81–90) with detailed explanations.
✅ You’ll learn how to:
• Apply progressive elaboration and rolling wave planning in Agile projects
• Use estimation techniques like story points, T-shirt sizing, and Planning Poker
• Distinguish between velocity and capacity when forecasting delivery
• Balance short-term sprint goals with long-term product roadmaps
• Manage technical debt while maintaining sustainable pace
By practicing these questions, you’ll strengthen your ability to plan, estimate, and deliver effectively — both for the PMP® exam and in real-world Agile projects.
Chapters:
0:00 Agile Planning & Estimation Overview
2:39 Question 81
4:27 Question 82
Show More Show Less View Video Transcript
0:00
The topic we'll cover is agile planning
0:02
and estimation, where agile teams
0:04
balance flexibility with focus. Planning
0:07
just enough to move forward while
0:08
staying ready to adapt as they learn
0:10
more. In agile, planning is not a
0:13
one-time activity. It's an ongoing
0:15
process called progressive elaboration
0:18
or rolling wave planning where near-term
0:21
work is planned in detail and long-term
0:23
work remains high level and adaptable.
0:26
Instead of estimating by hours or dates,
0:28
agile teams use relative estimation,
0:30
comparing work items to each other in
0:32
terms of effort, complexity, and
0:34
uncertainty. Let's go over three common
0:37
techniques. Story points use a number
0:39
scale like 1 3 5 8 to compare how large
0:43
or complex a user story is relative to
0:46
others. It's abstract, not tied to time.
0:50
T-shirt sizing uses labels like SML XL
0:54
to quickly estimate features at a high
0:56
level. Especially useful during road map
0:58
discussions. Planning Poker is a
1:01
collaborative team game where members
1:03
independently choose a number, then
1:05
reveal and discuss until reaching
1:06
consensus. It encourages conversation
1:09
and shared understanding. Once work is
1:11
estimated, velocity is used to track how
1:14
much the team delivers per sprint. It's
1:15
a key input for forecasting future
1:18
delivery. Don't confuse this with
1:20
capacity, which is about how much time
1:22
or availability the team actually has
1:25
for a sprint. To see the big picture,
1:27
teams use user story maps, which are a
1:30
visual layout of features based on the
1:31
user journey, helping prioritize by
1:34
value and organize releases more
1:35
effectively. Each sprint starts with a
1:38
clear sprint goal, which is a unifying
1:40
purpose that helps the team stay focused
1:43
and aligned even if not every story gets
1:46
finished. Release plans zoom out
1:48
further, showing what can be delivered
1:50
and when. They evolve based on actual
1:53
velocity and business priorities, giving
1:55
stakeholders visibility and helping
1:57
manage expectations. And then there's
1:59
technical debt, the hidden cost of
2:01
shortcuts like skipping tests or
2:03
delaying refactoring. It helps you go
2:05
faster now but slows you down later.
2:08
Agile teams make it visible, discuss it
2:10
regularly, and plan time to reduce it.
2:13
On the PMP exam, you'll likely be tested
2:15
on how agile teams estimate, plan, and
2:17
adapt. Expect questions involving
2:20
changing priorities, forecasting in
2:22
uncertainty, dependencies, and how these
2:24
techniques are applied in both agile and
2:26
hybrid settings. Now, we'll go through
2:29
10 practice questions that test your
2:31
knowledge of agile planning, estimation,
2:33
velocity, technical debt, and more.
2:36
Let's get into the first question in
2:38
this topic. Question 81. The project
2:41
sponsor asks why the team hasn't created
2:44
a fully detailed plan for all sprints at
2:46
the beginning of the project. The team
2:48
explains they are using progressive
2:50
elaboration. Which response best
2:53
reflects this approach? A. Work is
2:56
estimated and planned only after all
2:58
stakeholder requirements are confirmed.
3:01
B. Near-term work is planned in detail
3:04
while future work is kept high level and
3:06
refined over time. C. The team locks in
3:10
sprint level detail only after the
3:12
release road map is finalized. D.
3:14
Planning is deferred until just before
3:17
each sprint to remain as flexible as
3:19
possible. You can pause the video here
3:21
if you need more time to work on the
3:23
question. The correct answer is B. This
3:26
question focuses on progressive
3:28
elaboration and rolling wave planning
3:30
which are key agile concepts for
3:32
adaptive planning and iterative
3:34
development. Choice B is the best option
3:37
because it reflects the agile mindset of
3:39
planning just enough, providing detailed
3:41
planning for near-term work while
3:43
keeping future work intentionally vague
3:46
until more information is available.
3:48
This enables teams to adapt and refine
3:50
based on learning and change. Choice A
3:53
is incorrect. This sounds like a
3:55
waterfall mindset. Agile discourages
3:57
waiting for complete requirements before
4:00
planning or delivering value. Choice C
4:02
is incorrect. A release road map offers
4:05
direction but doesn't determine when
4:07
detailed planning should begin. Agile
4:09
encourages planning in cycles, not after
4:11
highle sign off. Choice D is incorrect.
4:15
Although agile values flexibility,
4:17
completely deferring planning until a
4:19
sprint starts can lead to lack of
4:21
alignment, confusion, or poor
4:23
forecasting. Let's move on to the next
4:25
question if you're ready. Question 82.
4:29
During a release planning session, the
4:30
product owner presents a large set of
4:33
backlog items and struggles to
4:34
prioritize what to deliver first. The
4:37
team suggests using user story mapping.
4:40
How can this approach help? A. It breaks
4:43
each user story into detailed tasks to
4:45
identify dependencies and assign
4:47
estimates. B. It groups stories by risk
4:50
and complexity to determine the most
4:52
achievable deliverables.
4:54
C. It organizes features around user
4:57
goals and identifies high value slices
4:59
for early delivery. D. It maps technical
5:02
components to the development
5:04
architecture to reduce rework. You can
5:06
pause the video here if you need more
5:08
time to work on the question. The
5:10
correct answer is C. This question
5:13
checks your understanding of user story
5:15
mapping, a visual prioritization tool
5:17
that supports valuedriven planning in
5:20
agile. Choice C is the best option
5:22
because user story mapping organizes
5:25
stories around user workflows or goals,
5:27
helping teams visualize which features
5:29
support the customer journey and
5:31
enabling early delivery of thin vertical
5:33
slices that provide real value. Choice A
5:36
is incorrect. Breaking stories into
5:39
tasks is part of sprint planning, not
5:41
user story mapping, which focuses on
5:44
feature alignment and prioritization.
5:46
Choice B is incorrect. Risk and
5:49
complexity may influence planning, but
5:51
user story mapping prioritizes value
5:54
through user perspective, not just
5:57
technical feasibility. Choice D is
5:59
incorrect. Mapping to architecture may
6:02
reduce technical risk, but it doesn't
6:04
help prioritize features from a customer
6:06
centric or goal oriented viewpoint.
6:09
Let's move on to the next question if
6:11
you're ready. Question 83. A new team is
6:14
struggling to assign story points
6:16
consistently. What's the best way to
6:18
improve their relative estimation
6:20
process? A. Use a reference story as a
6:23
baseline and compare new stories against
6:26
it. B. Reestimate all stories together
6:28
at the start of each sprint for
6:30
accuracy.
6:32
C. Assign story points based on how many
6:34
hours the task will take to complete. D.
6:38
Ask the product owner to assign points
6:40
based on business value. You can pause
6:43
the video here if you need more time to
6:45
work on the question. The correct answer
6:47
is A. This question tests your
6:49
understanding of relative estimation, a
6:52
key agile technique that emphasizes
6:54
comparison over precision. Choice A is
6:57
the best option because using a
6:59
reference story or anchor story gives
7:01
the team a consistent benchmark for
7:03
sizing other work. This improves
7:06
calibration and helps teams build shared
7:08
understanding around complexity. Choice
7:11
B is incorrect. While frequent
7:13
estimation can be useful, reestimating
7:15
everything each sprint is time-conuming
7:18
and unnecessary if the team already has
7:20
a stable baseline. Choice C is
7:23
incorrect. Story points are not about
7:25
hours. They represent effort, risk, and
7:28
complexity relative to other stories,
7:31
not duration. Choice D is incorrect. The
7:34
product owner sets priority, not
7:36
estimates. Estimation is the team's
7:38
responsibility. Let's move on to the
7:40
next question if you're ready. Question
7:43
84. During early release planning, the
7:46
team uses t-shirt sizing to estimate
7:48
several new features. A stakeholder
7:50
questions the value of this method,
7:52
asking how it helps with planning. What
7:54
is the most appropriate explanation? A.
7:57
It guarantees the team will complete all
7:59
the stories within a set time frame. B.
8:02
It provides a timebased estimate for
8:04
each feature to support detailed
8:06
planning. C. It gives a quick relative
8:09
sense of effort before precise
8:11
estimation is needed. D. It identifies
8:14
technical constraints in features
8:16
requiring further architectural input.
8:19
You can pause the video here if you need
8:21
more time to work on the question. The
8:23
correct answer is C. This question
8:26
evaluates your understanding of
8:27
high-level estimation techniques,
8:29
specifically how t-shirt sizing is used
8:31
in agile planning. Choice C is the best
8:34
option because t-shirt sizing offers a
8:37
fast relative comparison of effort
8:39
levels. It allows teams to plan at a
8:41
high level without needing detailed
8:43
breakdowns which is especially helpful
8:45
early in the project. Choice A is
8:47
incorrect. No estimation technique can
8:49
guarantee delivery within a set time.
8:52
Agile estimates are intended to support
8:54
forecasting, not commitment. Choice B is
8:57
incorrect. T-shirt sizing is not
8:59
timebased. It's intentionally abstract
9:01
using sizes SML, etc. to express effort
9:05
or complexity. Choice D is incorrect.
9:08
While technical constraints may arise,
9:10
identifying them isn't the primary
9:12
purpose of t-shirt sizing. Let's move on
9:15
to the next question. If you're ready,
9:17
question 85. During a backlog refinement
9:20
session, the agile team is estimating
9:22
user stories using planning poker. Most
9:25
of the team agrees on a story being a
9:27
five-point effort, but one team member
9:29
votes for 13. The team begins to move
9:32
on, assuming the outlier is a mistake.
9:34
The project manager notices the vote and
9:36
intervenes. What should the project
9:38
manager do to ensure the team gets the
9:41
most value out of the estimation
9:42
session? A. Ask the team member to
9:45
revote to align with the majority and
9:48
keep the session moving. B. Use the per
9:51
method to calculate a likely estimate
9:53
based on all submitted scores. C.
9:56
Document the discrepancy for future
9:58
review and proceed with the average
10:00
score. D. Invite the outlier to explain
10:03
their reasoning to promote discussion
10:05
and shared understanding. You can pause
10:08
the video here if you need more time to
10:10
work on the question. The correct answer
10:12
is D. This question assesses your
10:14
understanding of team-based estimation
10:16
practices in agile, specifically how
10:19
planning poker encourages collaboration
10:22
and shared ownership of effort
10:23
estimates. Choice D is the best option
10:26
because planning poker is designed to
10:28
surface differences in perception. When
10:30
a team member selects an outlier
10:32
estimate, it's often a signal that they
10:35
have insight others may not have. Asking
10:37
them to explain can uncover hidden
10:39
risks, misunderstood scope, or technical
10:42
constraints. This conversation builds
10:44
team alignment and consensus. Choice A
10:47
is incorrect. Forcing consensus without
10:50
discussion defeats the purpose of
10:51
planning poker. Agile values
10:54
collaboration and psychological safety
10:56
which requires allowing different
10:58
perspectives to be heard. Choice B is
11:01
incorrect. While per is useful in some
11:03
contexts, it isn't part of team-based
11:06
agile estimation. It also fails to
11:08
resolve underlying differences in
11:10
understanding. Choice C is incorrect.
11:13
Averaging scores without discussion can
11:15
mask misalignment and leave important
11:18
concerns unressed. Let's move on to the
11:21
next question if you're ready. Question
11:23
86. After three sprints, the project
11:26
manager notices that the team has
11:28
delivered 2022 and 18 story points
11:30
respectively. A stakeholder asks if the
11:33
team will be able to complete all
11:34
planned work by the release date. How
11:37
should the project manager respond? A.
11:39
Use the team's average velocity to
11:41
forecast how many points can be
11:43
delivered by the release. B. Use the
11:46
most recent velocity to estimate how
11:49
much work the team can deliver. C. Ask
11:52
the team to increase their velocity by
11:54
assigning more stories in the next
11:55
sprint. D. Use the lowest story point
11:58
total so far to estimate and ensure the
12:00
team can deliver. You can pause the
12:03
video here if you need more time to work
12:05
on the question. The correct answer is
12:07
A. This question evaluates your
12:10
understanding of velocity as an agile
12:12
forecasting tool. Velocity helps teams
12:14
and stakeholders predict how much work
12:16
can be completed based on real
12:18
performance data. Choice A is the best
12:21
option because using the average of
12:23
completed story points across multiple
12:26
sprints gives a more balanced realistic
12:28
forecast. This approach accounts for
12:30
sprint variability and improves
12:32
confidence in planning. Choice B is
12:35
incorrect. Relying only on the most
12:37
recent sprint may lead to inaccurate
12:39
projections, especially if that sprint
12:41
was impacted by anomalies or reduced
12:44
capacity. Choice C is incorrect. Asking
12:46
the team to increase velocity
12:48
artificially disregards agile's focus on
12:50
sustainable pace and empirical data.
12:53
Choice D is incorrect. Using the lowest
12:56
completed value might seem safe, but it
12:58
fails to reflect the team's true
13:00
capacity and can lead to underdely of
13:03
value without reason. Let's move on to
13:05
the next question if you're ready.
13:07
Question 87. Midway through a release,
13:10
the agile team realizes that several
13:12
team members will be unavailable during
13:14
the next sprint due to training and time
13:16
off. The project manager needs to adjust
13:19
expectations for delivery. What's the
13:22
best approach to plan the upcoming
13:24
sprint? A. Use the average team velocity
13:27
and assign fewer story points to account
13:30
for time off. B. Shift work to available
13:33
team members to try to maintain the
13:35
previous velocity. C. Assess available
13:38
team capacity and select backlog items
13:41
accordingly. D. Prioritize only
13:44
technical stories that require less
13:45
collaboration to reduce impact. You can
13:48
pause the video here if you need more
13:50
time to work on the question. The
13:52
correct answer is C. This question tests
13:55
your understanding of how to respond to
13:57
fluctuating team availability using
13:59
agile principles. In agile, planning is
14:02
based on actual capacity, not historical
14:04
velocity alone. Choice C is the best
14:08
option because it reflects the proper
14:10
use of capacity planning. Evaluating how
14:14
much time and effort the available team
14:15
members have and then selecting work
14:18
accordingly. This helps the team
14:20
maintain a sustainable pace and
14:22
realistic delivery expectations. Choice
14:25
A is incorrect. While adjusting velocity
14:28
sounds reasonable, velocity is an
14:30
observed measure. It's not manually
14:33
adjusted. Teams should plan based on
14:35
capacity, not artificially modified
14:38
velocity. Choice B is incorrect.
14:40
Reallocating all work to the remaining
14:42
team members to keep up velocity can
14:44
cause overload, burnout, and reduce
14:47
quality. Agile discourages this kind of
14:49
reactive planning. Choice D is
14:52
incorrect. Prioritizing work based on
14:54
perceived ease or technical isolation
14:56
avoids real planning and can lead to
14:58
sub-optimal value delivery. Let's move
15:01
on to the next question if you're ready.
15:03
Question 88. An agile team is planning
15:06
for upcoming sprints. The team has been
15:08
completing around 30 story points per
15:11
sprint but recently started forecasting
15:13
40 points to meet stakeholder
15:15
expectations. The project manager
15:17
notices that velocity hasn't increased
15:20
despite the higher forecasts and
15:22
delivery quality is beginning to slip.
15:24
What should the project manager do? A.
15:27
Ask the team to commit to fewer stories
15:29
and gradually work back up to 40 points
15:32
over time. B. Use capacity planning to
15:35
assign work more aggressively across
15:37
team members. C. Adjust the story point
15:40
estimation scale to make forecasts more
15:43
realistic. D. Facilitate a conversation
15:46
with the team about aligning forecasts
15:48
with observed velocity. You can pause
15:51
the video here if you need more time to
15:53
work on the question. The correct answer
15:55
is D. This question evaluates how you
15:58
manage forecasting and velocity
16:00
pressures in agile teams. It touches on
16:02
agile values such as transparency,
16:04
realism, and team ownership. Choice D is
16:07
the best option because the project
16:09
manager should support a team-led
16:10
discussion about sustainable delivery
16:12
and help realign forecasting with actual
16:15
velocity. Facilitating this kind of open
16:17
conversation encourages ownership,
16:19
trust, and prevents overcommitment. All
16:22
of which are key to maintaining quality
16:24
and predictability. Choice A is
16:27
incorrect. While it suggests scaling
16:29
down, it's a directive approach that
16:32
assumes the team can eventually increase
16:34
velocity, which may not be realistic or
16:37
appropriate. Choice B is incorrect.
16:40
Assigning work more aggressively pushes
16:42
beyond sustainable pace and disregards
16:44
self-management, potentially damaging
16:46
morale and quality. Choice C is
16:49
incorrect. Changing the estimation scale
16:51
doesn't address the real issue, which is
16:54
misalignment between forecasted and
16:56
delivered work. Let's move on to the
16:58
next question if you're ready. Question
17:00
89. An agile project involves multiple
17:04
stakeholders across departments, each
17:06
with different expectations for product
17:08
delivery timelines. During the initial
17:10
planning phase, the sponsor asks the
17:12
project manager how the team will align
17:14
short-term sprint planning with
17:16
longerterm business milestones. What
17:18
should the project manager do? A. Use
17:21
the team's current velocity to define a
17:24
detailed delivery schedule for each
17:26
sprint. B. Collaborate with stakeholders
17:29
to create a high-level product roadmap
17:32
based on priority and value. C. Ask the
17:35
product owner to lock in features and
17:37
dates early so the team can plan
17:39
accordingly. D emphasizes that agile
17:42
doesn't use fixed schedules and instead
17:44
focuses on continuous delivery. You can
17:47
pause the video here if you need more
17:49
time to work on the question. The
17:51
correct answer is B. This question tests
17:54
your understanding of release planning
17:56
in agile environments. Specifically, how
17:58
to balance flexibility with the need for
18:01
visibility into product delivery. Choice
18:03
B is the best option because creating a
18:06
high-level product roadmap provides a
18:08
visual timeline that links product
18:10
priorities with business goals. It
18:12
enables collaboration, transparency, and
18:15
shared expectations while maintaining
18:17
the flexibility to adapt as priorities
18:19
shift. Choice A is incorrect. While
18:22
velocity is useful for forecasting,
18:24
trying to define detailed delivery per
18:27
sprint too early contradicts the agile
18:29
principle of progressive elaboration.
18:32
Choice C is incorrect. Locking features
18:35
and dates early limits flexibility and
18:37
undermines the agile value of responding
18:40
to change over following a plan. Choice
18:43
D is incorrect. While agile emphasizes
18:47
continuous delivery, completely
18:49
dismissing schedules may alienate
18:52
stakeholders who still need visibility
18:54
for planning. Let's move on to the next
18:56
question if you're ready. Question 90.
19:00
During sprint planning, the agile team
19:01
begins selecting backlog items for the
19:04
upcoming sprint. The product owner
19:05
shares several urgent items that were
19:07
just added to the backlog. While some
19:09
previously refined stories align more
19:11
closely with the product vision and
19:13
roadmap, the team feels conflicted about
19:15
what to include. What should guide the
19:18
team's selection of work for the sprint?
19:20
A the items that were refined earliest
19:23
since they are ready for development. B
19:26
the items with the highest story point
19:28
estimates to ensure high throughput. C.
19:31
The items that best support a clear
19:34
cohesive sprint goal aligned with
19:36
product strategy. D. the items most
19:39
recently added by the product owner to
19:41
respond quickly to new needs. You can
19:44
pause the video here if you need more
19:45
time to work on the question. The
19:47
correct answer is C. This question
19:50
evaluates your understanding of sprint
19:52
planning priorities, especially how
19:54
sprint goals help maintain product
19:56
alignment and team focus. Choice C is
19:59
the best option because a strong sprint
20:01
goal guides the team in selecting
20:03
backlog items that deliver cohesive
20:05
value and align with the product vision.
20:08
This supports agile principles of
20:10
transparency, value delivery, and shared
20:13
understanding. Choice A is incorrect.
20:16
Refinement helps prepare items, but
20:18
order of refinement doesn't dictate
20:20
priority. Strategic alignment matters
20:23
more. Choice B is incorrect. High story
20:26
point items do not necessarily equate to
20:29
higher value. Agile prioritizes value
20:31
over volume. Choice D is incorrect. New
20:34
items might be important, but the team
20:36
should evaluate them in the context of
20:39
the sprint goal, not just recency. Great
20:42
job completing all 10 questions for
20:44
agile planning and estimation. That's 90
20:46
agile questions mastered so far. Stay
20:49
consistent and you'll master all 150
20:52
agile questions in this series. Let's
20:54
move forward together. When you are
20:55
ready for the next topic,