[maemo-community] Sprint process (was: Re: May 2009 sprint meeting)

[From: Andrew Flegg]

2009/5/7 Quim Gil <quim.gil at nokia.com>:
>
> Proposal: no more than 3 tasks per person in a single sprint:
>
> - 1 MUST at most.
> - 1 SHOULD at most.
> - 1 COULD at most.
>
> If someone is done after 2 weeks he can help another tasks strucggling
> in the sprint. And there is always a backlog to keep you going.
>
> Not coompleting more than 50% of a committed sprint doesn't feel good,
> and it's like this almost every month.

Yup. Any feedback from the maemo.org staff members, now that this has
had a while to sink in?

> Proposal: every committed task has a corresponding thread in
> talk.maemo.org. The owner of the task can subscribe to it and get emails
> whenever someone comments anything. No comments, no harm. But at least
> people had a clear and easy chance.

Whose responsibility would it be to create these threads? Assuming we
keep the task ID idea, subjects should be consistent ("[Task:9.05-1]
Define new sprint process") and, ideally, the post should contain:
abstract & link to task URL (i.e. wiki Task: page or Bugzilla).

>>  * At least one "must" task (which was "definitely" committed to
>>    in April) is listed as at 0%. Despite concerns being raised
>>    about the feasibility of the task.
>
> If a task gets concerns in the panning meeting it shouldn't be
> committed. The owner can always push it from the backlog, if he really
> thinks this is the right thing to do.

There's a wider question of how best to run the sprint meetings - they
don't feel quite right to me, given that the task in question *wasn't*
queried in detail during the planning meeting (that came afterwards).

>> I would *much* rather things were debated when suggested rather than
>> just flat-out ignored. I would hope that people would come to the
>> sprint planning meeting in the next period with a fleshed out,
>> concrete proposal (as per the process[2]). Anything which is clearly
>> not achievable within 4 weeks should be challenged, and anything which
>> can have a note against it of "other than that this is [mostly] done".
>
> Definitely. Opening the gateway to tmo might help combining the silence
> in the sprint (a problem) with the yells in tmo (another problem),
> getting as a result more fruitful information and discussion in both
> areas.

Yup. For the next sprint meeting - unless there're any objections -
any task which doesn't have a clear URL defining what's going to be
done, and it doesn't seem reasonable is going to get challenged.

Status updates on tasks will be updated on the sprint page *before*
the meeting, with short summaries being given in the meeting; allowing
us to focus on new business more readily.

However, none of the regular contributors have give their input on
what is changes to their working practices.

> Proposal: sort the tasks of the sprint per priority instead of per date.
> This way it's easy to see how the sprint evolves and where to
> concentrate the attention: get the green on the top.

Good idea.

Cheers,

Andrew

-- 
Andrew Flegg -- mailto:andrew at bleb.org  |  http://www.bleb.org/
Maemo Community Council chair