I am wondering what the best way to implement decomposition is.

For instance let's say we have a feature or an epic that has been in the product backlog for a while, or in the roadmap for that matter. Now it is time to put it into a sprint and hence decomposition becomes necessary. Now, regardless of the tools that is being used (low-tech vs high-tech), how do you guys keep track of the decomposition process? Do you do it at all?

For example, let's say I have a feature in the backlog that reads:

ID: 123 | As a user I want to be able to login

this will be broken down into the following user stories:

ID: 2001 | As a user I want to be informed when I input wrong credentials

ID: 2002 | As a user I want to access my dashboard when login is successful

ID: 2003 | As a user I want to be able to retrieve my lost credentials

And so on and so forth.

Is it advisable to keep the original feature (big) in the backlog and link it from the sub features (user stories) with an ID or something or can the original feature be simply chucked?

4 Answers 4


I like to think of epics as placeholders that exist temporarily until you are ready to break them down in to user stories.

The Scrum team works on user stories, so this is by far the most significant backlog artefact.

Once the epic has been broken down I see little value in tracking it or even linking it to the user stories. Its job is done.

I have worked in organisations that value tracking epics but it has usually resulted in confusion and some bad working practices.

For example, these organisations may:

  • Insist that all the stories associated with an epic are completed even if the lowest priority stories are less important than other backlog items.
  • Insist that only completed epics get shipped in releases.
  • Track progress in epics, even though it is stories that are being delivered.
  • I agree, although I am a novice ;) I still have a doubt though. In the example I provided, it is clear that the single user stories cannot be deliverable independently, although they are somehow independent stories. Somehow I would feel obliged to make them belong to the same set of requirements in order to be in the position to understand when they become deployable. What do you think about that?
    – nourdine
    Apr 26, 2019 at 12:52
  • Or at the very least use the superset information as a reminder of the fact that those stories MUST be deployed together.
    – nourdine
    Apr 26, 2019 at 12:55
  • 1
    @nourdine: It is perfectly possible that an organization decides to deploy the system before the "lost credentials" story is implemented. They just have to accept a higher load on the helpdesk to support the users that lost their password. Apr 26, 2019 at 13:37
  • One technique that teams used is called 'feature toggles'. The team releases features but does not necessarily make them visible in the application. Only when they have the set of features they want in a release ready do they change the feature toggle to make them all visible to the end users. Apr 28, 2019 at 8:26

The answer is: it depends. The answer will be different for different epics and development organizations.

If there is a stakeholder interested in knowing the status of the epic as a whole (rather than the status of the individual component stories) and if it is not too much effort in keeping that status up-to-date, then it can have a value to keep the epic.

If nobody is interested in the epic as such or if updating it takes an inordinate amount of effort, then you might as well discard it and track only the status of the stories.



You're missing a couple of key concepts:

  1. The ephemeral nature of most artifacts in Scrum, as agile frameworks value "working software over comprehensive documentation."
  2. 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:

  1. What has been accomplished or discovered this Sprint.
  2. Whether the product is good enough to ship as-is.
  3. Whether the product's feature set is good enough (or bad enough) to call a halt to further development.
  4. What refinements should be made in future.
  5. 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.


I would say that there is no universal method. There are different approaches that you can take the idea from.

enter image description here

  • I guess you have a couple of typos in your answer.
    – nourdine
    Apr 26, 2019 at 9:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.