linaro-project-management team mailing list archive

[Alexander Sack <asac@xxxxxxxxxx>]

When discussing the monthly model, I got feedback from techleads and
PMs that they would like to keep a single page that tracks all the
blueprints and work items for the upcoming milestones of all
components the team participates in.

This seems to be not included in current slidedeck/plan. Here a
proposal that would give a team a single page to look at to track
their progress for all upcoming deliveries.

Proposal for Team Page:
 * current monthly milestone team page becomes a "upcoming milestones
for team" page

 * work item burn down gets killed because there might be conflicting
dates - also I believe a burn down for just a month is often not that
meaningful.

 * status by blueprint becomes "upcoming deliverables"; grows columns:
component name + milestone + days left till delivery

 * status by assignee gets killed (because its hard to display this
with multiple milestones "upcoming this month" this way)

 * work item details get sorted by "delivery date" and only second
order by "importance"; this gives PMs and engineers a quick view on
what to deliver next.

On Wed, Aug 10, 2011 at 7:19 PM, Joey Stanford <joey@xxxxxxxxxx> wrote:
>> I propose option 1.
>
> +1 for quick and dirty
>
>
>
>> Card view
>> ---------
>>
>> For this we really need an API for the cards. Does kanbantool have an
>> API? This is a risk.
>
> No but you can wget
>
> http://linaro.kanbantool.com/boards/8991.csv
>
> which will be the latest in .csv format.
>
> I've submitted a question to them to see if they have or will do an API.
>
>
>> Milestone view
>> --------------
>>
>> I'm not sure what we want to do here yet, it requires some more thought.
>
> I want to be able to see
>
> 1) everything targeted to a milestone that you see in LP already -
> bugs and blueprints
>
> 2) some mechanism to see WIs which are targeted for this milestone
>
> I know that we'll want to use a measure of BPs, Bugs, and WIs
> completed this month for statistical purposes.
>
>
>> Performance information
>> -----------------------
>
> [snip]
>
>> In addition we might want aggregate info for completed lanes. This would
>> show things like number of workitems and %completed for each of the
>> months/quarters.
>
> Yes, as above and some level of monthly status. George (for those on
> copy) has requested historical data on numbers and has no interest in
> seeing past results.
>
> The question becomes then, if we keep just number data (e.g. number of
> bugs, BPs, and WIs complete) do we also need to keep that data as well
> or would the LP milestone page be sufficient knowing that it will not
> show WI information.  I believe that we'll need to keep 6 months worth
> of FULL data for analysis. 6 months is also a nice number to mesh with
> Roadmap planning, answering late arriving questions from partners, and
> also to see trending (although the trending can be done only with
> numbers and not require full data).
>
> I do not believe we want to keep more than 6 months of data (e.g. like
> a year) because it will a) grow stale, b) be used in an attempt to
> gather extended performance metrics, c) be used to focus on longer
> term, non-Agile, activities. Thus I'd like to remove the temptation
> from anyone.
>
> James, after folks have commented on this, would you please have a
> think about an estimate for this, making any default assumptions you
> feel necessary for "version 1". We can customize this as we need to in
> the future.
>
>
>> Blueprint/card health check
>
>> Estimate: 3 days for simple health check, 2 days for workitems errors, 2
>> days for per-team view.
>
> I suspect you'll need an extra day for card check given that you may
> need to process csv files.
>
>
>> Launchpad milestones
>> ====================
>>
>> I contacted Francis about whether we will be able to change the
>> milestone rules on Launchpad, and am awaiting a response.
>>
>> This is important if we wish to push some of the monthly visualisation
>> off on to Launchpad, otherwise we may be forced to provide the view in
>> status.linaro.org.
>>
>> This is a significant risk for this project.
>
> ACTION: Joey, Kiko, and ASAC to escalate to Canonical via the weekly
> sync meeting.
>
> ACTION: James - push through stakeholders meeting please.
>
>> AJAX workitem editing
>> =====================
>>
>> While this would be nice to have, it isn't required as it will still be
>> possible to edit workitems in the current manner.
>>
>> A prototype in greasemonkey is likely the best way to approach this.
>>
>> Estimate: defer from this round, so 0 days.
>
> I'd prefer not to defer anything but rather make a phase 1 and phase
> 2. I believe this all will be necessary, and not optional, but that
> phase 2 can hold features like this which can either be done after UDS
> and/or sourced out to the Community.
>
>
>
>> Bonus features
>> ==============
>>
>> I'm going to defer looking at this for now, except to stay that using
>> Launchpad milestone view for the team pages is apparently contreversial,
>> and so we should discuss that further.
>
> Please queue up for Phase 2. We can make the determination after UDS
> as to how we can proceed with it.
>
> James, would you be willing to write up the infrastructure proposal
> for phase 2 so we don't lose it?
>
>
>> Scheduling this work
>> ====================
>
> [snip]
>
>> So, it looks like we can take this on, with Mattias starting on it once
>> he finished hwpacks v2. Assuming we want this in two months, this
>> presents some risk, unless we have a backup plan for the next connect.
>
> Are you able James to work with Mattias beyond leadership to help him
> implement it?
>
> ASAC, Can you poll your teams during an upcoming Platform meeting to
> see if they can spare someone for a week or two to help Matthias &
> James?
>
>
> ----
>
> Thanks James for doing the write-up on this.
>
> Joey
>



-- 

 - Alexander