Jira Burndown in Tableau: Planned, Actual & Projected on One Chart

1. Jira Burndown in Tableau

Title

Business Analytics · Live Build Session

Planned, Actual, and Projected on one chart — connect, relate, pivot, and calculate your way to a single burn-up line, plus the data-hygiene issues and version limitations you'll actually hit.

2. What you'll walk away with today

Objectives

This session builds one chart from a real (messy) Jira export: Planned + Actual + Projected on a single burn-up line. By the end you can:

• Explain why a relationship, not a join, keeps Epics and Features honest.
• Pivot three wide date columns into one long Milestone Type / Milestone Date pair.

• Write the running % Complete calc with the FIXED-LOD denominator, and say why a raw or series-only denominator lies.
• Style Planned / Actual / Projected distinctly, mark today with a TODAY() line, and know Tableau's two real limitations here.
• Audit a raw export for column shifts, typo dates, and orphan foreign keys before you trust a single number.

Concretely: everything above happens against one real (messy) Jira export — the same file you'll have open today. You'll build across 7 parts, roughly 60–75 minutes end to end, with two deliberate return trips to an audit mindset: once on the raw data (Part 2), once on the finished chart (Part 7).

3. What survived from The Data Analyst's Toolkit — First Session (Sports Business)?

Warm-up

4. Show, don't tell: the finished chart

Concept

Before wiring anything up, look at where you're headed. The reference workbook's finished chart has three lines on one axis, colored by Milestone Type.

A vertical TODAY() line splits history from forecast. One chart tells the entire project story: what was planned, what's actually done, and what's expected next — and every piece of it comes from a real, occasionally messy, Jira export.

The takeaway: every line you're about to build is a promise about honesty — solid means it already happened, dashed means it's a guess, and the gap between Planned's 100% and Actual's 41% is the entire point of the chart.

5. Fill in: Look for Show, don't tell: the finished chart

Comparison

6. Part 1 — Connect & Relate

Section

Segment 1

7. Roadmap for Part 1

Concept

In this part: wire up the two Jira tables, see why a relationship (not a join) keeps every count honest, and build the validation sheet you'll lean on for the rest of the session. About 5 minutes in a live session — the shortest part, but everything downstream depends on getting it right.

8. Two tabs, one relationship

Concept

Before any pivot or calculation, Tableau needs to know how these two tables relate to each other — get this wrong and every count downstream is suspect. That's the job of this first part.

The export is two Excel tabs: Epics (Parents) — 5 rows — and Features (Children) — 44 rows — linked by Features.Parent Epic = Epics.Key.

relationship — A logical-layer link between two tables that keeps each table at its own grain — one row per epic, one row per feature — until a sheet actually needs to combine them. Contrast with a physical join, which flattens the tables into one.

In plain words: Epics and Features are separate lists that happen to reference each other; a relationship is just Tableau remembering that reference without merging the lists into one.

9. Break it if you can: Two tabs, one relationship

Counterexample

10. Relationships keep the grain; joins flatten it

Intuition

Picture Epics and Features as two separate stacks of index cards. A relationship is a note saying 'this card in stack B belongs to that card in stack A' — both stacks stay intact until you ask a question that needs both.

A physical join, by contrast, actually staples every matching pair of cards together into one new stack. At 49 total rows here it's invisible on a chart of sums — but every Feature row would duplicate for its Epic, and any Epic-level SUM() would silently double-count.

Another way to picture it: a relationship is like looking up a contact's phone number only when you need to call them. A join is like photocopying that phone number onto every page of a 44-page document — accurate today, but now there are 44 copies to keep in sync, and 44 chances to double-count if you ever SUM() that page.

11. Guess the shape of the answer: Connect and relate the tables

Estimation

12. Connect and relate the tables

Worked example

Click-path: Connect → Microsoft Excel → the workbook. Drag Epics (Parents) onto the canvas, then Features (Children) beside it — Tableau auto-detects Features.Parent Epic = Epics.Key as a relationship in the logical layer.

On screen right now: the Data Source canvas shows two boxes — Epics (Parents) and Features (Children) — connected by a thin line with a small relationship icon, not a solid join line. Clicking that connecting line pops up the editor showing Features.Parent Epic = Epics.Key.

13. Work backwards from the answer: Connect and relate the tables

Reverse engineer

14. What has to be given first: Build the validation sheet

Missing information

15. Build the validation sheet

Worked example

That's 42 features under the 5 epics. The remaining 2 — DPN-060 and DPN-061 — don't show up under any epic filter yet. Hold that thought; it's Part 2's second teaching moment.

On screen right now: Rows shows five epic keys (DPN-001…DPN-005), and Text shows five numbers that add up to 42 visible plus 2 hidden orphans — 44 total. If the sheet shows one blended total instead of five separate rows, Epic Key isn't on Rows yet.

16. What each one costs: Build the validation sheet

Trade off

17. Something is wrong here: joining instead of relating

Anomaly

18. Trap: joining instead of relating

Trap

Data Source canvas: drag Epics + Features onto the SAME physical layer
-> creates a physical join: Features.Parent Epic = Epics.Key

Data Source canvas: drag Epics, then Features NEXT to it (not onto it)
-> Tableau infers a relationship: Features.Parent Epic = Epics.Key

19. Part 2 — Audit Before You Build

Section

Segments 2–3

20. Roadmap for Part 2

Concept

In this part: re-point the data source at the RAW file and watch a real count drop from 44 to 29, then track down why — a 15-row column shift, three typo dates, and two orphan foreign keys. About 20 minutes combined (10 for the validation-sheet discovery, 10 for the deep-dive) — the longest part of the session, because everything you build afterward is only as trustworthy as this audit.

21. The validation sheet's real job

Concept

This next stretch is the longest part of the session for a reason: everything you build on top of bad data is bad, so real time goes here first, making sure the data is actually what you think it is.

A validation sheet isn't busywork — it's the tripwire that catches a broken import before it reaches a chart. "Does this count make sense?" is the single most useful question in this whole session.

Rule of thumb: if a total looks smaller than it should, don't assume the project shrank. Assume the data did.

The takeaway: a validation sheet's job isn't to look tidy — it's to be the one place you'd actually notice if a count silently changed.

22. By analogy: The validation sheet's real job

Analogy

23. Predict the next row: The count that shouldn't drop

Pattern

24. The count that shouldn't drop

Worked example

Setup: the reference workbook is built against a cleaned copy of the export. Now re-point that same data source at the untouched raw file instead and refresh.

Planned drops from 44 to 29 — a loss of 15 features (~34% of the dataset). Projected and Actual don't move; their sparsity comes from a different, unrelated cause covered later. Ask: why did Planned alone just lose 15 features?

On screen right now: after refreshing to the raw file, the Planned count drops from 44 to 29 while Actual and Projected hold steady at 18 and 11 — that visible, single-series drop is the whole “aha” moment this segment is built around.

25. Column positions are part of the data contract

Intuition

Tableau's pivot doesn't read column headers at pivot time — it reads whatever sits in the columns you selected when you built the pivot. If a hand-edit shifts values one column left, the pivot faithfully reshapes the wrong cells: empty ones.

There's no error message, no red flag. The pivot just quietly produces nulls where dates should be — which is exactly the 15-feature gap you just found.

In plain words: Tableau trusts you drew the map correctly. It reads column H expecting a Due Date; if a hand-edit put that date in column G instead, Tableau doesn't go looking for it — it just reports column H as empty.

26. Diagnose the shift: DPN-038

Worked example

Open the Features sheet in Excel. Scroll to row 31 (DPN-038, the first row of Build 3A) and compare it with row 2 (DPN-006, a healthy Build-0 row).

Impact: these 15 rows contribute zero rows to Planned, Projected, and Actual after the pivot — that's the 44→29 drop, plus part of the Projected/Actual sparsity you'll see later.

On screen right now: scrolling to Excel row 31, columns F and G are filled with Excel serial numbers (46204, 46295) while H, I, and J sit empty — compare that instantly to row 2, where F holds a text string and G through J all hold real values.

27. Trap: assuming it's just sparse data

Trap

28. Typos slip through silently too

Concept

You just found a structural problem — a whole column shifted. This next stretch is about a quieter kind of problem: the values themselves being simply wrong, even though every column is in the right place.

A shifted column is a structural defect. A typo date is a value defect — and Tableau validates neither. Both flow straight into your chart unless you catch them first.

This export has three: one plain decade typo, one typo compounded with the column shift, and one date that just doesn't add up next to its neighbors.

29. Teach it back: Typos slip through silently too

Explain it

30. DPN-013 — a decade typo

Worked example

DPN-013 (Build 0, epic DPN-001) is Closed / Resolution: Done — a legitimately finished feature.

Likely correct value: 2026-01-30 — a plausible four-month slip past a September 2025 due date, not an eleven-year one.

On screen right now: with the chart filtered to just DPN-013, the Milestone Date axis suddenly stretches out to include the year 2036, squeezing every other feature's real 2025–2027 activity into a thin band on the left edge.

31. DPN-042 — a compound error

Worked example

DPN-042 (Build 3A, epic DPN-004, row 35) is already one of the 15 column-shifted rows — its H/I/J are empty, so it contributes nothing to any series yet. But look at where its values landed.

On screen right now: DPN-042 doesn't appear anywhere on the chart yet — it's invisible, because its H/I/J pivot columns are empty. The only way to see the problem at all is to go back into the Excel source and read columns F and G directly.

32. DPN-021 — a coherence check

Worked example

DPN-021 (Build 1, epic DPN-002) isn't shifted or an obvious typo, but its three dates don't tell a consistent story.

On screen right now: nothing looks visibly wrong on the chart itself — DPN-021 plots as an ordinary point. This is a spreadsheet-only catch, which is exactly why a coherence check has to be a deliberate step, not something you wait to stumble on visually.

33. Fill in: Value for DPN-021 — a coherence check

Comparison

34. Something is wrong here: "Tableau should catch these errors"

Anomaly

35. Trap: "Tableau should catch these errors"

Trap

36. Orphan Parent Epic: a foreign key pointing nowhere

Concept

One more category of silent failure, and then Part 2 is done: what happens when a foreign key points at something that simply isn't there.

DPN-060 and DPN-061 both list Parent Epic = DPN-006. Check the Epics sheet: it only contains DPN-001 through DPN-005. DPN-006 is a Feature, not an Epic.

orphan row — A row whose foreign key value doesn't match any row on the other side of a relationship. The relationship match simply fails — the row isn't deleted, it just never joins into any epic-scoped view.

37. Take the definitions apart: relationship vs orphan row

Definition probe

38. Find the missing two

Worked example

Filter the validation sheet to Epic DPN-001. You see exactly 9 features — correct, matching the table from Part 1.

On screen right now: filtering the validation sheet to DPN-001 shows exactly 9 rows — correct on its face — and nothing on screen hints that two more features (DPN-060/061) exist anywhere. Their absence IS the lesson; there's no error banner to notice.

39. Draw the shape of it: Find the missing two

Blank canvas

40. Trap: "I'll just delete the bad rows"

Trap

41. Break it on purpose: "I'll just delete the bad rows"

Break the constraint

42. Part 3 — Pivot to Long Format

Section

Segment 4

43. Roadmap for Part 3

Concept

In this part: reshape three wide date columns into one long Milestone Type / Milestone Date pair, so a single axis can hold all three series. About 5 minutes — short and mechanical, and the one step that makes everything after it possible.

44. Wide data can't share one axis

Concept

The data is clean now (or you know exactly what's still broken). Before the chart can show three lines, the data itself has to change shape — that's this part.

Right now Due Date, Planned Completion, and Resolved are three separate columns. Tableau can only put ONE date field on a continuous axis — you'd need a dual axis (caps at two) or Measure Values (visually noisy) to force three.

tidy data — Data shaped so each row is one observation and each column is one variable. Here, one 'feature' isn't one observation — one (feature, milestone type) pair is.

In plain words: tidy data means one row = one observation. Right now one feature spans three columns of dates; after the pivot, one feature spans three ROWS, one per milestone — which is what lets a single axis show all three.

45. Pivot = turn columns into rows

Intuition

Picture the three date columns as three separate lanes on a highway. A pivot merges them into a single lane with a sign on each car saying which lane it came from — one axis (Milestone Date), one label (Milestone Type) a color encoding can read directly.

Every feature that had three date columns now becomes three rows: one row for its Planned date, one for its Projected date, one for its Actual date.

Another way to say it: a wide layout is like a sign-in sheet with three separate columns for “Monday visit,” “Tuesday visit,” and “Wednesday visit.” A tidy, pivoted version has one column for “visit date” and one column for “which day” — every visit gets its own row, sign-in-sheet style, no matter how many days someone came in.

46. Where does each piece belong: Jira Burndown in Tableau: Planned, Actual &…

Sorting

47. Guess the shape of the answer: Build the pivot

Estimation

48. Build the pivot

Worked example

Click-path: open the Features table's physical layer. Select Due Date (Planned), Planned Completion (Projected), and Resolved (Actual) (Ctrl/Cmd-click all three) → right-click → Pivot.

On screen right now: the Features physical table used to show one row per feature with three separate date columns; after Pivot, the same table shows three rows per feature sharing two new columns — Milestone Type and Milestone Date — with the original three date columns folded into them (reshaped, not deleted).

49. Watch it run: Build the pivot

Pattern

50. Null dates are signal, not noise

Concept

One immediate side effect of the pivot needs addressing before you build anything on top of it: some of those new rows will have a blank date. That's expected — how you handle it matters.

An unresolved feature has no Actual date; a Build-0 feature might have no Projected date. After the pivot those rows still exist — with Milestone Date = null — because "not done yet" and "no forecast issued" are real, true facts about the project.

Handling rule: exclude nulls per-visualization (a Milestone Date filter on the sheet), never delete them from the source. Deleting would erase the fact that a feature exists and just hasn't hit that milestone.

51. Something is wrong here: three measures on a shared axis instead

Anomaly

52. Trap: three measures on a shared axis instead

Trap

53. Part 4 — The Running % Complete Calc

Section

Segments 5–6

54. Roadmap for Part 4

Concept

In this part: build a raw running count with COUNTD, then turn it into a percentage using a FIXED-LOD denominator that refuses to let any one series grade its own homework. About 11 minutes (3 for the raw count, 8 for the calculation and its table-calc scope) — this is the conceptual heart of the whole session.

55. Before a percentage, get a raw count

Concept

Every percentage is a fraction wearing a costume. Before writing the % formula, build its numerator out in the open so you can see exactly what's being counted.

Drag Milestone Date (continuous) to Columns and COUNTD([Key]) to Rows, Milestone Type to Color. You now see three lines of raw cumulative feature counts, rising left to right.

Why COUNTD, not COUNT(rows): the pivot just tripled every feature into three rows. COUNT([Number of Records]) would count each feature three times over; COUNTD([Key]) counts each distinct feature key exactly once per date it appears.

56. The raw counts you should see

Worked example

On the raw file, the running COUNTD per series should climb toward:

On screen right now: three lines climb from left to right, topping out at three different heights: Planned's line reaches highest (29), Actual reaches partway (18), and Projected reaches lowest (11) — this is the raw file, before any of Part 2's fixes are applied.

57. Watch it run: The raw counts you should see

Pattern

58. Something is wrong here: COUNT(rows) after a pivot

Anomaly

59. Trap: COUNT(rows) after a pivot

Trap

COUNT([Milestone Date])   -- or SUM([Number of Records])

60. The % Complete formula

Concept

Before the formula itself, here's what each piece needs to do in plain English: RUNNING_SUM just means ‘keep a running tally as we move left to right along the dates.’ COUNT means ‘how many features hit this exact date.’ FIXED means ‘count something once, over the whole table, no matter what date or series we happen to be looking at.’ Put together: a running tally of features-per-date, divided by one constant total.

Create a calculated field named % Complete (running):

RUNNING_SUM(COUNT([Milestone Date])) / ATTR({FIXED : COUNTD([Key])})

COUNT([Milestone Date]) counts features per date, skipping nulls automatically. RUNNING_SUM(...) accumulates that count left to right along the date axis. ATTR({FIXED : COUNTD([Key])}) is a constant: the total distinct feature count (44), computed once, ignoring series or nulls.

61. Why per-series totals lie

Intuition

Imagine dividing the Actual series by its OWN non-null total instead — 18 resolved features divided by 18 (its own count). That reaches 100%. But 18 out of the project's real 44 features is only 41% complete. The series would be lying about the whole project by only ever grading itself.

The FIXED LOD sidesteps this entirely: the denominator is the same 44 for every series, every date, no matter how many of that series' own rows are null.

The takeaway: “percent complete” only means something if everyone agrees what 100% is. A FIXED denominator forces every series to agree: 100% is always all 44 features, not just the ones that happen to have data in that particular series.

62. Predict the next row: Configure the table calculation

Pattern

63. Configure the table calculation

Worked example

Right-click the % Complete (running) pill on Rows → Edit Table Calculation → Compute Using → Specific Dimensions.

On screen right now: three separate lines, each starting near 0% at its own earliest date and climbing independently. If instead you see one merged line, or three lines that all jump straight to 100%, Compute Using is set wrong — recheck the settings table two beats back.

64. Trap: the Actual series self-normalizes to 100%

Trap

RUNNING_SUM(COUNT([Milestone Date])) / ATTR({FIXED : COUNTD(IF NOT ISNULL([Resolved]) THEN [Key] END)})

ATTR({FIXED : COUNTD([Key])})

65. Part 5 — Style: Color, TODAY(), Line Pattern

Section

Segments 7–8

66. Roadmap for Part 5

Concept

In this part: give the three series meaningful colors, mark today's date with a reference line, and encode Projected as a dashed line (with a fallback for older Tableau versions). About 7 minutes (2 for color, 5 for the TODAY() line and line pattern) — the math is already done, so this is where the chart starts telling its story without you narrating it.

67. Color must encode meaning

Concept

The math is done; the rest of this part is about making the chart tell its story to someone who's only glancing at it for three seconds.

Milestone Type on Color already separates the three lines. But which colors say what you mean matters: a chart reader should feel confidence differences at a glance, not just count distinct hues.

68. What each one costs: Color must encode meaning

Trade off

69. Assign the series colors

Worked example

On screen right now: the legend reads Planned / Actual / Projected in gray-blue, dark green, and pale green — glance at the chart and the darkest line is immediately the one you can trust most (Actual), which is the whole design intent.

70. Something is wrong here: three equally bright colors

Anomaly

71. Trap: three equally bright colors

Trap

72. Which of these survive contact with Jira Burndown in Tableau: Planned, Actual &…?

Two truths and a lie

73. TODAY() marks history vs. forecast

Concept

One more encoding decision before line style: where does “now” sit on this chart, and how does a viewer know it without reading a single label?

A reference line at TODAY() is the one visual element that tells a viewer, without reading anything, where fact ends and forecast begins.

Click-path: right-click the Milestone Date axis → Add Reference Line → Scope: Entire Table, Line: Constant, Value: TODAY(), Label: "Today", Style: solid gray.

74. Add the reference line

Worked example

On screen right now: a single vertical gray line now crosses the chart at today's date, with a small “Today” label — every Planned/Actual point to its left is confirmed history; everything to its right, including the whole Projected series, is forecast territory.

75. Encoding uncertainty with line style

Concept

Color already tells Planned/Actual/Projected apart, so why add a second signal? Because not every viewer reads a legend carefully, and dashed-vs-solid still works even for someone who can't quite tell your two greens apart.

Color already separates the three series, but a dashed Projected line adds a second, redundant signal: "this is a guess, not a fact" — useful for anyone who can't easily distinguish the two greens.

Tableau 2023.2 added a Path-shelf Line Pattern for exactly this: per-series solid vs. dashed rendering on one chart, no workaround required.

76. Build the Line Pattern

Worked example

Before the formula: this calc doesn't compute anything numeric — it's just a label-switch. Read it as ‘if this row's series is Projected, call it Dashed; otherwise call it Solid,’ which the Path shelf then turns into an actual stroke style.

Create a calculated field Line Pattern:

IF [Milestone Type] = "Projected" THEN "Dashed" ELSE "Solid" END

On screen right now: Planned and Actual render as solid strokes; Projected renders as a dashed stroke — the same visual vocabulary as a blueprint's dashed “proposed” lines versus its solid “built” ones.

77. Limitation: Line Pattern needs Tableau 2023.2+

Concept

Before moving on, one honest pause: the step you just did doesn't exist on every Tableau install. Worth knowing before you promise it to a student or colleague.

Limitation callout: the Path-shelf Line Pattern feature doesn't exist before Tableau 2023.2. On an older install, the Path shelf simply won't offer dashed/solid styling — there's no error, the option is just absent.

Check the student's Tableau version before promising this step. If it's older, the fallback below still gets a visually distinct Projected line — just with more setup.

78. Teach it back: Limitation: Line Pattern needs Tableau 2023.2+

Explain it

79. Fallback: split-at-TODAY() calcs

Worked example

Pre-2023.2, build two calculated fields that split the SAME measure at the boundary, so they visually overlap and appear to connect:

// % Complete (Historical)
IF [Milestone Date] <= TODAY() THEN [% Complete (running)] END

// % Complete (Forecast)
IF [Milestone Date] >= TODAY() THEN [% Complete (running)] END

On screen right now (pre-2023.2): two measures instead of one, each formatted with its own line style, meeting at a single shared point directly on the TODAY() line — from a normal viewing distance the join is invisible and the chart reads as one continuous, correctly-styled line.

80. Inspect it line by line: Fallback: split-at-TODAY() calcs

Error analysis

81. Part 6 — Forecast Limitation & Formatting

Section

Segment 9 + limitations

82. Roadmap for Part 6

Concept

In this part: see exactly why Tableau's built-in Forecast feature can't touch a table-calc measure, then spend about 5 minutes on formatting — percentage axis, date axis, tooltips, legend order — the small polish that turns a working chart into a readable one.

83. Limitation: Forecast is greyed out on table calcs

Concept

Here's a second honest limitation, worth knowing before a student asks you to “just have Tableau predict the rest.”

Limitation callout: Tableau's built-in Forecast (exponential smoothing) cannot run on a table-calculation measure. % Complete (running) is a table calc, so Forecast is disabled for it — greyed out in the Analytics pane, no explanation given.

This is exactly why the session uses the export's OWN Planned Completion (Projected) column instead of asking Tableau to forecast anything. It's arguably better data anyway: it's the team's own revised estimate, not a generic statistical extrapolation.

84. What has to be given first: See the limitation, then use the real fix

Missing information

85. See the limitation, then use the real fix

Worked example

If a real statistical forecast is ever needed, it has to be computed outside Tableau (Python, R) and imported as a column — Tableau's Forecast feature is a presentation tool here, not a data-science one.

On screen right now: the Analytics pane's Forecast option sits greyed out with no tooltip explaining why — nothing in the UI tells you it's because the measure is a table calc, which is exactly why this is worth demonstrating live rather than just describing.

86. Draw the shape of it: See the limitation, then use the real fix

Blank canvas

87. Formatting is clarity, not decoration

Concept

The chart is functionally complete. What's left is making sure nobody has to do mental math or guess a date format just to read it.

A misformatted axis actively confuses a reader: an Excel serial number instead of a date, or a raw 0.41 instead of 41%, forces them to do translation work the chart should have done for them.

Four formatting moves finish the chart: percentage axis, date axis title, tooltip contents, and legend order.

88. By analogy: Formatting is clarity, not decoration

Analogy

89. What has to happen first: Finish the formatting

Ranking

90. Finish the formatting

Worked example

On screen right now: the % axis reads in clean percentages (like 41%, not 0.41), the date axis reads as calendar dates (not a five-digit Excel serial number), and hovering any point pops up a tooltip naming the series, date, percent, and feature count together.

91. Work backwards from the answer: Finish the formatting

Reverse engineer

92. Part 7 — Validate & Wrap Up

Section

Segment 10

93. Roadmap for Part 7

Concept

In this part: spot-check the finished chart's numbers against the audit from Part 2, walk the eight-step recipe that generalizes to any burndown, and answer five check questions before the recap. About 5 minutes for the validation pass itself, plus the pattern and checks.

94. Validation is the last hygiene step, not an afterthought

Concept

One last discipline before you call this done: check the finished chart's numbers the same skeptical way you checked the raw data back in Part 2.

A chart that LOOKS reasonable isn't the same as a chart that IS correct. Before calling the build done, spot-check every series against numbers you already know from Parts 2 and 4.

This is the same audit mindset from Part 2, applied one more time — to the finished chart instead of the raw data.

95. Break it if you can: Validation is the last hygiene step, not an…

Counterexample

96. Guess the shape of the answer: The full spot-check

Estimation

97. The full spot-check

Worked example

On screen right now: hover the rightmost point of each line — Planned should read 100% on the cleaned file (66% on raw), Actual should read 41% on both files, and Projected should read 25% on both files. Any other number means a step upstream needs revisiting.

98. Fill in: Cleaned file for The full spot-check

Comparison

99. Without one step: The end-to-end recipe

Constraint

100. The end-to-end recipe

Pattern

Every multi-series burndown you build this way follows the same eight moves. The topic changes; the shape doesn't:

1. Connect & relate the tables in the logical layer — never a physical join.
2. Validate: a count-by-epic sheet, checked on BOTH the raw and a cleaned copy of the file.
3. Audit the raw data for column shifts, typo dates, and orphan foreign keys before pivoting.
4. Pivot the wide date columns into one Milestone Type / Milestone Date pair; keep nulls, exclude per-viz.
5. Count distinct keys (COUNTD), never raw rows, once the pivot has triplicated them.
6. Calculate running % with a FIXED-LOD denominator over ALL distinct features — never a series-own total.
7. Style with meaningful color + a TODAY() line + a dashed Projected series (or its pre-2023.2 fallback).
8. Validate again: spot-check the finished chart's numbers against the audit from step 2.

The takeaway: none of these eight moves are Tableau trivia — they're the same eight questions (“how do these tables relate,” “is the data actually what I think,” “can one axis hold this,” “what's my real denominator,” “does the encoding tell the truth”) you'd ask of any burndown, in any tool, built from any messy export.

101. Where does it stop working: The end-to-end recipe

Edge cases

102. Rule out three: Check yourself: relationship vs. join

Elimination

103. Check yourself: relationship vs. join

Check

Recall what happens when two tables share the SAME physical layer instead of a relationship.

104. Answer it before you see the options: Check yourself: the denominator

Prediction

105. Check yourself: the denominator

Check

Think through what each denominator actually measures before you answer.

106. How sure are you: Check yourself: reading the raw vs. cleaned…

Commit first

107. Check yourself: reading the raw vs. cleaned counts

Check

Recall Part 2's numbers before answering.

108. Answer it before you see the options: Check yourself: choosing the denominator

Prediction

109. Check yourself: choosing the denominator

Check

This is the trap from Part 4, restated as a choice.

110. Rule out three: Check yourself: the version limitation

Elimination

111. Check yourself: the version limitation

Check

Consider what actually changes when the Tableau version is older.

112. Connect it up: Jira Burndown in Tableau: Planned, Actual & Projected on One Chart

Connect it up

113. Recap — one chart, three honest series

Recap

You can now build — and defend — a one-chart Planned/Actual/Projected burndown from a real, messy Jira export:

Two Tableau limits worth remembering: Forecast doesn't run on table calcs, and per-series line styling needs 2023.2+ (or the split-at-TODAY() fallback). Bring your own export next time — the audit steps here (column shift, typo dates, orphan keys) generalize to almost any Jira data you'll pull.

Plain words, one more time: build the relationship, audit before you trust a count, reshape wide into long, count what's real, calculate against one honest denominator, and make the encoding say what's true.