linaro-project-management team mailing list archive

[Michael Hope <michael.hope@xxxxxxxxxx>]

On Tue, Aug 16, 2011 at 7:20 AM, Alexander Sack <asac@xxxxxxxxxx> wrote:
> On Mon, Aug 15, 2011 at 11:29 AM, Amit Kucheria <amit.kucheria@xxxxxxxxxx>
> wrote:
>>
>> On 11 Aug 15, Michael Hope wrote:
>> > On Sat, Aug 13, 2011 at 4:24 AM, Joey Stanford <joey@xxxxxxxxxx> wrote:
>> > > Hi TLs and PMs,
>> > >
>> > > As we think through the delivery of monthly milestones and their
>> > > affect on status.linaro.org it's become very apparent that WIs should
>> > > /not/ span months. Instead they should exist on a BP you intend to
>> > > deliver in one month.  If you have a piece of work that will span
>> > > multiple months then it should be multiple BPs (i.e. one BP per month,
>> > > not two months working on one BP).  If you think you'll span months,
>> > > please split the work into (minimally) one month chunks as BPs.
>> > >
>> > > This allows us to use the LP milestone view and not spend time
>> > > updating status.l.o with essentially duplicate functionality. It also
>> > > allows us to spend more time improving the "card view" (Roadmap item
>> > > completion).  Additionally it allows us to better communicate
>> > > success/failure to the TSC (we're delivering something that someone
>> > > could attempt to use vs some obscure subset of WIs).   And lastly,
>> > > it's just plain easier for you to manage a single BP per month than
>> > > WIs from several BPs spanned across multiple months.
>> >
>> > What's the driver behind this?  I'm concerned we're working around
>> > limitations in the tools and losing information along the way.
>> >
>> > Say I have a feature that will span months.  At the moment I have one
>> > blueprint that tracks that feature with clumps of work items that go
>> > against the months.  The work items are small and much less than a
>> > month so, if I'm ahead of schedule, it's easy to pull in extra work
>> > for this month by shifting lines on the whiteboard.
>> >
>> > This feature == blueprint is easy to find and share.
>> >
>> > The alternative is splitting the feature into many blueprints and
>> > adding them as dependencies.  The current Launchpad UI makes ordering
>> > these hard, duplicates lots of information, and makes it hard for a
>> > Roger-like person to understand what's involved.  As blueprints are
>> > roughly a month, then you risk being 90 % done but missing the
>> > milestone, and can't easily pull in work from next month.
>>
>> I agree. This one-month limit for blueprints feels arbitrary. I have 30+
>> feature (engineering) blueprints ATM. Separating them into monthly
>> blueprints
>> will explode the number and make them harder to find and track.
>>
>
> So in the past (when we first did the monthly releases slides) we said we
> wanted to support a "multi month" blueprint by having the ability to deliver
> multiple tangible headlines from it. This was meant as a legacy approach to
> support transforming the already drafted 11.11 blueprints.
>
> There, each work items block would require - same as for one blueprint for
> each monthly working block approach -  a headline and an acceptance
> criteria.
>
> Now we are moving closer to the end of 11.11 it feels that we shouldn't code
> that support into the status.linaro.org.
>
> How about you try out the new model with new work arriving and keep the
> legacy blueprints running as they are polishing each work item block with a
> nice headline and acceptance criteria for now?
>
> My feeling is that you will notice that having one blueprint for each month
> (referring back to a roadmap card) approach works fine and isn't that much
> overhead for you after all. Your PM should be able to help you with the
> added manual action and set you up.
>
>> The only way I'd find this remotely enjoyable is if we had a blueprint
>> clone
>> tool that DTRT.
>
> thats an interesting idea to keep in mind.
>
>>
>> Why can't we live with "Work items for <milestone>:" sections in a single
>> blueprint so that all information related to said feature can be found in
>> a
>> single place?
>
> we could have that; the milestone view would not show nicely what was
> delivered without inventing something in launchpad; also its hard to add
> milestone specific comments and besides adding ability for headline and
> acceptance for each work item block we probably would also need to add
> support for comments for each block etc.
>
> It would be much easier if we could avoid such multi-sprint blueprints until
> we hit a real case were we think we really miss something with our current
> way of doing.
>
>>
>> The TSC and (non-assigned) member engineers are just beginning to
>> understand
>> how to track our work. Monthly blueprints will scatter information across
>> several blueprints making it impossible for them and further increase load
>> on
>> us to provide them with yet another status report.
>
> I don't think that's the case. Remember, there will be a roadmap card that
> will allow TSC and stakeholders to drill down to _all_ the blueprints
> associated with that card you have DONE so far, that are INPROGRESS and that
> are TODO.
>
> Now if you think about nice headlines of each of the blueprints TSC and
> friends will get a nice comprehensive list of what was achieved, what's
> currently done and whats in the future pipeline for any specific card they
> are interested in.

We'll give it a go.  A blueprint 'shard' tool that clones the
blueprint priority, milestone, and other meta data would be nice.

-- Michael