Moving PBI with tasks to other sprint when tasks are not shown

Edit Subject

You are right, only visible child items are moved with the parent item when it is dropped onto another iteration or area. I'll make sure the team discusses this behavior. Thanks for the feedback!

Yes, this is a problem. All child items should be moved to another iteration as long as they are not in the 'Done" state, whether or not they are visible.

Is there any indication when this will be fixed?

This has yet to be prioritized but I will make sure it gets some attention. Thanks!

This would be a helpful feature. When we move a story out of a sprint we need to then manually open up each task and change the iteration. It happens enough to be a noticeable burden.

Yes, and (unless I'm missing something), you have to add a new "cont'd" PBI to track them in the new sprint.

dejungle: No you don't have to create a new PBI (cont'd) to track them. They are still linked to the original PBI. It is just that because they were not visible when the parent PBI was moved they are level in the previous iteration and you have to go manually update them to the new iteration.

I would think this should be fairly straightforward to implement as you just go look for child items (or link types as defined in the config file) and update all items with the new iteration or area. This continues to be a serious pain point for the teams when doing sprint management.

This is a constant headache for us, leading to stray Tasks all over the place. Causes a lot of confusion on an ongoing basis.

This is currently being discussed for a possible inclusion in the next release.

We got used to this behavior, but with the 3.14 version it got worse. We are now unable to move tasks with the state done together with their parent Work Item to another iteration, regardless the state of “Hide Resolved Work Items”.

The debate is still active. The reasoning behind this is that done items should not be moved out of their sprints. I'll try to push this again in the upcoming backlog maintenance.

I agree with Louis on this - tasks that are marked "done" should stay in the iteration where they were marked "done". Active tasks should move with their parent even if they're not currently visible.

The problem is, the hidden work items may be hidden because they belong to another team, or for many other reasons. I don't think tasks that are not done and not visible should always move with their parent no questions asked. We're thinking we'd need some kind of feedback about what will be moved, what cannot be moved (done items) and what can be moved (hidden items, maybe a way to select them).

When we have Product Backlog Items that is not done in a sprint, we have to move it in to the next sprint. To get a picture of the state of this PBI we like to see all the tasks underneath it, including those who are done (in the previous sprint).

I cannot see why it’s written in stone that it’s illegal to move a done task? It does not affect the sprint backlog burndown in the current sprint.
With the current behavior (UT 3.14) we have to open the PBI and look at all its links (child) to see the tasks left in the previous sprint.

In Scrum the product backlog burndown shows the PBI Story points that is burned in each sprint. If we have a “8-pointer” in “sprint 1” that is not done, we don’t burn any points down in that sprint. When it’s done in the next sprint we get credit for all the 8 points.

To keep track of witch sprint the task was done in should be of lesser concern than to see a PBI /Bug with its entire tasks in the same sprint.

If you reestablish the behavior from ver. 3.13 where work items that are filtered out stays, users can make their own choice.

To the question of what to do with the hidden work items, you could promt the user with the message "This work item has hidden child, are you sure you want to move it?" Yes/No

I think this is a valid point, although I'd like to point out that nothing's ever set in stone. This issue has been polarizing people ever since we started discussing it, even internally with our other teams. This is why we are trying to come up with an elegant solution where user feedback would be requested when there is a possibility of work items being left behind.

I agree it's not set in stone. Each user/team has its own particular way of working. For my team, the most natural thing is to have the Done tasks stay in the iteration where they're completed, and the open tasks to move to the current iteration with the PBI, but on the other hand, I don't think what happens to the Done tasks is that important - the open ones are what's important.

Regarding the search for elegant solution, I think if there's simply a user setting to control whether to change the iteration of a child item when the parent item changes, even if the child item is hidden, that should do it. If there's another option to control what happens with tasks that are Done, that should take care of Petter's request.