linaro-project-management team mailing list archive

[Amit Kucheria <amit.kucheria@xxxxxxxxxx>]

On Tue, Aug 16, 2011 at 3:15 PM, Zach Pfeffer <zach.pfeffer@xxxxxxxxxx> wrote:
> 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.

I'm willing to give it a try, but I am concerned about how anybody is
going to figure out what work was done on a feature if it is
splattered across 5-10 monthly blueprints?

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

We differ in our perspective. You're looking at it from the POV of
making a release. I'm looking it from the POV of keeping all the data
on a feature in one place to be able to point to upstreams/prospective
members, non-Linaro member engineers, etc.

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

OK. We'll try it for 11.09 (with reservations) and see what blows up.

/Amit