linaro-project-management team mailing list archive

[Ilias Biris <ilias.biris@xxxxxxxxxx>]

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 ilias.biris@xxxxxxxxxx
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs