We have designed our system with the follow steps:

Backlog (epics) Ready for discovery (epics) In discovery (epics) Ready to break into stories / 3 amigos (epics->stories) Ready for development (stories) In development (stories) Ready for QA (stories) Ready for PO review (stories) Done (stories)

We designed it so that the team can take more ownership for creating the stories as we don't have an experienced PO.

We have a weekly queue replenishment meeting. We focus on the input queue i.e. at the incoming epics.

So far it seems to be working fine however I want everyone to keep on top of the stories that are coming out of the epics being broken down.

So my question is how do we ensure that epics don't spawn endless stories - since the developers are creating the stories.

I do coach the developers on the importance of having defined epics with a start and finish and not to use them as containers.

Update: Example of an Epic:

It's a BI/Data Science team, so this is a rough example of an epic: Airflow pipeline - create a json data contract between an existing application and a nightly s3 bucket and in turn it transforms the data several times and eventually the data ends up in snowflake

Second example of an epic:

Create a dashboard for a specific business department in Looker (would include Explore, LookML)

  • Could you give an example of one of your epics (obviously, you don't need to put in any sensitive info).
    – Daniel
    Commented Jun 21, 2019 at 13:28
  • 1
    Interesting problem! Perhaps instead of coming up with Epics directly, you may want to try out Story Mapping as a way of defining specific manageable “chunks” of functionality that get grouped as Features and User Stories? Of course, that would require a whole new approach and training in it. But it might force your team to think of specific things users should be able to achieve with the system - instead of a vague high-level functionality or container they must come up with and call them epics. As a reference, you should refer to Jeff Pattons book on that topic. Commented Jun 21, 2019 at 16:34
  • 1
    How are you using Epics? I've run across two different uses. The first is where the Epic is a container for Stories, and often represents the deliverable work - although each Story could be implemented and tested, the value to users tends to be realized for the set of them. The second is where an Epic represents a large body of work that is broken down into Stories - the Epic eventually "goes away" in favor of stories.
    – Thomas Owens
    Commented Jun 21, 2019 at 16:48
  • @ThomasOwens the second example. Where it 'goes away'. I believe this to be best practice and the original intention of an epic according to Mike Cohn. The first example I don't favour and I believe Jira perpetuates this style.
    – TheLearner
    Commented Jun 21, 2019 at 16:49
  • @MaheshSingh yes I definitely want to do this and thanks for kind of confirming this as an option.
    – TheLearner
    Commented Jun 21, 2019 at 16:50

1 Answer 1


If you're going to be using the User Story format, I'd start by recommending that your Epics follow the same format as a Story. Focus on what you want the user to be able to accomplish and why. You can even go as far as developing some initial acceptance criteria that may be applied to various Stories that are written and delivered later on.

But you aren't necessarily tied to the User Story format. You can also use a Use Case format, where the Epic level is a full description of the use case and the major paths through it. Then, your Story level work would start with the "happy path" through the use case and then include various alternative paths through the use case.

As far as "spawning endless stories", this may be expected. As the work is refined, people may throw out ideas. The important piece is to order the work so that way the most valuable and most important work (or dependencies for the most valuable and/or most important work) is done first. Deliver what makes sense, get some feedback, and reorder the work.

I'd also recommend having someone who isn't a developer take responsibility for writing the work items. Although developers can help, there should be someone with a vision for the product. This person can sanity check a lot of the work and see if it makes sense. Depending on the tooling you are using, there are different ways. In electronic tooling, you can log the work and apply various tags or labels to it so they are available but not necessarily visible unless included. If you're using a physical board, you may not want to record them until there's a clear user-driven need.

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.