2009/5/7 Quim Gil <[email protected]>:
>
> 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:[email protected] | http://www.bleb.org/
Maemo Community Council chair
_______________________________________________
maemo-community mailing list
[email protected]
https://lists.maemo.org/mailman/listinfo/maemo-community
