On Tue, Aug 16, 2011 at 7:20 AM, Alexander Sack <[email protected]> wrote: > On Mon, Aug 15, 2011 at 11:29 AM, Amit Kucheria <[email protected]> > wrote: >> >> On 11 Aug 15, Michael Hope wrote: >> > On Sat, Aug 13, 2011 at 4:24 AM, Joey Stanford <[email protected]> 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.
We'll give it a go. A blueprint 'shard' tool that clones the blueprint priority, milestone, and other meta data would be nice. -- Michael _______________________________________________ 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
