linaro-project-management team mailing list archive

[Zach Pfeffer <zach.pfeffer@xxxxxxxxxx>]

On 15 August 2011 04:29, 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.

We've been doing the monthly milestone thing since 11.05:

https://launchpad.net/linaro-android/+milestone/11.05
https://launchpad.net/linaro-android/+milestone/11.06
https://launchpad.net/linaro-android/+milestone/11.07
https://launchpad.net/linaro-android/+milestone/11.08 - in progress

I've actually found that by executing each month that I end up with
less WIs that are more directed. If something doesn't get done and
there's been something tangible completed I split the BP. If nothings
really been done I either move the BP to the next month or put it into
the backlog.

The other nice thing is that its easy to create Headlines and
Acceptance criteria on the smaller chunks of work.

> Consider the case of developing a tool, say, powerdebug. Every month we might
> add a small feature or so. Or fix a bug. So I'm expecting there to be 1-3 WIs
> related to powerdebug every month. You're asking me to create a new blueprint
> every month for 1-3 work items. I find that unreasonable.

I'm not sure why this is so unreasonable. It takes roughly 1 min to
create a BP for the month. Plus once its created than people like
Android or Platform can see what the 1-3 features you're going to
deliver and create matching integration BPs.

> I might be in the minority here, but I feel that creating blueprints has a
> lot of overhead (drafting, assigning, status, milestones, dependency linking,
> etc.), not to mention sustained housekeeping (whiteboard, status, work items)
> and making sure that outsiders can make sense of our blueprint hierarchies.

With the month-to-month planning I find BPs don't take much time to
make. I always keep in mind that a BP is just a tracking and
communication tool, its not the work.

> The only way I'd find this remotely enjoyable is if we had a blueprint clone
> tool that DTRT.
>
> 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?

I'd vote against this. It may be a tool limitation, but its much
easier to look at the BP list:

https://launchpad.net/linaro-android/+milestone/11.07

...and see whats coming than drilling down into each one.

> 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.

Its been my experience that the monthly view is easier to grok for
external people looking at a project than having a 6 month detailed BP
which someone has to dig through.

> Can't we teach the LP milestone view to understand repeated retargetting of
> the blueprint every month?
>
> /Amit
>
>