Using "Continue work in" in customized process
Hi,
We have a customized process (based on the standard SCRUM) where we have changed / added some work item types and changed the flows.
I'm wondering how the "continue work in" is implemented. We have a weird behavior in our process template where a "continue work in" action on a task will but it in "New" state instead of "Done".
I figured it might be some required property, so I disabled all required properties, but it still defaults back to "New" and then creates the related task in the selected iteration for continuing work.
I have thoughts like:
* it might be that we don't have the state transition any more. Maybe "continue work in" looks for or some id that is not present anymore.
* maybe the action looks for a state that is not there anymore, because we customized the process.
It would be easier, if I knew exactly what "continue work in" does "under the hood".
Anybody knows???
We have a customized process (based on the standard SCRUM) where we have changed / added some work item types and changed the flows.
I'm wondering how the "continue work in" is implemented. We have a weird behavior in our process template where a "continue work in" action on a task will but it in "New" state instead of "Done".
I figured it might be some required property, so I disabled all required properties, but it still defaults back to "New" and then creates the related task in the selected iteration for continuing work.
I have thoughts like:
* it might be that we don't have the state transition any more. Maybe "continue work in" looks for or some id that is not present anymore.
* maybe the action looks for a state that is not there anymore, because we customized the process.
It would be easier, if I knew exactly what "continue work in" does "under the hood".
Anybody knows???
Accepted answer
The thing to keep in mind is that "continue work item" is just a way to
create a new work item that captures the "partial work" that has been
completed, and then changes the "planned for" and "estimate/completed"
fields of the existing work item.
But I agree that this new work item for the partial work should inherit
the priority and parent fields of the original work item. I'd suggest
filing an enhancement request.
Cheers,
Geoff
On 12/14/2011 6:53 AM, cruiser wrote:
create a new work item that captures the "partial work" that has been
completed, and then changes the "planned for" and "estimate/completed"
fields of the existing work item.
But I agree that this new work item for the partial work should inherit
the priority and parent fields of the original work item. I'd suggest
filing an enhancement request.
Cheers,
Geoff
On 12/14/2011 6:53 AM, cruiser wrote:
Hi all, I still mess around with the functionality described above
(using "continue work in" to move work from one sprint to
the next).
Does anybody know why the following happens to the
"original" task:
1. priority is set to "unassigned".
2. links to parent work item is removed.
The (2) is the worst one, becuase the original work item is then
removed from the accumulated time spent in the parent work item.
Does anybody know why this happens?
4 other answers
Ok, so I found out that "Continue work in" (in RTC 2.0.0.2 IFIX 05) seems to execute following actions:
1. sets priority to "Unassigned".
2. executes the actions Complete: .
If the transition New -> Done is not possible anymore because of a customized flow, then this functionality will fail.
1. sets priority to "Unassigned".
2. executes the actions Complete: .
If the transition New -> Done is not possible anymore because of a customized flow, then this functionality will fail.
Hi all, I still mess around with the functionality described above (using "continue work in" to move work from one sprint to the next).
Does anybody know why the following happens to the "original" task:
1. priority is set to "unassigned".
2. links to parent work item is removed.
The (2) is the worst one, becuase the original work item is then removed from the accumulated time spent in the parent work item.
Does anybody know why this happens?
Does anybody know why the following happens to the "original" task:
1. priority is set to "unassigned".
2. links to parent work item is removed.
The (2) is the worst one, becuase the original work item is then removed from the accumulated time spent in the parent work item.
Does anybody know why this happens?
Comments
we have now upgraded to v3.0.1 and we are still having problems with using "Continue work in". Our problems can be summed up:
- Priority on work item staying on the old plan is set to "unassigned".
- Links to parent is disconnected
- This functionality disallows required fields (as Priority) in state "done" because then the "continue work in" process cannot save the work item in state "done".
Does anybody have any comments on this? Else I will now create an RFE.
Morten - were you able to create the RFE? Breaking the parent link creates orphans when using "Continue Work in" is a big problem - I would consider it a bug not a feature enhancement. For example, the current behaviour prevents any meaningful information from being viewed at the story / epic level when actual Time Spent in "child" tasks is lost when they are orphaned.
I haven't found where to enter requests to address issues like this or I would do it myself. I haven't found any evidence that this has changed in later releases of RTC.
I haven't found where to enter requests to address issues like this or I would do it myself. I haven't found any evidence that this has changed in later releases of RTC.
Hi Morten,
Greetings!
In 5.0, the Parent link is retained. It was fixed through :
Continue work in" functionality in Plan view on Task level missing a parent/child on the newly generated WorkItem to the Parent of the Source WorkItem (300364)
Further in 5.0, I see that any Required Attributes (including Priority and Tags) are copied over fine.
hope this information/observations helps.
Greetings!
In 5.0, the Parent link is retained. It was fixed through :
Continue work in" functionality in Plan view on Task level missing a parent/child on the newly generated WorkItem to the Parent of the Source WorkItem (300364)
Further in 5.0, I see that any Required Attributes (including Priority and Tags) are copied over fine.
hope this information/observations helps.