linaro-project-management team mailing list archive

[Ilias Biris <ilias.biris@xxxxxxxxxx>]

On 17/06/11 23:11, Joey Stanford wrote:
>> 14/32:  proposal: since we are accelerating cadence we ought to observe
>> a decrease on batch sizes per queue per team. Can we get some flow
>> diagrams in s.l.o eg cumulative flow diagram of the queue size per team,
>> to see other opportunities for improvement? With historical data we
>> could also show trends per team in order to spot possible flow problems.
>> Also how about measuring the aging on queues?
> 
> Yes, great idea. How?
> 

An image is worth 1000 (or more) words, so check a way to do CFDs with
google spreadsheets here:
http://open.bekk.no/cumulative-flow-diagrams-with-google-spreadsheets/,
(we can redefine the status of the items there as per our work item
statuses: TODO, INPROGRESS, POSTPONE, BLOCKED, DONE)

The CFD should show what happens to our work items over time, leading to
the calculation of how much time (on average) a work item remains in the
queue before it gets done. We can check how much work overall gets DONE
vs BLOCKED or POSTPONED over time.

With that knowledge I could for example speculate and discuss what are
the circumstances in different teams and how to improve the flow. This
would add value for the project management and the team leads beyond the
burndown chart.


>> 21/32: we should also measure efficiency in queue handling, eg size of
>> queue, trends on size, aging of items in the queue as well as feedback
>> speed (how long from blueprint getting created to getting approved to
>> getting done) and overall aging of problems
> 
> Could do. How?
> 

Once we have the CFDs getting churned, we can start measuring trends
such as - what was the fluctuation of the queue size over a period of
time - so what was the fluctuation of Work In Progress over a period?
Also we can check the trend of the time it took to solve work items per
team (from getting INPROGRESS to getting DONE) - similar to the bug
resolution time metric seen in other organizations.

A different type of aging can be the delay to start something: say I
take some item in the queue for 11.07 (TODO). I spend about 3 weeks
before I mark is as INPROGRESS. Why did I spend so much time? Many cases
are due to legitimate reasons, but this delay could be indicative of a
problem either in the way the team breaks down work or in dependencies
elsewhere, in either case the metrics should give a context for anyone
to ask questions :-)

Does that make better sense to you Joey? How about others, do you think
these metrics would be a good idea?

Best,

-- 
Ilias Biris,
Aallonkohina 2D 19, 02320 Espoo, Finland
Tel: +358 50 4839608 (mobile)
Email: ilias dot biris at linaro dot org
Skype: ilias_biris