How To Represent Epics in the backlog?

John Gordon October 14, 2014

Problem

How can I have a large epic that I know I need to work on, but don't want to break down into stories just yet, be represented in the backlog?

Background

We want to follow the practice of "iceberging" work in the backlog. Per the image, large items are put in the backlog. They represent a larger body of work–an epic. It doesn't make sense to break them down into stories immediately, it's better to wait until the team is coming close to being able to work on it. Screen Shot 2014-10-15 at 9.26.13 AM.png

Jira's epic don't actually represent what I think an epic is: a large amount of work that may not be able to be completed within one sprint. Instead, I think that Jira's epic's are more similar to a "Theme":

From Mike Cohn's article:

" “theme” is a collection of user stories. We could put a rubber band around that group of stories I wrote about monthly reporting and we'd call that a “theme.” Sometimes it's helpful to think about a group of stories so we have a term for that."

Because Jira's Epics are really themes – a rubber band wrapped around related stories-- Epics can't be in the backlog, and can't be assigned a story point value. This causes real problems when trying to plan a release.

To plan a release with a specified number of points–say you want to achieve 200 points in the next release–requires every backlog item dragged into the release has a point value assigned to it. The problem here is that I want to drag in my epics that have a rough story point value assigned to them, but I don't want to break down the epic before I add it to the release (a release could last 3 months).

Workarounds

The main workaround we use is to create a story in the backlog to represent the epic. We assign a large story point value to the story, then drag it into the release when we perform our release planning. This really is a kludge, in my opinion, and makes it harder to manage the backlog when we perform grooming sessions during the release because we have to manually reduce the size of the large epic-story when we identify a story that is part of the epic and point it (e.g. epic/story = 200 pts. a Story is broken out of the epic with 8pts. We then reduce the epic/story to 192 points manually).

It really becomes difficult when the whole epic/story isn't fleshed out because we don't have enough time in one grooming session; we have some stories, then one big story partially fleshed out. To keep it all organized, we then create a JIRA Epic (really a theme IMHO), and have to associate all the stories we fleshed out, plus the large placeholder story with the JIRA Epic. This can cause confusion when looking at the planning.

 

Thanks For Reading!

So, what does your team do to address this issue – trying to give an Epic a presence on the backlog?

1 answer

0 votes
Julio Ramirez October 14, 2014

Hi John, I think you made a good clarification of the epic/theme topic. I agree with your view.

Here's what we do:

We use story items for epics. Epics match our concept of big-fat-story we can't fairly estimate. Then we estimate them in sizes with the only purpose of planning/forecasting.

At stripping out stories from an epic, we don't discount any points from its total. Epic sizes don't translate into story points. And I'd discourage the team to do so; epics are just coarse-estimated and the operation wouldn't make sense to me. I'd chop it all into stories (and smaller epics). Estimate stories and, eventually, if the result yields also an epic of e.g. half the original scope, I would re-size it down to maintain consistency. Otherwise, it would retain its original value.

 

Best

Julio

Suggest an answer

Log in or Sign up to answer