[almighty] Portfolio backlogs vs Product backlogs?

Vineet Reynolds Pereira vpereira at redhat.com
Thu Nov 10 10:49:50 UTC 2016


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

> I think this is possible with the current discussion version of the
> model. Key to this is I think:
>
> 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.


>
> 2. Work items to work items links are completely domain-specific as
> well as the type of the work items
>     -> we can define any relation beween work items as the context
> sees fit. So we could define "program work items"
>         in addition to "implementation work items" and a 1:n relations
> between them for example as part of the
>         "project template" (to speak in vso terms). This also applies
> to epics (and this is equally important on
>         a business level, but more or less a minor feat in our
> implementation.
>

+1, the WIT of items in a portfolio backlog is often different from the WIT
of WIs in a product backlog.
Portfolio backlogs often have initiatives, features or epics, which map to
stories or tasks in a product backlog.


>
> 3. We allow for several projects on the org level, with possible
> interpendency (aka "linkability") of entities across all
>     entities of an org.
>
> Yes, we need that kind of model and we will most likely encounter more
> requirements like this later and in the future. The challenge here is
> to create a system that can offer this stuff on a configuration level
> while not crossing the border of "generic turns into unmanageable"
> line.
>

+1. My proposal is that portfolio backlogs be activated manually so that
teams can use this feature when they become too large and need program
management not just project management.


>
> -- Michael
>
>
> On Thu, Nov 10, 2016 at 11:18 AM, Vineet Reynolds Pereira
> <vpereira at redhat.com> wrote:
> > Hi,
> >    I haven't seen a lot of discussion on this topic. When reviewing the
> > walking skeleton [1], I noticed a feature area on portfolio management.
> >    Now, portfolio backlogs are different from project backlogs in that
> > highest level initiatives that cut across multiple project teams are put
> > into a portfolio backlog. This is often done by a program manager. Work
> > items in a portfolio backlog eventually find their way to one or more
> > lower-level product backlogs. Individual project teams work only their
> > product backlogs.
> >
> >    I've seen similar features in VSTS and JIRA. Do we intend to support
> > anything like this?
> >
> > Vineet
> >
> > [1]:
> > https://docs.google.com/spreadsheets/d/19woiNb1ZDi4douxoDeQ0SMx6SMSfO
> 5b9AyeoRBAibFA/edit#gid=1230916644
> >
> > _______________________________________________
> > almighty-public mailing list
> > almighty-public at redhat.com
> > https://www.redhat.com/mailman/listinfo/almighty-public
> >
>
>
>
> --
> Michael Kleinhenz
> 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/132e247f/attachment.htm>


More information about the almighty-public mailing list