[teampractices] heterogeneous and hierarchical backlogs, shaving and exploding epics

Mon Jun 22 15:47:23 UTC 2015

Good stuff David. One note is that there are likely to be small stories
mixed into the bottom layers of the iceberg. It won't all be epics and
sagas down there. (At least, it hasn't been for projects I have on).

Joel: I'm struggling to understand how "hierarchical" would work in the
real world. Since you, JamesF, and I all like the heterogeneous model, is
it worth even keeping hierarchical around? If so, can you explain it more
fully? I would hate for a project to artificially combine stories into an
epic, merely to obey a rule that all work must be contained within an epic.

Kevin Smith
Agile Coach
Wikimedia Foundation

*Imagine a world in which every single human being can freely share in the
sum of all knowledge. That's our commitment. Help us make it a reality.*

On Fri, Jun 19, 2015 at 12:27 PM, David Strine <dstrine at wikimedia.org>
wrote:

> I haven't heard these terms before but I understand the need for #2.
>
> I'm a huge fan of *Agile Estimation and Planning
> <http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415> *by
> Mike Cohn and I'll reference it for my response.
>
> RE #1
> The way I understand backlogs in Scrum, epics and stories for an "iceberg"
> in the same backlog.
> [image: Inline image 1]
> If you have a story large enough to be called an epic, it inherently won't
> fit into a sprint. It needs to be broken down. Also, Scrum and agile still
> require a team to do some planning to achieve the iceberg shape.
>
> Over several sprints, the team works down through the backlog. Epics start
> getting closer to the top. One of my instructors, Ken Rubin has a rule for
> this. If an epic appears within 3 or 4 sprints of the top of the backlog,
> the team must consider breaking it down or re-prioritize it lower.
>
> IMO problems like #1 crop up when you use a virtual backlog and scrum
> board. Anne and I are trying some tests on the FR-tech backlog to produce
> the iceberg:
> https://phabricator.wikimedia.org/tag/fundraising-backlog/
> We have the first 3 sprints roughed out with goals. Then columns for
> quarterly goals beyond that. The Epics can't enter the first 3 sprints
> unless they are broken down. This exposed some features that needed to be
> addressed immediately.
>
> RE #2
> *Agile Estimation and Planning* uses the term "split". I like using the
> term "breakdown". I've also heard "decompose". I think people would
> understand your terms just fine.
>
>
> On the meta idea of SP costing:
> The general assumption is that the new smaller stories are re-costed after
> the epic is split or changed. In your exploding example, there really isn't
> an epic left. There should just be smaller stores and they should all have
> their own costs. Again I think this is a tool problem. The epic just
> happens to exist after the new tasks are created. In a real world paper
> board, the epic would be crumpled up in a trashcan while the smaller
> stories remain in the backlog.
>
>
>
>
>
>
> On Fri, Jun 19, 2015 at 11:32 AM, Joel Aufrecht <jaufrecht at wikimedia.org>
> wrote:
>
>> Hi,
>>
>> Here are four very idiosyncratic terms that I came up with while
>> discussing Epics and Backlogs with Kevin.  I found them very helpful but
>> I'm sure there are existing, more common names for these out there.  A
>> quick googling didn't reveal anything exactly relevant and before I
>> invested more time in looking for standard terminology I thought I'd ask
>> here.
>>
>> 1) Heterogeneous vs hierarchical product backlogs
>>
>> A hierarchical product backlog is one with a stack-ranked list of
>> stories and also a stack-ranked list of Epics (and maybe a stack-ranked
>> list of Sagas or Themes or Features as well).  In this backlog, each Story
>> is part of an Epic.
>>
>> A heterogeneous product backlog is one stack-ranked list comprising a mix
>> of Stories and Epics, each completely independent.
>>
>> A homogeneous product backlog is one stack-ranked list of Stories, which
>> is what vanilla Scrum starts with, but in practice this is rarely adequate
>> for a project of any size.  It is, however, best practice for a _sprint_
>> backlog.
>>
>> 2) Shaving vs Exploding Epics
>> To shave an epic is to identify a Story within the scope of work of an
>> Epic, create that as an independent Story, and then rewrite the Epic to
>> exclude that scope.  To explode an Epic is to move the entire scope of work
>> into a series of Stories and then close the Epic.  Both of these methods
>> are appropriate in a heterogeneous product backlog, where they prevent
>> double-counting scope.  In a hierarchical backlog, the scope of work of the
>> original Epic must be preserved, so the equivalent to shave is "partial
>> work breakdown to the story level" and to explode, "full work breakdown to
>> the story level".
>>
>> Thoughts?  What terms have you seen for these concepts?
>>
>>
>> *Joel Aufrecht*
>> Team Practices Group
>> Wikimedia Foundation
>>
>> _______________________________________________
>> teampractices mailing list
>> teampractices at lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/teampractices
>>
>>
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20150622/b38a31e5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 103352 bytes
Desc: not available
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20150622/b38a31e5/attachment-0001.png>