TL;DR
You're missing a couple of key concepts:
- The ephemeral nature of most artifacts in Scrum, as agile frameworks value "working software over comprehensive documentation."
- The concept of themes, which are are related (as opposed to large) user stories.
Tracking epics or themes as first-class data elements assumes that they can be fully-defined up front, and that they have intrinsic value. They can't, and they don't. Epics, themes, and even most "features" are all ephemeral byproducts of agile development, and are only useful in communicating about current or near-term work. Because agile development embraces change and assumes that a product will evolve over time, tracking historical work (or worse, legacy planning artifacts like epics) is generally done for political reasons rather than framework-related ones.
You should actively question the value in tracking in-progress or completed user stories. If you find you must track them, then the team should collaborate with the stakeholders to find the most effective way to do that in your unique context.
Question the Assumptions
In agile frameworks like Scrum, a working product is more important than comprehensive documentation. Living documentation that describes the current feature set is valuable, but tracking historical requirements and deltas from past iterations is a holdover from waterfall-like methodologies. While documentation like legacy backlog data is not entirely irrelevant, it shouldn't become an end unto itself. So, it's worth asking whether this data is useful in helping to produce a working product, or in inspecting the project's processes. If not, don't do it.
In many cases, the reason that teams want to do this in the first place is because stakeholders are really asking:
How much progress are we making towards Feature X or Release Target Y?
If that's the case for your stakeholders, this usually indicates one or more of the following Scrum implementation problems:
Insufficient framework training for stakeholders.
The Product Owner and Scrum Master should work with stakeholders to explain the process more effectively. The team should also highlight framework processes, artifacts, and events that can be used by stakeholders to evaluate the current status of the project, and the Scrum Team's progress towards the project's goals.
Lack of transparency or visibility.
The Scrum Team should inspect-and-adapt its artifacts and processes to determine why stakeholders don't feel they have full transparency, or lack visibility into the team's progress. Information radiators like the Product Backlog, Sprint Backlog, or Sprint Review might need to be improved. On the other hand, it may simply be the result of insufficient collaboration or communication between the Scrum Team members and stakeholders. This should be addressed as a core process issue, and may even belong on the Product Backlog to ensure it's treated as a priority with allocated resources.
Incomplete increments or missing Sprint Goals.
In Scrum, each Sprint should have a unified Sprint Goal that defines the potentially-shippable increment to be delivered. A Sprint Goal is required by the framework. If you lack a coherent Sprint Goal, not only are you not following Scrum properly, but you're forcing stakeholders and the Scrum Team to thrash around looking for proxy metrics like epic-tracing rather than focusing on the delivery of a coherent increment of work that is clearly done or not-done.
A non-incremental or non-iterative approach to development.
Product development, especially in software, is never 100% complete. Trying to pre-plan future work is an agile anti-pattern, as Scrum should maximize the amount of work not done by focusing on delivering a coherent increment within a single Sprint. Stakeholders should expect to refine features over time. For example, one Sprint might deliver "basic login capability," while other Sprints deliver "enhanced user feedback for logins" and "account recovery" features.
In short, your question seems to assume that all work for a given feature can be known ahead of time, and work should be tracked against this "100% complete" status, including specific implementation details. This is entirely contrary to both agile theory and effective Scrum practice, so don't do that.
Track Against "Good Enough"
Each Sprint, the Scrum Team should be providing a coherent increment of work to stakeholders for review. Furthermore, after the first few Sprints, the product should always be in a potentially-releasable state after each Sprint. So, rather than tracking work against a big, upfront design, the Scrum Team and the stakeholders should be asking:
Is the current state of the product good enough to ship?
Part of this conversation may revolve around what's changed since the last time the product was reviewed. That's where the current Sprint Goal, completed features, and epics/themes addressed within the Sprint should be discussed. The goal isn't to evaluate how much remains to be done, though. The objective is to review:
- What has been accomplished or discovered this Sprint.
- Whether the product is good enough to ship as-is.
- Whether the product's feature set is good enough (or bad enough) to call a halt to further development.
- What refinements should be made in future.
- What changes or additions might need to be addressed in near-term Sprints.
Epics, themes, and stories are useful ways to organize work on Product and Sprint Backlogs, but they are not the measure of progress in Scrum. If the Scrum Team and the stakeholders can't evaluate whether the increment is a successful step towards the project's vision or goal without falling back on non-agile metrics like "percent done," then the cognitive framework the organization is applying to the project lacks the necessary empiricism for successful agile adoption. This should be addressed as a top priority.
