live_tv
Livestream Starting Soon
00
Hours
:
00
Minutes
:
00
Seconds
Up next in 10
Agile Review Series: Agile Metrics & Reporting
Full 150 Agile Review & Questions Video: https://youtu.be/Z-teNScLspI
Which Agile metrics really matter for your PMP® exam — and how are they used in real projects? In this video, we’ll cover Agile Metrics & Reporting, focusing on how teams use charts, trends, and flow data to improve transparency, forecast delivery, and demonstrate value.
This is the tenth video in our 15-part Agile Review & Question series. You’ll learn how Agile teams use burndown charts, burnup charts, velocity, cumulative flow diagrams, cycle time, lead time, and defect trends to stay aligned and continuously improve. Then, you’ll test your knowledge with 10 scenario-based practice questions (Questions 91–100) with detailed explanations.
✅ You’ll learn how to:
• Interpret Agile metrics like velocity, cycle time, and burndown charts
• Spot bottlenecks and scope changes using visual tools
• Distinguish between lead time and cycle time in Agile delivery
• Track value through sprint goals, quality trends, and stakeholder reporting
• Apply Agile reporting practices for both teams and scaled environments
By practicing these questions, you’ll strengthen your ability to analyze metrics, guide stakeholder communication, and answer PMP exam questions with confidence.
Chapters:
0:00 Agile Metrics & Reporting Overview
2:35 Question 91
4:27 Question 92
Show More Show Less View Video Transcript
0:00
The topic we'll cover is agile metrics
0:02
and reporting. How agile teams use data
0:04
and visual tools to track progress,
0:06
improve transparency, and guide
0:08
decision-making throughout the delivery
0:10
process. In agile, metrics are not about
0:13
command and control. They're about
0:15
visibility, learning, and continuous
0:17
improvement. On the PMP exam, you'll be
0:20
tested not just on what the metrics are,
0:22
but when to use them, and what they mean
0:24
in real agile delivery. You should be
0:27
comfortable with burndown charts, which
0:28
show how much work remains in a sprint
0:30
or release. The slope tells you whether
0:32
you're on track or falling behind.
0:34
Burnup charts show completed work
0:36
against the total scope and make changes
0:39
to the scope visible, something
0:40
burndowns can hide. You'll also see
0:43
velocity trends, which average the
0:45
amount of work completed per sprint.
0:47
This helps forecast delivery dates and
0:49
scope completion. But remember, velocity
0:51
is a planning tool, not a performance
0:54
target. A cumulative flow diagram
0:56
visualizes how work moves across stages
0:59
from to-do to done by analyzing the
1:01
colored bands. You can spot bottlenecks,
1:04
measure flow efficiency, and see whether
1:06
your work in progress is stable or
1:08
growing out of control. Two other
1:10
important measures are cycle time and
1:12
lead time. Cycle time measures how long
1:14
it takes from starting work to
1:16
completing it. Lead time measures from
1:19
the moment a request is made until it's
1:21
delivered. On the exam, expect to see
1:23
scenarios where reducing either metric
1:26
improves responsiveness.
1:28
For quality, agile teams track defect
1:30
trends and escaped defects, which are
1:32
defects found after release. Reducing
1:34
these shows improved quality practices.
1:37
Pairing this with root cause analysis
1:38
helps prevent recurring issues. Teams
1:41
also track sprint goal achievement to
1:43
ensure they're delivering value, not
1:44
just closing tickets. Meeting sprint
1:46
goals consistently signals strong focus
1:49
and planning. The PMP exam may include
1:52
questions on stakeholder reporting in
1:54
agile. This is about showing progress
1:56
using working solutions and visual
1:58
artifacts like charts and conbon boards,
2:01
not long status reports. Transparency
2:04
comes from making progress visible, not
2:06
from static documents. In scaled agile
2:10
environments, metrics may roll up from
2:11
multiple teams. You'll need to
2:13
understand how reporting adapts to
2:15
support program level visibility without
2:17
sacrificing agility or overwhelming
2:20
teams with unnecessary metrics. And now
2:23
we'll go through 10 practice questions
2:24
that will test your knowledge of agile
2:26
metrics, how to interpret them, and how
2:28
to use them to drive delivery,
2:30
alignment, and transparency. Let's get
2:32
into the first question in this topic.
2:35
Question 91. Midway through the sprint,
2:38
the project manager notices that the
2:40
burndown chart shows little change over
2:42
the past several days, even though the
2:44
team has been working steadily. The team
2:46
confirms that several backlog items are
2:48
nearly complete, but have not yet been
2:50
marked as done. What should the project
2:53
manager do? A. Discuss with the team
2:56
whether extending the sprint would help
2:58
complete the remaining work and reflect
3:00
progress. B. Encourage the team to
3:03
update work item status promptly so the
3:06
chart reflects real progress. T. Work
3:09
with the product owner to see if
3:11
incomplete items should be deferred to
3:13
the next sprint for clearer reporting.
3:15
D. Reestimate incomplete items to
3:18
reflect remaining effort before updating
3:20
the chart. You can pause the video here
3:22
if you need more time to work on the
3:24
question. The correct answer is B. This
3:28
question focuses on how burndown charts
3:30
reflect progress and the importance of
3:32
keeping them up to date. In agile, a
3:34
burndown chart works best when tasks are
3:37
updated as soon as work is completed or
3:39
its status changes. Choice B is the best
3:42
option because it ensures transparency
3:44
by encouraging the team to update work
3:46
item status promptly. This allows the
3:48
chart to accurately show remaining work,
3:50
supports informed decisionmaking, and
3:53
avoids misleading stakeholders.
3:56
Choice A is incorrect. Extending the
3:58
sprint is not consistent with agile
4:00
practices as sprint lengths are fixed to
4:02
provide cadence and predictability.
4:04
Choice C is incorrect. Moving items to
4:07
the next sprint just to make the chart
4:08
look better is manipulating data rather
4:10
than addressing the root issue. Lack of
4:12
timely updates. Choice D is incorrect.
4:16
Reestimating work for the sake of the
4:18
chart adds unnecessary overhead and
4:20
doesn't solve the real problem of
4:22
delayed status updates. Let's move on to
4:25
the next question if you're ready.
4:27
Question 92. Midway through a release,
4:30
the sponsor reviews the burnup chart and
4:32
is concerned that the team's progress
4:34
line is flattening while the total scope
4:36
line is trending upward. Several new
4:38
features have been added due to recent
4:40
market changes, but the sponsor is
4:42
worried the product will not be ready by
4:44
the targeted release date. The project
4:46
manager wants to address the concern
4:47
while keeping stakeholders informed and
4:50
the team focused. What should the
4:52
project manager do first? A. Facilitate
4:55
a discussion with stakeholders to review
4:57
the impact of scope changes and adjust
4:59
expectations or priorities. B. Work with
5:02
the team to explore options for
5:04
increasing throughput, including
5:06
potential adjustments to work practices
5:08
or schedules. C. Collaborate with the
5:11
product owner to identify lower priority
5:14
features that could be removed from the
5:15
scope to protect the release date. D.
5:18
Update the release forecast based on the
5:20
latest velocity trend to provide
5:22
stakeholders with an updated delivery
5:24
projection. You can pause the video here
5:26
if you need more time to work on the
5:28
question. The correct answer is A. This
5:32
question tests your ability to interpret
5:34
a burnup chart and address scope changes
5:37
in agile. Burnup charts show both work
5:40
completed and total scope, making them a
5:43
valuable tool for detecting scope creep
5:46
early. Choice A is the best option
5:48
because it promotes transparency and
5:50
collaboration with stakeholders to
5:51
review the scope changes, discuss
5:53
trade-offs, and agree on next steps.
5:55
This aligns with agile values of
5:57
openness and stakeholder engagement.
5:59
Choice B is incorrect. While exploring
6:02
ways to improve throughput may help in
6:04
some cases, focusing first on team speed
6:07
without addressing scope creep risks
6:09
burnout and ignores the root cause.
6:12
Choice C is incorrect. Identifying lower
6:15
priority features is a valid technique,
6:17
but removing scope without stakeholder
6:20
input undermines trust and shared
6:22
ownership. Choice D is incorrect.
6:24
Updating the release forecast may be
6:26
useful for reporting, but without
6:28
stakeholder discussion, it only
6:29
communicates the problem. It doesn't
6:31
help resolve it. Let's move on to the
6:33
next question if you're ready. Question
6:35
93. A project manager is reviewing the
6:38
team's velocity over the last five
6:40
sprints. The numbers vary slightly, but
6:42
there is an overall upward trend. As the
6:44
team becomes more familiar with the
6:46
work, the sponsor asks for a release
6:49
forecast based on these results. What
6:51
should the project manager do? A. Use
6:54
the highest velocity achieved to
6:56
forecast delivery for maximum optimism.
7:00
B. Disregard earlier velocities and use
7:03
only the last sprints velocity for
7:05
accuracy. C. Average all sprint
7:07
velocities from the start of the project
7:09
to avoid bias. D. Use the recent
7:12
velocity trend to create a range-based
7:14
forecast that accounts for variability.
7:17
You can pause the video here if you need
7:19
more time to work on the question. The
7:22
correct answer is D. And this question
7:24
is about using velocity trends
7:26
effectively in agile forecasting.
7:28
Velocity is not just a number. Trends
7:31
reveal patterns that can improve
7:33
prediction accuracy while accounting for
7:35
change and uncertainty. Choice D is the
7:38
best option because it uses the recent
7:40
trend to produce a range-based forecast
7:43
which reflects both improvement and
7:45
natural variability. This creates
7:47
realistic expectations for stakeholders.
7:50
Choice A is incorrect. Using the highest
7:53
number assumes perfect conditions will
7:55
continue which is unrealistic and risky.
7:58
Choice B is incorrect. One sprint is too
8:00
small a sample size and could reflect
8:02
anomalies rather than the true
8:04
capability of the team. Choice C is
8:07
incorrect. Averaging all past sprints
8:09
may dilute the more relevant recent
8:11
performance data, especially if the
8:13
team's efficiency has significantly
8:15
changed. Let's move on to the next
8:17
question if you're ready. Question 94.
8:21
While reviewing the cumulative flow
8:23
diagram, the project manager notices
8:24
that the inrogress band has been
8:27
steadily widening over the last 2 weeks.
8:30
The team has not increased its work in
8:32
progress limits, but fewer items are
8:34
reaching the done stage. What should the
8:36
project manager do next? A. Encourage
8:39
the team to pick up additional small
8:41
tasks to help show progress across the
8:44
board. B. Investigate possible
8:46
bottlenecks and work with the team to
8:48
address causes limiting flow. C. Discuss
8:52
with the team whether temporarily
8:53
extending the sprint could help complete
8:56
more items in progress. D. reduce the
8:59
scope of the sprint backlog so that
9:01
remaining work can be finished sooner.
9:04
You can pause the video here if you need
9:06
more time to work on the question. The
9:08
correct answer is B. This question tests
9:11
your ability to interpret a cumulative
9:13
flow diagram and take action when flow
9:15
problems appear. A widening in progress
9:18
band often signals a bottleneck. Work is
9:21
entering the system faster than it is
9:23
leaving which reduces throughput. Choice
9:26
B is the best option because it focuses
9:28
on identifying and addressing the root
9:30
cause. Working with the team to remove
9:33
blockers or rebalance work is an agile
9:35
way to improve flow efficiency. Choice A
9:38
is incorrect. Taking on more small tasks
9:40
may give the appearance of progress, but
9:42
it worsens the work in progress and
9:45
delays completion of existing work.
9:48
Choice C is incorrect. Extending the
9:51
sprint length changes cadence and
9:54
predictability and does not fix the
9:56
underlying problem. Choice D is
9:59
incorrect. While reducing scope can
10:01
sometimes help in specific cases, it
10:03
doesn't solve systemic issues causing
10:05
the bottleneck. Let's move on to the
10:08
next question if you're ready. Question
10:11
95.
10:12
During a retrospective, the team
10:14
discusses ways to improve delivery
10:15
speed. The project manager suggests
10:17
tracking how long it takes to complete
10:19
work items after they begin actively
10:22
working on them in order to identify
10:24
delays in execution. Which metric should
10:26
the team use? A lead time, B throughput.
10:31
Cycle time, B velocity. You can pause
10:35
the video here if you need more time to
10:37
work on the question. The correct answer
10:39
is C. This question tests your
10:42
understanding of agile metrics and when
10:44
to use them. Cycle time measures the
10:46
time it takes from when a team starts
10:48
actively working on an item until it's
10:50
completed. It's a key metric for
10:51
spotting bottlenecks and improving
10:53
execution speed. Choice C is the best
10:56
option because it directly measures the
10:58
duration of active work, which is
11:00
exactly what the project manager wants
11:02
to track. Choice A is incorrect. Lead
11:05
time measures the time from when the
11:06
request is made until delivery, which
11:09
includes waiting time before work
11:11
starts. Choice B is incorrect.
11:14
Throughput counts the number of work
11:16
items completed in a given period but
11:18
does not track the time to complete each
11:20
one. Choice D is incorrect. Velocity
11:23
measures the amount of work often in
11:26
story points completed in a sprint, not
11:28
the time to complete individual items.
11:31
Let's move on to the next question if
11:33
you're ready. Question 96. In the past
11:36
three sprints, the team has seen an
11:38
increasing number of defects found after
11:40
release. The project manager wants to
11:42
improve product quality without slowing
11:44
delivery. What should the project
11:47
manager do first? A. Work with the team
11:50
to analyze defect trends and identify
11:52
root causes during retrospectives.
11:55
B. Collaborate with the QA team to
11:57
strengthen testing approaches and
11:59
improve coverage in upcoming sprints. C.
12:03
Allocate part of each sprint's capacity
12:05
to address quality improvements
12:07
alongside new feature work. D. Introduce
12:10
a peerreview process for all completed
12:12
work before it moves to the next stage.
12:15
You can pause the video here if you need
12:17
more time to work on the question. The
12:19
correct answer is A. This question
12:22
focuses on using defect trend data to
12:24
drive quality improvements in agile.
12:26
Reacting to defects without
12:28
understanding why they occur may lead to
12:30
short-term fixes but not lasting
12:32
improvement. Choice A is the best option
12:35
because it prioritizes root cause
12:37
analysis with the team using
12:39
retrospectives to discuss trends, find
12:41
systemic issues, and agree on targeted
12:43
changes that improve quality sustainably
12:46
without sacrificing delivery speed.
12:48
Choice B is incorrect. While improving
12:51
testing coverage can help detect defects
12:53
earlier, it addresses symptoms rather
12:56
than the underlying causes of defects.
12:59
Choice C is incorrect. Allocating sprint
13:02
capacity for quality improvement is
13:04
helpful but does not guarantee the right
13:06
actions will be taken without
13:07
understanding defect causes first.
13:10
Choice D is incorrect. Peer review can
13:13
catch some defects earlier, but it's
13:15
only one quality practice and may not
13:17
address deeper process or technical
13:19
issues. Let's move on to the next
13:22
question if you're ready. Question 97.
13:25
During the last three sprints, the team
13:27
has delivered all committed backlog
13:29
items. But in two of those sprints, the
13:31
sprint goal was not fully met. The
13:33
sponsor is concerned about whether the
13:35
team is delivering the right outcomes.
13:37
What should the project manager do? A.
13:40
In the next sprint planning, ensure the
13:43
team selects backlog items that can be
13:45
completed comfortably to help meet the
13:47
sprint goal. B. Continue tracking
13:50
delivery based on completed backlog
13:52
items as this reflects the team's actual
13:54
output. C. Work with the product owner
13:57
to refine backlog items so they have
13:59
clearer acceptance criteria and can be
14:02
completed within the sprint. D. Review
14:05
recent sprint goals with the team and
14:07
product owner to ensure they are clear,
14:09
outcome focused, and achievable. You can
14:12
pause the video here if you need more
14:14
time to work on the question. The
14:16
correct answer is D. This question tests
14:19
your ability to evaluate delivery
14:21
success beyond just backlog completion.
14:23
Completing all backlog items doesn't
14:25
necessarily mean the sprint goal, which
14:27
represents the intended outcome, is
14:29
achieved. Choice D is the best option
14:32
because it ensures sprint goals are
14:34
clear, outcomedriven, and realistic,
14:37
aligning the team's efforts with the
14:39
product vision and stakeholder
14:41
expectations. This keeps the focus on
14:43
delivering value, not just output.
14:46
Choice A is incorrect. Reducing work
14:48
commitment may make meeting the goal
14:50
easier, but it does not address the root
14:53
cause of misaligned or unclear goals.
14:56
Choice B is incorrect. Tracking only
14:59
backlog completion measures output, not
15:01
whether outcomes and business value are
15:03
being delivered. Choice C is incorrect.
15:07
Clearer acceptance criteria may improve
15:09
backlog quality, but it does not
15:11
guarantee that the work aligns with or
15:13
fulfills the sprint goal. Let's move on
15:16
to the next question. If you're ready.
15:18
Question 98. Two major defects were
15:21
reported by customers within days of the
15:24
latest release. These defects were not
15:26
found during development or testing. The
15:28
product owner is concerned about the
15:30
potential impact on customer trust and
15:32
the team is worried about quality
15:34
slipping in recent sprints. The project
15:36
manager wants to prevent similar issues
15:38
from occurring in future releases. What
15:40
should the project manager do first? A.
15:43
Work with the QA and development teams
15:45
to expand regression and exploratory
15:48
testing focused on high-risk areas. B.
15:51
Facilitate a root cause analysis with
15:53
the team to understand why the defects
15:55
escaped and agree on preventive actions.
15:58
C. Adjust the sprint plan to include
16:01
targeted defect prevention activities
16:03
alongside feature development. D.
16:06
Introduce a pre-lease checklist for the
16:08
development team to review before
16:10
deployment. You can pause the video here
16:12
if you need more time to work on the
16:14
question. The correct answer is B. This
16:17
question tests your understanding of
16:19
quality management and continuous
16:21
improvement in agile. While adding more
16:23
testing or checklists can help, they
16:25
treat the symptoms rather than solving
16:27
the underlying problem. Choice B is the
16:30
best option because a root cause
16:32
analysis engages the whole team to
16:34
identify why the defects escaped and
16:36
agree on specific process or technical
16:38
improvements to prevent similar issues
16:40
in the future. This approach addresses
16:42
the systemic causes, not just the
16:44
visible problems. Choice A is incorrect.
16:47
Expanding regression and exploratory
16:49
testing may detect more defects earlier,
16:52
but it doesn't explain why these
16:54
particular defects weren't caught.
16:56
Without understanding the root cause,
16:57
issues may continue. Choice C is
17:00
incorrect. Allocating time for defect
17:03
prevention is positive, but it risks
17:06
being unfocused without first
17:07
identifying the causes of the escaped
17:10
defects. Choice D is incorrect. A
17:12
checklist can help prevent some errors,
17:14
but it's unlikely to address deeper
17:17
process or testing gaps that allowed the
17:19
defects to escape. Let's move on to the
17:22
next question if you're ready. Question
17:24
99. A senior stakeholder says they want
17:27
a weekly detailed progress report from
17:29
the project manager because they are
17:31
used to traditional project updates. The
17:34
project manager wants to meet the
17:35
stakeholders needs while staying aligned
17:37
with agile principles. What should the
17:39
project manager do? A. Provide a weekly
17:43
written report summarizing team
17:44
activities and task completion status.
17:47
B. Share the team's daily scrum notes
17:51
and sprint backlog so the stakeholder
17:53
can track work in detail. C. Invite the
17:56
stakeholder to sprint reviews and
17:58
provide a high-level visual summary of
18:00
progress and outcomes. D. Create a
18:03
custom dashboard showing individual team
18:06
member productivity and hours worked.
18:08
You can pause the video here if you need
18:10
more time to work on the question. The
18:12
correct answer is C. This question tests
18:16
your understanding of balancing
18:17
stakeholder needs with agile values.
18:20
Agile prioritizes transparency and
18:23
collaboration through interactive value
18:26
focused events rather than static
18:28
detailed reports. Choice C is the best
18:31
option because sprint reviews give
18:33
stakeholders direct visibility into
18:35
progress, delivered value, and upcoming
18:38
plans while a visual summary reinforces
18:41
understanding without overwhelming them
18:43
with task level detail. This approach
18:46
also fosters engagement and feedback.
18:49
Choice A is incorrect. A static written
18:52
report focuses on activities and output,
18:54
which doesn't align with agile's
18:56
emphasis on value and collaboration.
18:58
Choice B is incorrect. Providing daily
19:01
scrum notes and backlog details may
19:03
overwhelm the stakeholder and still
19:06
doesn't focus on delivered outcomes.
19:08
Choice D is incorrect. Measuring and
19:11
reporting on individual productivity
19:13
contradicts agile's focus on team
19:15
performance and collaboration. Let's
19:17
move on to the next question if you're
19:19
ready. Question 100. In a large
19:22
organization using a scaled agile
19:24
framework, multiple teams are working on
19:26
different components of the same
19:28
product. Senior leadership wants to
19:30
understand overall progress toward the
19:32
next release without receiving separate
19:34
reports from each team. The project
19:36
manager is responsible for consolidating
19:38
progress updates while staying aligned
19:40
with agile principles. What should the
19:43
project manager do? A. Request that each
19:46
team submit a weekly written status
19:48
report to be merged into a master
19:50
summary for leadership. B. Schedule a
19:53
recurring meeting with all scrum masters
19:55
to review each team's burndown chart and
19:58
compile a joint report. C. Use a shared
20:01
spreadsheet where each team updates its
20:03
completed story points and blockers
20:05
weekly. D. Create a program level
20:08
dashboard that consolidates real-time
20:10
cross teamam progress dependencies and
20:12
risks. You can pause the video here if
20:15
you need more time to work on the
20:16
question. The correct answer is D. This
20:20
question tests your understanding of
20:22
scaled agile reporting and program level
20:24
transparency. In large initiatives,
20:27
leadership needs a holistic view of
20:29
progress without overburdening teams
20:31
with additional reporting tasks. Choice
20:34
D is the best option because a program
20:36
level dashboard consolidates real-time
20:38
data from multiple teams showing
20:40
dependencies, risks, and overall
20:42
progress in one view. It supports
20:45
decision-m and promotes transparency
20:47
across teams without duplicating work.
20:51
Choice A is incorrect. Compiling weekly
20:54
written reports increases administrative
20:56
effort and delays visibility. Choice B
20:58
is incorrect. While scrum master syncs
21:01
can be valuable, manually compiling
21:04
burndown charts into a report is
21:06
inefficient and less timely than
21:08
automated tracking. Choice C is
21:10
incorrect. Shared spreadsheets can
21:12
provide some visibility, but often
21:14
require manual updates and lack the
21:16
real-time insights needed in scaled
21:18
environments. Congratulations, you've
21:21
completed all 10 questions for agile
21:23
metrics and reporting. That's 100 agile
21:25
questions mastered so far. That is an
21:28
incredible milestone and you're building
21:29
a solid foundation for your PMP exam.
21:32
Let's move forward together when you are
21:34
ready for the next topic.