-
Suggestion
-
Resolution: Fixed
-
1
-
Original summary: GreenHopper misuses the concepts of "epics" and "themes"
–
An epic is a placeholder for a collection of user stories that will eventually be defined (this has to happen before they're added to a sprint). Epics can be prioritized in the Product Backlog, along with all the other Product Backlog Items.
A theme is a coherent set of user stories – Often the resulting user stories from an epic. You can't prioritize a theme per se, because its Product Backlog Items may not necessarily be in a consecutive order.
GreenHopper is mixing the two concepts, leading to the following issues:
- You can't prioritize an epic (the issue type) in the Product Backlog. They don't even show up in the Product Backlog.
- The "epic" functionality is in some aspects confusing and cumbersome, because it mainly deals with themes, while also assuming that epic = theme. One consequence is having a redundant "Epic Status" field that users must somehow keep in sync with the "Status" field.
- You get a separate pseudo backlog for "epics", which allows you to prioritize them. This doesn't mean anything in Scrum.
Older versions of JIRA/GreenHopper used to get these two things right, albeit with an interface that wasn't as helpful as the new Rapid Boards: Themes were a type of label and epics could be prioritized.
- relates to
-
- Closed
-
- Future Consideration
- mentioned in
-
![[Extranet] Page](/images/icons/generic_link_16.png "[Extranet] Page")
Page
Failed to load
[JSWCLOUD-8851] Ability to view and prioritise epics in the backlog
Clare Stankwitz
added a comment - +1, in agreement with both the issue summary and many of the comments. The current setup is also confusing for team members new(er) to Scrum.
Clare Stankwitz
added a comment - +1, in agreement with both the issue summary and many of the comments. The current setup is also confusing for team members new(er) to Scrum. 
Matt Elwin
added a comment - + 1 I think a fundamental concept of Scrum is that you don't break down Epics into smaller Stories until the Epic gets prioritised close to the top of your product backlog i.e. don't break down requirements into detail too far ahead of time. However you still want to be able to add/see and prioritise those Epics in the backlog continuously. That's what a backlog is!
Matt Elwin
added a comment - + 1 I think a fundamental concept of Scrum is that you don't break down Epics into smaller Stories until the Epic gets prioritised close to the top of your product backlog i.e. don't break down requirements into detail too far ahead of time. However you still want to be able to add/see and prioritise those Epics in the backlog continuously. That's what a backlog is! 
Nishant Mehta
added a comment - +1 It would be great to see and prioritize epics in the Backlog view/Plan mode along with the other issues.
Nishant Mehta
added a comment - +1 It would be great to see and prioritize epics in the Backlog view/Plan mode along with the other issues. 
Jennifer Medlin
added a comment - +1 Agree with the others 
Jens Walter
added a comment - +1 The current way of dealing with epics is not helpful +1 Would love to see this. Otherwise, epics are just sort of 'hidden' away when being used as somewhat of a 'parent' ticket.
Michael Daitzman
added a comment - +1 - not having this blew up my planned workflow for themes to organize epics. I had not tried to do this since using greenhopper back in the day -https://xkcd.com/1770/ sort of sums it up 
Michael Daitzman
added a comment - +1 - not having this blew up my planned workflow for themes to organize epics. I had not tried to do this since using greenhopper back in the day - https://xkcd.com/1770/ sort of sums it up 
Lee McDole
added a comment - +1 from me. My ideal workflow would be to create high level Epics in the backlog, then as the project progresses and we dig into those Epics, we flesh them out with user stories. But it's critical that they be visible in the backlog when prioritizing.
Lee McDole
added a comment - +1 from me. My ideal workflow would be to create high level Epics in the backlog, then as the project progresses and we dig into those Epics, we flesh them out with user stories. But it's critical that they be visible in the backlog when prioritizing. 
+1, totally agree that this is needed so that Epics can be sized and prioritized on the backlog before they have been broken down into stories. Once an Epic has any stories in it, it should disappear from the backlog.