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

Previous discussion was archived at Talk:Team Practices Group/Best Practices Handbook/Archive 1 on 2015-06-17.

There's an issue I've been running into with the distinction between priorities and goals. Quarterly goals should be quantifiable - something you can check off if completed. Some high priorities may be ongoing maintenance or support tasks.

For example, there is a large volume of work just to keep things floating that doesn't fit into an aspirational goal in mature software systems, particularly in systems with lots of external dependencies (like, say, payment processors). In fundraising, we also face supporting campaigns that are running year-round, bringing up new issues all the time. Both of these categories of work can't be predicted and are non-negotiable highest priority. We will always opt to keep the ship afloat rather than complete a new feature request.

I'm interested in other PM and TPG thoughts on this. It's not compelling for me/my team to write a quarterly "make sure money can come in" or "be responsive to last minute changes by external vendors" goals, so ours have been focused on new work and stabilizing - aspirational objectives that we plan to complete in the remainder of the time.

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

As a data point, the Discovery PO added an Epic column to the Discovery product backlog workboard, so I'll get to see the pros and cons first-hand.

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.

Kevin: Option B wasn't entirely clear to me. Was that a way of advancing the process without stalling the meeting?