Epics as work items
I think there's a problem with the fact that in RTC and the scrum template, epics are represented as work items.
Representing epics as work items certainly allows you to very nicely show the hierarchy of epic parents with their decompose child stories.
BUT... the problem is that when you want the classic, flat, completely prioritized release backlog that scrum encourages, in RTC you see epics and stories in the same list and you are allowed to prioritize them against each other. But I think it is meaningless in scrum to prioritize a story against an epic. To handle this today, I move all my epics to the bottom of the flat prioritized backlog, so they are out of the way of the stories which represent the real work. I can rank my stories against other stories, and my epics against epics, and I just ignore the fact that they are in the same list.
If I were a complete scrum purist, I would question whether epics should even be work items at all, since you never actual DO an epic. An epic is something too big to fit into an iteration and must be broken down into stories that do fit. So you could argue that you should never be able to add an epic to an iteration plan. They are really groups of story work items, not work in themselves.
More pragmatically, I would be happy if I could find a way to exclude epics from a flat iteration plan, so that I get RTC to show me the completely prioritized backlog of stories (no epics). Is this possible? Should I open an enhancement request?
Thanks!
Mark
Representing epics as work items certainly allows you to very nicely show the hierarchy of epic parents with their decompose child stories.
BUT... the problem is that when you want the classic, flat, completely prioritized release backlog that scrum encourages, in RTC you see epics and stories in the same list and you are allowed to prioritize them against each other. But I think it is meaningless in scrum to prioritize a story against an epic. To handle this today, I move all my epics to the bottom of the flat prioritized backlog, so they are out of the way of the stories which represent the real work. I can rank my stories against other stories, and my epics against epics, and I just ignore the fact that they are in the same list.
If I were a complete scrum purist, I would question whether epics should even be work items at all, since you never actual DO an epic. An epic is something too big to fit into an iteration and must be broken down into stories that do fit. So you could argue that you should never be able to add an epic to an iteration plan. They are really groups of story work items, not work in themselves.
More pragmatically, I would be happy if I could find a way to exclude epics from a flat iteration plan, so that I get RTC to show me the completely prioritized backlog of stories (no epics). Is this possible? Should I open an enhancement request?
Thanks!
Mark
One answer
I think there's a problem with the fact that in RTC and the scrum template, epics are represented as work items.
Representing epics as work items certainly allows you to very nicely show the hierarchy of epic parents with their decompose child stories.
BUT... the problem is that when you want the classic, flat, completely prioritized release backlog that scrum encourages, in RTC you see epics and stories in the same list and you are allowed to prioritize them against each other. But I think it is meaningless in scrum to prioritize a story against an epic. To handle this today, I move all my epics to the bottom of the flat prioritized backlog, so they are out of the way of the stories which represent the real work. I can rank my stories against other stories, and my epics against epics, and I just ignore the fact that they are in the same list.
If I were a complete scrum purist, I would question whether epics should even be work items at all, since you never actual DO an epic. An epic is something too big to fit into an iteration and must be broken down into stories that do fit. So you could argue that you should never be able to add an epic to an iteration plan. They are really groups of story work items, not work in themselves.
More pragmatically, I would be happy if I could find a way to exclude epics from a flat iteration plan, so that I get RTC to show me the completely prioritized backlog of stories (no epics). Is this possible? Should I open an enhancement request?
Thanks!
Mark
Sorry, but there is currently no way filter Epic from a plan. The only filter that takes the work item type is the 'Exclude Execution Items' filter. However, an Epic is clearly not an execution item.
I understand your arguments and have to agree. But only in parts. An Epic is certainly not a work item if you literally read *work* item. Epics are just abstract notions of something. However, we understand work item as an item with a bunch of attributes. Still, it is arguable what attributes an Epic should have. And I think the most arguable is the 'Planned For' attribute. If ever, an Epic might be planned for a whole release, certainly not for an iteration.
I've created https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/99056
where I would like to continue the discussion.
Back to a pragmatic solution. As there is no filter, I recommend to either set the Planned For attribute of Epics to unassigned, or to plan them for a release, not an iteration (e.g. 4.4 instead of 4.4s1).
With 2.0.0.2 we are going to introduce a back iteration. That is a marker for an iteration which we read as "The product backlog is all the work items planned for that iteration". When Epics don't get planned for the backlog iteration, you can rank your stories (which are planned for the backlog iteration) without any 'epic-noise'.
--
Cheers, Johannes
Agile Planning Team