Epics should be treated the same as other backlog items. They should appear in the same lists, and should be able to track tasks against them.
A typical use case for me is a backlog item that begins its life at a parent project, say one representing an application. This has child projects representing different components. Some changes may be needed in different components, so the main backlog item is broken down as a story. But I will still track some tasks and tests against the epic - for example, documentation might not be component-specific.
As it currently stands I would have to create a separate story for the application-level work, and I cannot prioritize the whole thing as part of my backlog.
by: Daniel S. | over a year ago | Product Planning
Comments
Yeah, epics should definitely be treated as backlog items. It's not trivial to see epics in any of the views without having to do some detective work.
We want to be able to drag and drop Epics without moving them into another epic. Basically this requires a slightly more sophisticated interface: if you drop one Epic into the center of the text of another Epic, it becomes a child. If you drop an Epic BETWEEN two Epics, it should just change the ordering.
I think Epics are under supported in general. They are really one of the cornerstones of scrum Agile and they are almost an after thought in VersionOne. Its very difficult to view Epics and userstories for a project together. That view is essential for overall product planning.
I would love Epics to show in the UI as backlog items. I haven't thought it through yet, though, to figure out all the implications of the ways they're not quite like backlog items. (Can run across iterations, etc.)
There is no reason why one level parent child relationship of Epics and child stories isn't viewable in the product backlog. If this wasn't an electronic board and one was doing this using post-its then you find there are a number of common practices, color of note to swim lanes for the epic, that one maintains a reference view of this relationship.
In a nutshell it helps Product Owners to manage the forest of trees within the larger landscape that we call product backlog.
Of course when it comes to Sprint Backlog the case is somewhat different, as this is the execution part of the sprint, and one where Epic can't be scheduled in as a whole. So it is reasonable not to have the Epics viewed into this backlog.
I would like to be able to link an epic to a Feature Group to create additional filter/sorting criteria (e.g. for specific user Groups)
Epics have been evolving and continue to do so. Some items mentioned in comments such as tests on epics and reordering without changing the parent have been added over time. In addition to those changes that have been made, we are planning on adding what we've been hearing as the most valuable aspect that is done for backlog but skipped for epics: release planning.
that would be essential for us too!
as for integration of SAFe we would need the ability to assign Epics to sprints! So rather Sprint-Planning than Release-Planning! Will you be able to realize this?
whereas the sprint containing the epic will be called 'Agile Release Train'...
We see specific SAFe support and the concept of a release train as something different than this. We are very interested in seeing how many customers are pursuing the SAFe path, so please do log your ideas for best ways in which we can support that journey.
The Winter 2014 Release contains epic release planning which allows for a mixed bag of epics and backlog in doing release planning. With that, we're going to close out this idea. Feel free to log new ones for any further steps that you would find valuable.