All courses > Business administration > Project management ::

Essential Jira Reports for Project Managers: Interpreting Progress and Predictability

Capítulo 10

Estimated reading time: 11 minutes

Why reports matter for project managers

Jira reports are most useful when they answer a specific decision question: Are we on track? Is the plan stable enough to forecast? Where is flow getting stuck? This chapter focuses on interpreting signals (not just reading charts) and turning them into a status narrative with actions.

1) What question each report answers and when to use it

Burndown chart

Question it answers: “Are we likely to finish the sprint scope by the sprint end date?”

When to use: Daily during a sprint, especially in standups and mid-sprint check-ins.

Best for timeboxed work (Scrum sprints).
Best when the sprint backlog is relatively stable after sprint start.

Burnup chart

Question it answers: “How much have we completed, and how has total scope changed over time?”

When to use: Sprint-level and release-level conversations where scope change is expected or needs to be made explicit.

Continue in our app.

Listen to the audio with the screen off.
Earn a certificate upon completion.
Over 5000 courses for you to explore!

Or continue reading below...

Download the app

Best for explaining scope growth/shrink without “hiding” it inside a burndown line.
Useful for stakeholders who ask “Why does it look like we’re behind?”

Velocity chart

Question it answers: “What is our typical delivery capacity per sprint, and is it stable enough to forecast?”

When to use: Sprint planning and release forecasting; monthly health checks.

Best when the team uses consistent estimation (e.g., story points) and stable team composition.
Use trends, not single-sprint spikes.

Cumulative Flow Diagram (CFD)

Question it answers: “Is work flowing smoothly through states, or are we accumulating bottlenecks?”

When to use: Weekly delivery reviews, flow health checks, and when cycle time is rising.

Best for Kanban or hybrid teams; also useful within a sprint to detect WIP pile-ups.
Excellent for spotting where work is waiting (queue growth).

Control chart

Question it answers: “How long does work typically take from start to done, and how variable is it?”

When to use: Forecasting delivery dates, investigating predictability, and setting expectations with stakeholders.

Best when workflow statuses are configured to represent “in progress” vs “done” clearly.
Use percentiles (e.g., 50th/85th) rather than averages when variability is high.

Sprint report

Question it answers: “What was committed vs completed, what was added/removed, and what carried over?”

When to use: End-of-sprint review and retrospective preparation; also for explaining sprint outcomes to stakeholders.

Best for capturing scope changes and incomplete work with context.
Useful for identifying churn and mid-sprint re-planning.

Release progress (Version/Release report)

Question it answers: “For a target release, what’s done, what’s in progress, what’s not started, and what’s at risk?”

When to use: Weekly release status, go/no-go readiness, and stakeholder updates.

Best when issues are consistently assigned to Fix Versions (or Releases) and statuses reflect reality.
Pair with flow metrics when you need predictability, not just counts.

2) How to interpret signals (scope change, churn, bottlenecks, variability)

Burndown: reading slope, flatlines, and “cliffs”

Healthy signal: A generally downward trend with small step-downs as items complete.
Scope change signal: The remaining work line jumps up (new work added) or drops sharply (work removed or re-estimated). Ask: “Was scope intentionally changed? Who approved it?”
Churn signal: Frequent up-and-down movement (re-estimation, tickets reopened, scope swapped). Ask: “Are we thrashing due to unclear requirements or unplanned work?”
Late completion signal: Flatline for most of the sprint then a steep drop near the end. This often indicates large stories, late testing, or work not being moved to Done promptly.

Practical check: If burndown is flat by mid-sprint, review WIP and story slicing. Confirm that workflow steps (e.g., QA) are not hiding completion until the last day.

Burnup: separating progress from scope movement

Two lines to watch: Completed work (rising) and total scope (may rise/fall).
Scope creep signal: Total scope line rises faster than completed line. This is not “team underperformance” by default; it is a planning/control signal.
Stabilization signal: Total scope flattens while completed continues rising—this is when forecasting becomes more reliable.

Practical check: When stakeholders ask for a date, first ask whether scope is fixed. If not, use burnup to show the trade-off: date vs scope.

Velocity: stability and capacity, not a performance score

Stable signal: Velocity varies within a narrow band across several sprints.
Capacity change signal: A step change (sustained drop or rise) often reflects team size changes, holidays, major support load, or workflow changes.
Planning risk signal: High variance sprint-to-sprint makes release forecasting unreliable; treat forecasts as ranges, not points.

Practical check: Use a rolling average (e.g., last 3–5 sprints) and note anomalies (on-call week, production incident). Avoid “target velocity.”

CFD: spotting bottlenecks and WIP overload

A CFD shows bands for each status over time. The thickness of a band indicates how much work is in that state.

Bottleneck signal: One band (e.g., “In Review” or “QA”) thickens over time while upstream bands keep feeding it. This indicates a constraint.
WIP overload signal: “In Progress” band grows and stays thick; throughput doesn’t increase. This often correlates with multitasking and longer cycle times.
Flow improvement signal: Bands remain relatively parallel and stable; “Done” increases steadily.

Practical check: When a band thickens, ask: “What is preventing items from moving? Is it skill coverage, environment, approvals, or unclear acceptance criteria?” Then apply a WIP limit or swarm on the constraint.

Control chart: variability, outliers, and forecasting

A control chart plots cycle time per issue. The key is understanding distribution and variability.

Predictability signal: Most points cluster tightly; percentiles are close together (e.g., 50th=4 days, 85th=6 days).
Variability signal: Wide spread with frequent outliers; percentiles far apart (e.g., 50th=4 days, 85th=14 days). This means delivery dates should be communicated as ranges.
Process change signal: A visible shift downward (faster) or upward (slower) after a certain date may indicate a workflow change, new policy, or new bottleneck.

Practical check: Use the 85th percentile as a conservative planning input: “Most items finish within X days.” Investigate outliers: blocked work, waiting for review, unclear scope, or external approvals.

Sprint report: commitment integrity and carryover

Churn signal: Many issues added after sprint start or removed mid-sprint. This indicates unstable intake or frequent priority changes.
Carryover signal: Many incomplete issues roll into the next sprint. This suggests overcommitment, oversized stories, or hidden downstream work (testing, integration).
Completion pattern signal: If most completion happens at the end, check for late QA, large batch sizes, or workflow states not updated daily.

Practical check: Compare “Completed” vs “Not Completed” and list the top 3 reasons for non-completion (e.g., blocked, underestimated, scope unclear). Turn those into retro actions.

Release progress: readiness and risk concentration

Risk signal: A high proportion of “In Progress” late in the timeline, or many items not started close to the target date.
Hidden work signal: Many items in “In Review/QA” with slow movement indicates downstream constraint; release progress alone may look “fine” if you only count Done.
Scope volatility signal: Frequent additions to the release version; pair with burnup to show scope movement.

Practical check: Segment release items by size/type (e.g., stories vs bugs) and identify the “critical few” that drive readiness. Use control chart percentiles to estimate whether remaining items can finish in time.

3) Common misreadings and how to avoid them

Report	Common misreading	Why it’s wrong	How to avoid it
Burndown	“Flat burndown means the team did nothing.”	Work may be in progress but not reaching Done; workflow updates may lag.	Check WIP states, blocked items, and whether Definition of Done pushes completion late (e.g., QA at end).
Burndown	“We’re behind because the line is above the ideal.”	Ideal line assumes linear completion and stable scope; real work is lumpy.	Look for scope jumps and completion batching; use burnup to explain scope changes.
Burnup	“Completed line is rising, so we’re fine.”	If total scope rises faster, you may still miss the target.	Compare the gap between completed and total scope; discuss scope control decisions.
Velocity	“Higher velocity means better performance.”	Velocity is relative to estimation; teams can inflate points or change sizing.	Treat velocity as a planning input only; keep estimation consistent; watch stability over time.
Velocity	“We should set a velocity target.”	Encourages gaming and reduces quality; ignores variability and unplanned work.	Use ranges (rolling average ± variation) and focus on flow and predictability improvements.
CFD	“A thick band means the team is productive (busy).”	Thick WIP bands often mean waiting and longer cycle times.	Interpret thickening as a bottleneck signal; reduce WIP and address constraints.
Control chart	“Average cycle time is 6 days, so everything takes 6 days.”	Variability and outliers matter; average hides risk.	Use percentiles (50th/85th) and investigate outliers; communicate forecasts as ranges.
Sprint report	“Unfinished work means the team failed.”	It may reflect scope churn, overcommitment, or external blockers.	Separate controllable vs uncontrollable causes; track carryover reasons and improve planning/slicing.
Release progress	“80% done means we’re 80% ready.”	Remaining 20% may contain the hardest integration/testing; status may not reflect readiness.	Identify critical items; validate readiness criteria; pair with CFD/control chart for flow risk.

Step-by-step: a repeatable interpretation routine

Use this routine whenever you open a report, so you consistently turn charts into decisions.

Confirm the data boundary: Which board, which sprint/release, which date range, which issue types?
Check for scope movement first: In burndown/burnup/sprint report, identify additions/removals/re-estimates.
Check flow next: Use CFD to see where work is accumulating; validate with a quick look at the board columns.
Check predictability: Use control chart percentiles and outliers to understand delivery risk.
Translate into actions: Name the constraint, decide an intervention (swarm, WIP limit, slice stories, expedite review), and assign an owner/timebox.

4) Exercise: analyze report screenshots and write a status narrative with actions

Exercise setup

Collect (or use provided) screenshots for the same team/time period:

Sprint burndown
Sprint burnup (or scope change view if available)
Velocity chart (last 6–8 sprints)
Cumulative Flow Diagram (last 2–4 weeks)
Control chart (last 30–60 days)
Sprint report (current sprint)
Release progress for the next release

What to look for (guided questions)

Burndown: Where are the scope jumps? Are there long flat periods? Is completion clustered at the end?
Burnup: Did total scope change? When did it stabilize (if at all)? Is completed work rising steadily?
Velocity: Is there a stable band? Any step changes due to capacity shifts? How wide is the variance?
CFD: Which status band is thickening? Is WIP growing? Is “Done” increasing at a steady rate?
Control chart: What are the 50th and 85th percentile cycle times? Are there many outliers? Do outliers cluster around a workflow step?
Sprint report: How many issues were added after sprint start? What carried over and why?
Release progress: What proportion is not started vs in progress? Are critical items still upstream (e.g., not started)?

Write a short status narrative (template)

Write 6–10 sentences. Include decisions and actions, not just metrics. Use this structure:

1) Progress summary (what is done and what is trending): 1–2 sentences. 2) Scope and churn (what changed, why it matters): 1–2 sentences. 3) Flow and bottlenecks (where work is stuck, evidence): 1–2 sentences. 4) Predictability / delivery risk (variability, forecast range): 1–2 sentences. 5) Actions (specific interventions, owners, timeboxes): 2–3 sentences.

Example inputs (simulate what you see in screenshots)

Burndown shows two upward scope jumps on days 3 and 6; line is mostly flat until day 8, then drops sharply.
Burnup shows total scope increased by ~20% mid-sprint; completed line rises late.
Velocity over last 6 sprints: 32, 28, 35, 18, 22, 20 (notice a sustained drop after sprint 3).
CFD shows “In Review” band thickening over the last 10 days; “In Progress” also slightly increasing.
Control chart: median cycle time 5 days; 85th percentile 13 days; several outliers at 20+ days.
Sprint report: 12 issues added after sprint start; 7 issues not completed, 4 of them in “In Review.”
Release progress: 60% done, 25% in progress, 15% not started; two critical stories are not started.

Example status narrative (what “actions, not just metrics” looks like)

This sprint is trending to complete most committed work, but completion is batching late, with a sharp drop in remaining work only in the final third of the sprint. Total sprint scope increased by roughly 20% due to mid-sprint additions, which explains why the burndown deviates from the ideal line and increases carryover risk. Flow data indicates a review/QA constraint: the CFD shows the “In Review” band thickening, and the sprint report confirms multiple incomplete items stalled in review. Predictability is currently moderate-to-low: while the median cycle time is 5 days, the 85th percentile is 13 days with several 20+ day outliers, so remaining work should be forecast as a range rather than a single date. Actions: (1) timebox a review swarm for the next 48 hours with two engineers assigned to clear the review queue; (2) apply a temporary WIP limit on “In Progress” to prevent feeding the bottleneck; (3) split the two not-started critical release stories into smaller vertical slices today and start the highest-risk slice first; (4) agree with stakeholders that any new sprint additions require explicit trade-off (swap out equal scope) to reduce churn.

Now answer the exercise about the content:

A project manager wants to explain progress while making scope changes visible during a sprint or release conversation. Which Jira report is best suited for this purpose?

You are right! Congratulations, now go to the next page

You missed! Try again.

The burnup chart shows two lines: completed work and total scope. This makes scope changes (growth or shrink) visible instead of hiding them in a single remaining-work line, supporting clearer progress and forecasting discussions.