It's all about the answers!

Ask a question

Tracking time spent when reassigning or defering a work item


Daniel Hatfield (312) | asked Apr 28 '10, 10:35 a.m.
I have recently been working with a customer who is looking to roll out RTC and have JIRA in place today. JIRA has a way of people adding time spent to a ticket/issue. This means multiple people can work on an item.

What are the advantages of breaking up work items into multiple items with a parent item. There must be benefits that Team Concert provides from a reporting and planning perspective having this break down right?

Also what is the best approach to reassign a work item\task to a new owner without loosing the time spent by the original owner?

And likewise what is the best approach to defer a work item\task to a later sprint\iteration without loosing the the time spent on the original sprint\iteration?

I have explored the creation of a new item and having an over arching parent but this is too much overhead.

The best option I have come up with is creating a custom status in the process configuration data "reassigned" and "defered". When a task gets moved into this state a duplicate task could be created and linked to the previous one in a custom relationship.

Firstly is there a better option?
A process that the JAzz team uses when reassigning tasks?
Exisintg or future planned functionality that supports this?

Also... Is there a way of creating a trigger to automate the option that I described?

Appreciate your feedback and help!

4 answers



permanent link
Daniel Hatfield (312) | answered Apr 28 '10, 10:54 a.m.
On top of this if you break a task down into child tasks it appears the time spent does not roll up into the parent task. Is there a way to make this happen... similar for the way a story work item shows progress of time spent on children tasks?

permanent link
Jean-Michel Lemieux (2.5k11) | answered May 03 '10, 12:23 p.m.
JAZZ DEVELOPER
I have recently been working with a customer who is looking to roll out RTC and have JIRA in place today. JIRA has a way of people adding time spent to a ticket/issue. This means multiple people can work on an item.


The Jira work logging support allows you to update the task with an audit trail of who worked on the task and the amount of time they worked.

We have something similar that is supported, but maybe not as explicit. What you can do is tweak permissions on tasks to allow users on the same team to update the time spent on an item. When this happens, they add a comment for example "just finished the mock up". The history for the task will show the change in the time spent and a history of the activity by the different users.


What are the advantages of breaking up work items into multiple items with a parent item. There must be benefits that Team Concert provides from a reporting and planning perspective having this break down right?

Also what is the best approach to reassign a work item\task to a new owner without loosing the time spent by the original owner?


The main advantage is allowing you to assign the subtasks to different iterations and use them as placeholders for your planning exercise.

When you assign a task to someone else, the audit trail will contain the info about who updated the time spent, but you are correct that it's not "reportable".


And likewise what is the best approach to defer a work item\task to a later sprint\iteration without loosing the the time spent on the original sprint\iteration?
I have explored the creation of a new item and having an over arching parent but this is too much overhead.

The best option I have come up with is creating a custom status in the process configuration data "reassigned" and "defered". When a task gets moved into this state a duplicate task could be created and linked to the previous one in a custom relationship.


We have an action in the Eclipse client only (not in the web yet) which takes a task and moves the unworked portion to another iteration. This leaves a new task with the time spent, resolved, and an estimate updated as placeholder in the originating iteration and the original is moved to the new iteration.


Firstly is there a better option?
A process that the JAzz team uses when reassigning tasks?
Exisintg or future planned functionality that supports this?

Also... Is there a way of creating a trigger to automate the option that I described?

Appreciate your feedback and help!

permanent link
Michael Schneider (886) | answered May 03 '10, 12:54 p.m.
JAZZ DEVELOPER
Also what is the best approach to reassign a work item\task to a new owner without loosing the time spent by the original owner?


Currently, there is no direct way to reassign the owner while retaining the old owners time records. However, there's work underway: we plan to support time tracking for 3.0

In the meantime, you could use the continue work action Jean-Michel mentioned, as a work around:

- First, select the items you wish to reassign
- Then, use the continue work action to reassign it to another iteration
-> the original item is now closed, still owned by the original owner and containing the original estimate and time spent
- use a query to find the newly created work items by the "Continue Work Action" (query by the selected iteration and recently created by you)
- use bulk modification actions in the query result to reassign to the current iteration and the new owner.

----
MikeS
Agile Planning Team

permanent link
Michael Schneider (886) | answered May 03 '10, 1:04 p.m.
JAZZ DEVELOPER
On top of this if you break a task down into child tasks it appears the time spent does not roll up into the parent task. Is there a way to make this happen... similar for the way a story work item shows progress of time spent on children tasks?


It is rolled up in the "Progress" column of a plan. The estimate of a parent task can be set to any value and does not indicate the rolled up value (in case that parent task has work associated with it as well)

Please post additional details here if this is not what you see.

----
MikeS
Agile Planning Team

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.