What is the advantage of having two people assigned to a single
workitem, over having a child workitem for each additional user working
on the task?

JPibm wrote:

Hello,

This idea may have been posted before, but I did not see it while
doing an initial scan, so I figured I would mention it. I am working
with a colleague of mine, and we are using Jazz to manage our
development efforts. Alot of our work is done collaboratively, and
we often find ourselves working on the same tasks. Generally, we
create the task for one person, and duplicate it and assign the
duplicate to the other person. We feel like there should be an
ability when creating a work item, to assign to multiple people, and
have both team members have ownership of that one task.

We've been having that discussion at part of our evaluation of Jazz for use by the J9 team and we don't feel that's a solution. That feels like a hack that just makes things confusing.

We'd be bastardizing the use of duplicate to also mean two people working on the same task. It also means that if you, as a manager, truly want to know who worked on tasks you'd have to follow all the duplicate links.

If the task you are duplicating is actually a bug report from a client do you create a duplicate defect? Now your defect creation/closing numbers don't match up since an actual defect as reported by a client has two Jazz defects just for the purpose of having two owners.

Further, if someone else comes over looking for this work item which one do they comment on? If there's N people working on a defect you have N work items to open and see which one everyone has been commenting on.

All of this makes the user interaction with the system more complicated they it has to be.

What is the advantage of having two people assigned to a single
workitem, over having a child workitem for each additional user working
on the task?

Note that I wasn't suggesting that you make a "duplicate" task (that I
agree would be wrong). What I was suggesting was that when an
additional user works on a task, that they be assigned a "child" task.

But I do agree there is an issue here (which I've filed a while back,
see workitem 21879). The issue is the lack of separation between the
"issue" being raised, and the "tasks" that are being performed to
address the issue. If we had such a separation (where the person
raising the issue would own an "issue" record, and the people working on
the issue would each have a "task" record, and the tasks would linked to
issues), then it would be obvious where to comment ... on the "issue" if
you have a comment on that issue, or on the "task" if you have a comment
on how that task is being performed. This would also allow you to
explore/record different ways of addressing an issue, by having two
different tasks associated with that issue. This is particularly
important when you need to fix an issue in multiple releases, when
different work needs to be performed in the different releases. You
want one "issue" record (owned by the submitter of the issue), but
multiple "task" records (one for each of the releases which requires a
different solution).

But back to the suggestion of having multiple owners, at some point you
need to solve the problem of displaying a "composite" task in an easy to
digest fashion anyway (some issues require a whole team over a period of
weeks to solve). Once that problem is addressed, having two people work
on a task is just a simple edge case for this general problem.
Also, multiple owners has "accountability" problems ... when an issue
has multiple owners, it is unclear who is "responsible" (thus my
preference for "child tasks", so there is a clear owner for any given
issue).

Note: This is just my 2 cents worth ... and does not reflect any general
agreement on this issue on the part of the workitem team.

Cheers,
Geoff (ClearCase Connector Team)


gcastro wrote:

We've been having that discussion at part of our evaluation of Jazz
for use by the J9 team and we don't feel that's a solution. That
feels like a hack that just makes things confusing.

We'd be bastardizing the use of duplicate to also mean two people
working on the same task. It also means that if you, as a manager,
truly want to know who worked on tasks you'd have to follow all the
duplicate links.

If the task you are duplicating is actually a bug report from a client
do you create a duplicate defect? Now your defect creation/closing
numbers don't match up since an actual defect as reported by a client
has two Jazz defects just for the purpose of having two owners.

Further, if someone else comes over looking for this work item which
one do they comment on? If there's N people working on a defect you
have N work items to open and see which one everyone has been
commenting on.

All of this makes the user interaction with the system more
complicated they it has to be.

What is the advantage of having two people assigned to a single
workitem, over having a child workitem for each additional user
working
on the task?

I'm not sure having an "issue" is any better. The task these two people are working on is not a composite. They're literally working on the exact same thing (ie. pair debugging from the same machine). The task is already fully decomposed.

All we want is to be able to account for the time these two people spend on a task/defect. Creating entire tasks just so we can count the estimates towards more than one person seems like overkill.

If you were to pictures this from a UI perspective you'd be pulling the owner and estimate attributes into one table attribute that lists all the owners and their estimate.

As for accountability I'm not sure it's a problem. Whoever owns the item is accountable for the changes contained therein (if there are 2,3,4 owners all are accountable). Plus, we also know exactly who delivered a certain changeset already.

Note that I wasn't suggesting that you make a "duplicate" task (that I
agree would be wrong). What I was suggesting was that when an
additional user works on a task, that they be assigned a "child" task.

But I do agree there is an issue here (which I've filed a while back,
see workitem 21879). The issue is the lack of separation between the
"issue" being raised, and the "tasks" that are being performed to
address the issue. If we had such a separation (where the person
raising the issue would own an "issue" record, and the people working on
the issue would each have a "task" record, and the tasks would linked to
issues), then it would be obvious where to comment ... on the "issue" if
you have a comment on that issue, or on the "task" if you have a comment
on how that task is being performed. This would also allow you to
explore/record different ways of addressing an issue, by having two
different tasks associated with that issue. This is particularly
important when you need to fix an issue in multiple releases, when
different work needs to be performed in the different releases. You
want one "issue" record (owned by the submitter of the issue), but
multiple "task" records (one for each of the releases which requires a
different solution).

But back to the suggestion of having multiple owners, at some point you
need to solve the problem of displaying a "composite" task in an easy to
digest fashion anyway (some issues require a whole team over a period of
weeks to solve). Once that problem is addressed, having two people work
on a task is just a simple edge case for this general problem.
Also, multiple owners has "accountability" problems ... when an issue
has multiple owners, it is unclear who is "responsible" (thus my
preference for "child tasks", so there is a clear owner for any given
issue).

Note: This is just my 2 cents worth ... and does not reflect any general
agreement on this issue on the part of the workitem team.

Cheers,
Geoff (ClearCase Connector Team)

I personally believe there always should be exactly one person who owns
a given task, and everyone else is a helper. The owner of the task owns
the parent task, and each helper owns a child task. The owner of the
task knows that he/she has the responsibility for making sure it gets
done (even if the bulk of the work, or even all of the work, is done by
the helpers). Otherwise, even with the best intentioned set of people,
things slip through the cracks when everyone assumes "someone else" will
get it done, or almost as bad, everyone is wasting time redundantly
checking whether or not the task is done. In addition, you know who is
"in charge" of that particular task, in case there are disagreements
about how it should be done.

If there is no good way to pick the owner, flipping a coin is fine (but
if the work doesn't get done, it is the person who was selected by the
coin who is held responsible :-).

Cheers,
Geoff

JPibm wrote:

The use case I have in mind is this:

We have a general task of:

"Create a JSP/AJAX front end for the Eclipse Help System, to
allow a user to modify the help preferences within the Web UI, and
not have to go into Eclipse"

- 2 members of my team are working on this task. So i agree that we
would have Child tasks stemmed from this main task. My question is,
who would be the owner of the Parent task.. Me, or the colleague of
mine who is also working on Child Items of this task? Would the
Parent task be unassigned, and all child tasks would have an owner?
This is where we are hitting some confusion. We are both putting in
equal work on child tasks, but who owns the main parent task? Hope
that makes sense.

Yes, that's how I'd think about it.

Note that there are some issues in the current agile planning UI that
sometimes result in my choosing to replace a "parent-child" link with a
"related-to" link, but if you encounter something like this, please file
an enhancement request against the planning component, because having
the GUI properly handle these kind of work-breakdown structures is
important.

Cheers,
Geoff

JPibm wrote:

Hi Geoff,

Thank you for clearing this up for me. Initially, thinking about
project organization, we tended to group many work items into one
Milestone, and not organize the work items in a milestone with Parent
- Child relationships (even though many tasks were subsets of another
task, we grouped them all at one level).

In addition to that, thinking back on what you said and keeping a
layered approach in mind, the top level project would have been owned
by my manager, and then main components of the project would have been
owned by certain developers on the team. Then, work items of the main
components may be mostly done by the developer owning the component,
however other developers may develop small pieces of components they
do not own, and will work on these work items even though they do not
own the high level project the work item falls under.

Am I thinking right? : )


Thanks Again!