Description
Related Objects
Event Timeline
I have a few issues with the current state. Maybe we should do another 30-minute real-time collaboration to try to refine it.
For the TBD in the explode section, I would normally expect to encounter the epic during grooming, although it certainly could happen during sprint planning.
- I'm not convinced that an EPIC column is necessary (or helpful). Maybe it should be offered an option rather than a dictate? Or perhaps you can persuade me that it is the One Right Way(tm) to do it.
- Option B wasn't entirely clear to me. Was that a way of advancing the process without stalling the meeting?
- All the shaving you propose is to peel off just one story at a time. Often I find it best to peel off as many stories as easily reveal themselves. Especially during the following sprint planning meeting, the existence of one open story should not preclude shaving off more, if the epic itself is high priority.
Meta note: Should these notes be in the wiki page's Talk page instead of in this ticket?
Does that wikipage not mention the use of the Epic project at all, or am I just unsuccessful in finding it?
@Aklapper; Joel might have a different answer, but I think this document is (at least for now) tool-agnostic, so doesn't discuss anything specific to phabricator.
On shaving epics vs exploding them: Agreed, in practice, you will want to shave some epics and explode others, and circumstance should dictate which. The confusion (in my mind) came over what should happen to the Epic after it's shaved or exploded. The answer for that is different depending on whether the backlog is hierarchical or heterogeneous backlog. In a hierarchical backlog, the Epic is not changed by exploding or shaving, and the new Stories all need to be linked to the Epic, so that any backlog grooming at the Epic level is carried through to the lower level. In a heterogeneous backlog, the Epic should be removed if it's been exploded; if it's shaved, the Description of the Epic should change to remove that portion of its scope. New open question, though: if you shave an Epic, should the new Story(ies) be children of the Epic? I'm thinking no.
@JAufrecht: I think we both favor the heterogeneous approach, so I'll ignore the hierarchical for now.
I don't see a need to remove epics, as long as their estimate reflects the amount of work remaining after all of its subtasks have been done. That is, the estimate should reflect the unshaved/unexploded work. With that, I think keeping epics around as a way of showing relationships between their subtasks makes sense. Which answers the second part: Yes, I think shaving an epic should create subtasks.
I will also reiterate my general discomfort with having a lot of epics (or maybe my concern is more with sagas). Any time you are bundling several tasks into one container, that container as a whole cannot properly be prioritized. By setting an epic's priority "high", you are not saying "Everything in this epic is high priority", but rather that "At least one bit of this epic is high priority". The actual priority of each shaved subtask must be evaluated separately, and most likely after some (20%? 50%? 80%?) of an epic is complete, it's priority should be changed to low, because the parts that remain are bells and whistles.
Putting that differently, I would rather identify the high priority stories directly, rather than identifying an epic, and then splitting it to find the high priority stories. I haven't thought a lot about this topic in this context, so I reserve the right to further develop this line of thinking.
Moving discussion to https://www.mediawiki.org/wiki/Talk:Team_Practices_Group/Best_Practices_Handbook (note that this is our second Flow page, so we can experiment with multiple discussions in multiple pages).