Hello! During the review of Q2 roadmap cards there was some feedback related to process and the cards themselves. I collected as much as I could and put it below for a wider review - here are the main points and my proposed solutions.
-- 1. Process related: some felt the roadmap process is complicated (at least as implemented via JIRA - see the flow diagram in https://wiki.linaro.org/OPSCOM/RoadmapProcessWithJIRA#JIRA_Workflow_transitions_diagram). Proposal: I have now circulated a proposal to opscom first for comments - the changes involve removing 2 states from the flow, and simplifying the process. I will shortly also share this with the techleads for more feedback. -- 2. When do the roadmap cycles start and end? Not aligning with the release milestones can cause problems in finishing deliverables on time. Proposal: roadmap cycles should as much as it is practically possible align with release milestones to facilitate delivery and planning. -- 3. If work is not completed for a roadmap card, is it preferable to create new cards covering the missing parts or extend an existing card? Proposal: if the project is not really finished (ie most acceptance criteria are not complete, the core of the work is still largely unfinished) then it is better to continue with the existing card. If the card deliverables are mostly done is or if there is need to change major parts of the unfinished acceptance criteria then it is better to create a new card. Usually this is assessed during the cards review at delivery time. It would be helpful to identify, during card drafting, the minimum core of acceptance criteria (the ones that if NOT delivered would render the whole card unfinished). -- 4. Should the cards be split to cover individual "projects" or should they be munged together to form "bigger" cards with high level goal defined and with a breakdown of the work packages involved, having individual acceptance criteria for each work package? Issues related to this question a. Requesting specific card content density and amount of cards may cause rework on the cards and potential loss of acc. criteria when cards are merged together. Munging cards together seems to not make sense, if it is done simply for the sake of having "less cards" for the quarter. b. Generality in "big overarching"/"munged" cards vs clear & concise "project-based" cards. The "munged" cards aim to move a bit away from project-based thinking, getting the teams to think on the missions, overarching achievement goals or themes that a team should aim for the period ahead listing also what outputs will be. i. In some cases the themes and directions are bigger efforts - epic-like, covering a future period of 6-12 months. The problem when trying to identify subtopics can be that these subtopics are of smaller effort than necessary in order to constitute 1 card. Lumping cards together can lead into having general descriptions which fit the "epic" description, whilst focusing at delivering much smaller subtopics of that "epic". Much of this issue is how to do the splitting and how to give proper names and descriptions to these quarterly-based cards to make them meaningful. ii. Are we missing a level of abstraction there in process/JIRA? For example, we could have epic JIRA cards which would relate to large compounds of work (missions) - and as a separate level we could have the epic-children JIRA cards covering the work needed to complete the epic. We do support the "epic child cards" now, but we are missing epic-level cards. iii. Marketing vs operational cards: Another way to think of this issue is defining the cards top-down (marketing missions breaking down to projects, breaking down to work packages, which in turn take care of technical issues) vs bottom up (technical issues defining the mission). Taking the strategic direction means that cards should be closer to missions (top) rather than specific technical issues (bottom). Would it be best to handle missions through the cards and use the blueprints to cover the work packages / technical issues Proposal: I personally think this issue is related to best practices + tool issues. Tool-wise we should have support for epic cards and linking them to subtopic cards. The former involve effort for 6-12 months, the latter up to 2-3 months. Best practices then need to be reached for each team in order to decompose the epics into subtopic cards, and these cards into blueprints for the work to be planned without missing acc. criteria for quarter deliverables. Please voice your ideas here - also point any other issues that I may have missed! 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
