Topic on Talk:Team Practices Group/Best Practices Handbook/Archive 2

Kevin: 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.

Joel: A lot of the confusion around shaving vs exploding is my contribution, from thinking about shaving and exploding in a hierarchical backlog. That is, if you are maintaining a list of Epics—as tracking tasks, as a way to roll up Tasks into a manageable shorter list, or for some other reason—then any shaving or exploding is going to have to work around double-counting, since the scope of work is now represented in both the Epic and the Stories. However, in a heterogeneous backlog in which Stories and Epics mix at the same level, then the Epic shrinks when shaved and disappears when exploded, so there is no double-counting.

However, there is also a use case to retain Epics so that the URLs pointing to them remain valid references for many years, which conflicts with the notion of eliminating Epics after exploding or fully shaving.

Personally I would rather keep the epics around as long as they are still valid. That is, as long as they can't be considered "resolved". There is a question as to whether they can be resolved when 51% or 80% or 99% or 100% of their original functionality has been completed. But whatever threshold is picked (and that can be on a per-epic basis), their description and subtasks should accurately reflect what the epic is about.

For example, at 80%, the PO might say the epic is "done enough". At that point, the remaining 20% of the work should be detached, either as a new epic, or as a set of independent tasks. Then the original epic should have no blocking tasks, and no unshaved/unexploded work remaining, and thus can be resolved.