[almighty] Portfolio backlogs vs Product backlogs?

[Vineet Reynolds Pereira]

On Thu, Nov 10, 2016 at 4:26 PM, Michael Kleinhenz <kleinhenz at redhat.com>
wrote:

> >> 1. Iterations are hierachical
> >>     -> an Interation on a program level may contain several iterations
> >> on an implementation level, also across projects.
> >>         So we could have "business iterations" that contain several
> >> iterations of other projects in the org.
> >
> > I'm unsure whether business iterations need to roll up other iterations.
> > But, lower level product backlogs do have to be rolled up to a higher
> level
> > portfolio backlog.
> > We can continue discussing this.
>
> Mmmh, but does a backlog makes sense without something like
> iterations? Without iterations, the character changes: from an actual
> "working on" to a "control of". Such a program backlog model would be
> of use for a scenario where it is solely used for controlling state
> and progress of the actual "working" projects below. But it this a
> realistic usecase? I doubt that, because:
>

I get your point, and it looks like we need a shared understanding of what
transitions are possible on portfolio backlog WIs.
There is scope for confusion in how portfolio backlog WIs undergo
transitions.

My original understanding was that product backlogs are where work is
scoped, estimated and executed, and portfolio backlogs should just reflect
this in a rolled up manner. A portfolio WI is 'done', when the rolled up
stories in product backlogs are 'done'. I didn't see the need for business
iterations in this context.

Now. that alone is not sufficient, as portfolio backlog items need to be
worked on by a program manager or product owners, to break the WI into
product WIs, and therefore portfolio WIs may have their own transitions
(New -> WIP -> Done). I'll agree this aspect would require supporting
iterations, so that portfolio backlogs can be continuously groomed just
like any other backlog.

I'll attempt to do some additional research and come up with some concrete
examples.


>
> 1. there might also be work items on the program level: "approve
> features", "strategic definitions" etc.
>
> 2. iterations on a program level might have a different business
> meaning, like "fiscal year".
>
> I think having iterations there definitely makes sense.
>
> -- Michael
>
>
> --
> Principal Software Engineer
>
> Red Hat Deutschland GmbH
> Werner-von-Siemens-Ring 14
> 85630 Grasbrunn
> Germany
>
> RED HAT | TRIED. TESTED. TRUSTED.
> Red Hat GmbH, www.de.redhat.com,
> Registered seat: Grasbrunn, Commercial register: Amtsgericht München,
> HRB 153243,
> Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
> Michael O'Neill
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20161110/18aafaa0/attachment.htm>