Skip to main content

How one should deal with Epics?

Last post 11:48 pm May 27, 2020 by Ian Mitchell
2 replies
08:15 pm May 27, 2020

Have a few practical questions:

Example 1: At first we have an epic for a product feature. Then, later on, it's more refined into the individual user stories. Some of those user stories are moved to the sprint. What happens to the Epic? Is it closed? Deleted? Left in the backlog (what about its SP?). 

Example 2: We use a development management tool that has scrum add-in. The concept there is that first of all we have a Feature (equivalent for Epic). It becomes a parent task for other work, like user stories. User stories definitely go to the Product Backlog, but what about the Feature? If I have both Epic, and User stories - they kind off duplicate each other. 

Anyone has similar "challenges" when using some industry scrum tools?

 

Thank you!

 


10:52 pm May 27, 2020

Most tools are going to present challenges. Often, they are either set up for a particular way of working. In other cases, tools are highly configurable and can be customized in ways that can end up with extra difficulty in using and maintaining.

As a reference point, I use Jira.

I've never used an Epic the way you describe in your first example. Although what you describe is a common definition of Epic, it's not what Jira considers an Epic to be. In Jira, an epic is a container for other tasks. As such, it is created when there's a discrete deliverable, work is grouped under it for planning purposes and high-level sizing, and then the Epic is opened when work starts and is closed when the last item is closed. The use of automation tools in Jira makes it so that there's very little manual transition of Epics from one state to the next.

Jira's Epics are used like the Feature that you use in your second example. However, there aren't necessarily duplicates as there's not a 1:1 mapping between Epics (or, in your case, Features) and other things (like User Stories). A special Epic board gives management better insight into the status of work. They can see the Epics, which ones have had work done, and can then click on them to get additional details if desired.

My advice is to find the balance between your workflow and what the tool supports. The best-case scenario is that you find tools that fully support your workflow and all of your other needs. Usually, we don't have the best-case, though. Often, we need to make some compromises. That involves understanding your tool and how it can fit into your process, making adjustments to your process where necessary.


11:48 pm May 27, 2020

What happens to the Epic? Is it closed? Deleted?

Does that "epic" user story have acceptance criteria, and if so, have they been met?

User stories definitely go to the Product Backlog, but what about the Feature?

Do you think a "feature" would help as an organizing principle in the Product Backlog?


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.