The epic was planned for 3 sprints but it took 5. In the retrospective, someone asks three simple questions: When did the scope grow? Who moved the due date? Which stories changed hands mid-sprint?
Jira recorded every one of those changes. Getting them back out, across a whole epic, is the hard part.
This article is for Scrum Masters, project managers, and engineering leads who need answers about an entire epic, not a single ticket.
Jira Keeps the History, One Issue (Work Item) at a Time
Each work item has a History tab in its Activity section. It lists field changes for that item only. There is no export and no view across items. An epic with 15 child work items means 16 tabs to open and copy by hand.
JQL historical operators such as WAS and CHANGED help you find work items that matched a past condition. But the results show current values. You don't see the old value, the new value, who made the change, or when. These operators also support only a short list of system fields, so custom fields like Story Points stay out of reach. That leads retrospectives to run on memory, and audits run on screenshots.
3 Questions About an Epic, and Where the Answers Are
Historian - Issue History for Jira reads the Jira changelog and turns it into a single report for many work items. Here is how it answers each question.
What Changed in the Epic and Its Children During the Sprint
Open Apps → Historian - Issue History for Jira → History Explorer and scope the report with JQL (which brings the epic and its child work items):
key = SSP-90 OR parent = SSP-90
This pulls the epic itself plus every work item currently under it, so one report covers the whole epic.
Who Changed a Field, and When
Switch to Field-Based View. Here, every field change gets its own row, even when several fields changed in one transition.
Filters on different columns combine with AND logic, so you can stack them to get a precise answer.
What the Epic Looked Like at Kickoff
To see it, open Historic Query, enter the same JQL, and set Show me the results as of to your kickoff date. The report shows each work item and its field values as they were on that date.
Work items created after that date are still listed, with empty fields and a note that they did not exist yet. (See MTP1-43 to 40 in the image above). Scope added later stands out right away.
Scope creep isn't only new work, though. Display the Parent field and an item that was moved into the epic later shows a different parent on your selected date, with a change badge on its Parent cell — click it to open the timeline and see exactly when it moved and who moved it (see MTP1-33's Parent history above.)
Historic Query is read-only. It shows the past without changing current data.
Exporting Epic History in Jira
Export the report to XLSX or CSV. The file matches what you see on screen: the same work items, fields, filters, and grouping. XLSX works best in spreadsheet tools; CSV suits imports into other tools.
Here is who gets the most out of an epic-level history:
Scrum Masters: Run retrospectives on a dated record of scope and estimate changes, not on recollection.
Project Managers: Explain a slipped delivery date to stakeholders with a clear trail of what changed and when.
Engineering Leads: Spot process patterns, like work items bouncing between statuses or repeated reassignments, and fix the workflow instead of guessing.
Jira Admins: Give teams history reporting while keeping export rights limited to the right groups.
The changelog already holds the full story of every epic. A report across the epic and its child work items makes that story readable in minutes instead of hours.
You can find Historian on the Atlassian Marketplace.
