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 <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~linaro-project-management Post to : [email protected] Unsubscribe : https://launchpad.net/~linaro-project-management More help : https://help.launchpad.net/ListHelp
