Hi Glenn,

top level work item types are described here:http://jazz.net/library/article/201.

Top-level work item types are used to track work typically done in several smaller execution items.

Looking at it in my test repository seems to support your guess that the continue work in depends on the work item being an execution item for the menu entry to show up.

Does this have something to do with the fact that a Story is a 'top level work item type.' What exactly does that mean: 'top level work item type'?

Hi Ralph,

We have this same "issue". We have a Story and the team plans it for say Iteration 4. But then they don't complete it so they need to move it to iteration 5. However, we have our story points at the story level, and we'd like to have a way to "take credit" for the work that was completed in iteration 4, which looks to be similar to how the Continue Work In seems to handle tasks ... a completed task in iteration 4 with the amount of work done, and then the original task in iteration 5 with the "remaining work".

So, are there any options here? Can I not make a "Story" a top level work item type" and then be able to Continue Work In with a Story also? If so, what downstream impacts would that have (as in, what will not longer work properly if a Story is not a TLWIT)??

Susan

Hi Glenn,

top level work item types are described here:http://jazz.net/library/article/201.

Top-level work item types are used to track work typically done in several smaller execution items.

Looking at it in my test repository seems to support your guess that the continue work in depends on the work item being an execution item for the menu entry to show up.

Does this have something to do with the fact that a Story is a 'top level work item type.' What exactly does that mean: 'top level work item type'?

Hi Susan,

if you have child task work items, the effort for those would be tracked when closing them. Another option I can see would be to duplicate the story, split the story points and close the initial story you finished in the iteration. I think this is how it is intended to be done. One thought, not being able to split up the work such that it can be done in an iteration is something you want to see in the burndown - so that you can try to split better next time.

Maybe you want to discuss that with development on a work item. Not sure how this could be implemented.

Ralph

Hi Ralph,

We have this same "issue". We have a Story and the team plans it for say Iteration 4. But then they don't complete it so they need to move it to iteration 5. However, we have our story points at the story level, and we'd like to have a way to "take credit" for the work that was completed in iteration 4, which looks to be similar to how the Continue Work In seems to handle tasks ... a completed task in iteration 4 with the amount of work done, and then the original task in iteration 5 with the "remaining work".

So, are there any options here? Can I not make a "Story" a top level work item type" and then be able to Continue Work In with a Story also? If so, what downstream impacts would that have (as in, what will not longer work properly if a Story is not a TLWIT)??

Susan

Hi Glenn,

top level work item types are described here:http://jazz.net/library/article/201.

Top-level work item types are used to track work typically done in several smaller execution items.

Looking at it in my test repository seems to support your guess that the continue work in depends on the work item being an execution item for the menu entry to show up.

Does this have something to do with the fact that a Story is a 'top level work item type.' What exactly does that mean: 'top level work item type'?