Hi Ilias, On 3 January 2012 08:39, Ilias Biris <[email protected]> wrote: > Hi folks > > handling technical debt is a smallish issue that we should think on how > to tackle. > > The main issue I have relates to the limitations of launchpad + our > current process. Most common case for me is many small items from all > the blueprints in a release period, say 1 work item for every other > blueprint, for a total of 10 blueprints... At the same time, splitting > every one of the original blueprints just for 1-2 work items in each > one, seems an overkill and unnecessary bureaucracy. > > Instead I would like to propose using a special blueprint called > "technical debt" per project, which will maintain dependency links to > all the blueprints with outstanding small work leftover. The technical > debt blueprint can move from release to release, the target is to get to > releases with 0 techn debt. >
The platform groups have been dealing with this issue too. During the postmortem reviews done typically on the last week of the cycle, any blueprints with unfinished items are scrutinized. Depending on the amount of work items unfinished, a decision is made on what to do with the remaining work. If the spirit of the blueprint was not fulfilled then the entire blueprint is re-targeted to the next cycle. If some major functionality has been delivered, the blueprint can be split, with the finished work marked as 'implemented' and the unfinished work in a new blueprint targeted to the next cycle. If there are only one or two minor items that need to be finished but did not make it into the release, we have been assigning these to bugs and noted in the original blueprint . This prevents them from languishing in a backlog or in a low priority blueprint. The advantage of this method is that all work that has been done for the current cycle is documented and pigeon-holed where it belongs. The unfinished work is then targeted at a future milestone and can be tracked accordingly. > There are pros and cons > - pros: The teams do not face much bureaucracy, they do not even need to > split the original blueprints. The PM can take care of linking the > leftover blueprints to that techn debt blueprint via the dependencies. > > - cons: Since the linkage is done via dependencies, the techn. debt > needs to be kept low, otherwise it will be hard to trace all the small > leftover items if they pile up. Still the PM can and should be ready to > give a complete picture on what is still owed as work. > > Counter-arguments? Does anyone mind if I try this during 12.01? What I can add as a con is that should the number of unfinished items start to rise, you are worse of than before since you now have many more blueprints to deal with and the problem becomes one of unfinished blueprints, not just unfinished work items. > > Many thanks, > -- > Ilias Biris [email protected] > Project Manager, Linaro > M: +358504839608, IRC: ibiris Skype: ilias_biris > Linaro.org│ Open source software for ARM SoCs > > _______________________________________________ > 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 Cheers, DZ -- David Zinman Linaro Release Manager | Project Manager Linaro.org | Open source software for ARM SoCs _______________________________________________ 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
