On Fri, Oct 23, 2009 at 6:43 PM, markpetronic <markpetronic@...>
Does this seem to be a reasonable practice in the groups mind?
I join Rob
And then I have more insights on your initial post
1. How you all handle all these other supporting tasks that are required
to allow the /real/ stories to progress?
=> do them 'just it time'
it is ok to discard or add tasks when you do (or learn) more ('that was more easy as we planned' or 'hey we are having trouble with this one')
2. How do you schedule their priorities and track their completion since
most of them are dependencies for real stories to be worked on and
completed to our DoD? For example, can't do an acceptance test without
the function test environment setup.
=> track story done, not tasks
just move tasks in task board
classical board can use one swim lane for each active story, with task moving from 'to do', to 'done', that is from story on left to done on right
3. How do you factor into the team capacity for the sprint backlog the
time needed to do this /other stuff/ if that stuff is not on the
=> keep your estimates, and see if you need to commit to more or to less on next sprint
4. What is the general criteria or questions you ask yourself concerning
what should go into the product backlog in this regard and what should
it can be as simple as 'why should I put this story in backlog' :)