linaro-project-management team mailing list archive

[Alexander Sack <asac@xxxxxxxxxx>]

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.


-- 

 - Alexander