linaro-project-management team mailing list archive

[Mattias Backman <mattias.backman@xxxxxxxxxx>]

On Wed, Oct 12, 2011 at 12:01 PM, Ilias Biris <ilias.biris@xxxxxxxxxx> wrote:
> Hello Mattias
>
> first of all this looks like a good start. I think that looking at the
> health of cards will be useful for product management as well as the
> teams. So as a start this look ok.
>
> Here are some questions I had trying to imagine using this info:
>
> 0. Is this supposed to cover all states of a card? The states I have
> recorded from the documentation are
>
> NEW/DRAFT, NEW/ACCEPTED, Qn/PLANNED, Qn/READY, Qn/DELIVERED,
> Qn/INCOMPLETE, Qn/DEFERRED
>
> Are all going to be covered ?

If those states are all handled in the Kanbantool UI, then the cards
will show up in the correct lane with the correct status even if you
would add or change status or lane names. If some of those states have
to be inferred from other information, I have yet to code that though.

>
> 1. I suppose a health check for a roadmap card should push to action -
> to correct any issues. If so will there be a visual queue as to what is
> wrong or would the reader have to scan the whole information presented
> in such a health check and infer that action is needed?

Any card that is unhealthy can have that visualized in the lane view
as well as on the card detail view.

>
> 2. There should be some way to reach the criteria shortlist for a card
> to be 100% healthy.
>
> So each state mentioned above should have some criteria for the health
> check. For example it may be perfectly ok for a NEW (or even a PLANNED)
> card to not have blueprints for example. In fact afaik the card state
> where blueprints are supposed to be there is Qn/READY.

This is very good to know. So then I'd need to have a list of health
checks for each state. Or rephrasing that; know for each health check
which states that would apply to.

>
> Providing a shortlist of the criteria in some part of this page would
> allow anyone to check then why their cards are not good. Even if the
> visual queue is not given - as I was asking in 1 - the criteria should
> be clear to all, so that action can be pushed for with a justification.

Absolutely. We're thinking a table at the bottom of the page
displaying the result of all the applicable health checks for that
card.

>
> 3. I +1 Mounir's suggestion to show the priority of a card if it is set.

Sure, that's easy to do.

>
> 4. Having Blueprints associated with a card is a generally useful
> criterion. For some card states however, I'd like to know what is the
> ratio of Implemented Blueprints out of the total Blueprints associated
> with the card. For example if a card is marked DELIVERED then there
> should be some indication of the delivery - eg show how many blueprints
> are Implemented out of the total blueprints linked with the card

Would it be ok to have that displayed regardless of the state? That is
provided that there are any blueprints linked.

>
> 5. Especially for  READY/DELIVERED/DEFERRED/INCOMPLETE states I'd like
> to have a link to LP blueprints associated with the card. Then I could
> simply inspect from the top-down (from roadmap card downwards) what is
> done, what is still not finished etc. Is that even possible to provide?

As implemented now, the card detail page displays a list of all the
linked blueprints with their status. There are no linked blueprints
yet to show off that yet though, but you can see it as soon as we
start putting the card id:s in the blueprint whiteboards.

>
> I hope these make sense, please consider these as items in your backlog,
> I do not mean to ask everything to be there from the start but it would
> be good to know if/when these features would be available.

Absolutely. I think it all makes sense so I'll start working on some
of the items that seem to be most clear. I'll let you know when there
is more to see and I'll gladly listen to your feedback whenever you
have some.

Thanks,

Mattias