Automatically Inheriting Owner to Tasks in Story Template

[christo...@mcafee.com]

Hi,

is there a way to automatically set the owner of a set of tasks to the
owner being set on the parent user story? E.g. when I change the owner
of the story, is there a way to automatically set the owner of all its
child tasks to the same person?

Thanks, Christoph

[Wortman, Bret D.]

I'm not sure you'd want to do this -- the idea behind agile development is to share responsibility amongst the team, and having one person own the story defeats team collaboration. Breaking a story into tasks allows sharing of tasks amongst the team members, leading to collaboration and true team ownership of the story.

Hi,

Thanks, Christoph

--
You received this message because you are subscribed to the Google Groups "VersionOne-users" group.
To post to this group, send email to versiono...@googlegroups.com.
To unsubscribe from this group, send email to versionone-use...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/versionone-users?hl=en.

[Christo...@mcafee.com]

I sure wouldn't want to prohibit changing the owner of individual tasks afterwards, let alone adding more tasks; this is solely about default population of the Owner field when starting a new story. Starting a new story that has a set of tasks with no owners.

Thanks, Christoph

Hi,

Thanks, Christoph

Firmensitz: Muenchen
Amtsgericht: AG Muenchen
Handelsregister: HRB 144340
Geschaeftsfuehrer: Emmet Russell, Keith Krzeminski, Douglas Rice
Bankverbindung: ABN-Amro Bank N.V. Konto 671 211 9006
UST-ID: DE168122444

[Wortman, Bret D.]

What we do is to start all tasks with no owner. It makes it clear that all work is available to be claimed by anyone at any time. Developers then at the start of the sprint claim a task that they most want to work on or which they feel most needs to be worked on. They work it to completion and then select the next unclaimed task.

Work should not be assigned, it should be claimed. Work is not pushed to developers, it is pulled by developers. Here's a blog post that summarizes the difference pretty well: http://blogs.msdn.com/b/elee/archive/2010/01/21/push-vs-pull-in-scrum.aspx

The danger of preassigning all tasks is that if someone gets sick, or someone is overloaded, that isn't immediately obvious. The work appears to be okay -- it's assigned, so someone must be taking care of it. If I finish my work early and I have available bandwidth to do more, it's harder for me to figure out what's available for me to do if I have to go around and ask everyone what they have or haven't started, and let's be honest, not all developers are rigorous about updating the tool with their current status.

Leaving the work unassigned makes it very clear what's available to be worked.

Bret

[MikeD]

Hi Christoph,

The series of questions you have posed suggest a pattern to me, as an
Agile Coach, where folks are actually going away from several aspects
of collaboration and learning that happen when folks actually
interact to determine some of the items you are trying to automate.
Estimates for instance... the activity of a team estimating stories or
tasks as a team is how learning between folks of different levels of
experience can occur and also enables teams to form common references
to estimation. This is key for agile estimation.

Additionally as Bret points out. Pre-assigning owners tends to also
limit cross-training and maintain siloed resources on teams which can
cause teams to get blocked sooner and have lower through put.

It might be a good idea to really reflect on what is the root cause
for wanting to automate this stuff. Do you and your team not see value
in the collaborative aspects of agile execution? Is the approach not
supported by management, you're not given the time so you're looking
for how to cut out the process? Do you currently have functionally
siloed teams?

-Mike