<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 10, 2016 at 4:01 PM, Michael Kleinhenz <span dir="ltr"><<a href="mailto:kleinhenz@redhat.com" target="_blank">kleinhenz@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think this is possible with the current discussion version of the<br>
model. Key to this is I think:<br>
<br>
1. Iterations are hierachical<br>
    -> an Interation on a program level may contain several iterations<br>
on an implementation level, also across projects.<br>
        So we could have "business iterations" that contain several<br>
iterations of other projects in the org.<br></blockquote><div><br></div><div>I'm unsure whether business iterations need to roll up other iterations.</div><div>But, lower level product backlogs do have to be rolled up to a higher level portfolio backlog.</div><div>We can continue discussing this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2. Work items to work items links are completely domain-specific as<br>
well as the type of the work items<br>
    -> we can define any relation beween work items as the context<br>
sees fit. So we could define "program work items"<br>
        in addition to "implementation work items" and a 1:n relations<br>
between them for example as part of the<br>
        "project template" (to speak in vso terms). This also applies<br>
to epics (and this is equally important on<br>
        a business level, but more or less a minor feat in our implementation.<br></blockquote><div><br></div><div>+1, the WIT of items in a portfolio backlog is often different from the WIT of WIs in a product backlog.</div><div>Portfolio backlogs often have initiatives, features or epics, which map to stories or tasks in a product backlog.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3. We allow for several projects on the org level, with possible<br>
interpendency (aka "linkability") of entities across all<br>
    entities of an org.<br>
<br>
Yes, we need that kind of model and we will most likely encounter more<br>
requirements like this later and in the future. The challenge here is<br>
to create a system that can offer this stuff on a configuration level<br>
while not crossing the border of "generic turns into unmanageable"<br>
line.<br></blockquote><div><br></div><div>+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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-- Michael<br>
<div><div class="h5"><br>
<br>
On Thu, Nov 10, 2016 at 11:18 AM, Vineet Reynolds Pereira<br>
<<a href="mailto:vpereira@redhat.com">vpereira@redhat.com</a>> wrote:<br>
> Hi,<br>
>    I haven't seen a lot of discussion on this topic. When reviewing the<br>
> walking skeleton [1], I noticed a feature area on portfolio management.<br>
>    Now, portfolio backlogs are different from project backlogs in that<br>
> highest level initiatives that cut across multiple project teams are put<br>
> into a portfolio backlog. This is often done by a program manager. Work<br>
> items in a portfolio backlog eventually find their way to one or more<br>
> lower-level product backlogs. Individual project teams work only their<br>
> product backlogs.<br>
><br>
>    I've seen similar features in VSTS and JIRA. Do we intend to support<br>
> anything like this?<br>
><br>
> Vineet<br>
><br>
> [1]:<br>
> <a href="https://docs.google.com/spreadsheets/d/19woiNb1ZDi4douxoDeQ0SMx6SMSfO5b9AyeoRBAibFA/edit#gid=1230916644" rel="noreferrer" target="_blank">https://docs.google.com/<wbr>spreadsheets/d/<wbr>19woiNb1ZDi4douxoDeQ0SMx6SMSfO<wbr>5b9AyeoRBAibFA/edit#gid=<wbr>1230916644</a><br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> almighty-public mailing list<br>
> <a href="mailto:almighty-public@redhat.com">almighty-public@redhat.com</a><br>
> <a href="https://www.redhat.com/mailman/listinfo/almighty-public" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/almighty-<wbr>public</a><br>
><br>
<br>
<br>
<br>
--<br>
Michael Kleinhenz<br>
Principal Software Engineer<br>
<br>
Red Hat Deutschland GmbH<br>
Werner-von-Siemens-Ring 14<br>
85630 Grasbrunn<br>
Germany<br>
<br>
RED HAT | TRIED. TESTED. TRUSTED.<br>
Red Hat GmbH, <a href="http://www.de.redhat.com" rel="noreferrer" target="_blank">www.de.redhat.com</a>,<br>
Registered seat: Grasbrunn, Commercial register: Amtsgericht München,<br>
HRB 153243,<br>
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,<br>
Michael O'Neill<br>
</blockquote></div><br></div></div>