How to UnCommit to a PBI [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

I have a PBI that is Committed. Linked to it, I have 6 Tasks. Two are finished and Four are not even started.

It turns out that we won't be finishing this, but might pick it up in a later sprint. We will not be moving it to the next Sprint.

If I move the PBI into the Backlog, the tasks are orphaned in my current Sprint.

If I move the Tasks into the Backlog, I really have no clue where they go... but the true issue is that whenever we pick up that PBI again, we'll have to somehow remember that it was an UnCommitted PBI, and will have to check the Links then pull the Linked Tasks with it.

Is there a better way? I'd like to keep the Done tasks in the Sprint they were Done in, and pull the ToDo Tasks anywhere the PBI goes.

Answer 1

In Scrum, a product backlog item is done, or not done. It's a binary state. If it's not done, move it back to the product backlog, re-estimate it and let the product owner re-order it. The tasks are candidates for being discarded. Here's why:

The product backlog item that you return to the product backlog may not be worked on in the next sprint, may not be worked on for several sprints or may never be worked on at all. All these actions are likely to affect the content of the tasks.

For example, team composition may change and so the way of delivering the functionality for the product backlog item may change. Certainly, the estimates for the tasks would change.

When discarding the tasks, consider removing the code for the tasks that you describe as being finished. You want to keep your code base lean and easily maintainable.

Finally, when you talk about orphaned tasks, I'm gaining the impression that you're using a software tool to manage your product backlog. Is this the case? If so, I'd encourage you to consider the problem as a Scrum issue first and foremost. This may then highlight issues with your software tool which you can address as a separate issue. In other words, don't let the software tool drive your adoption of Scrum.

Answer 2

Uncommit a PBI = move it back to the backlog. Once the PBI has been started, you can't really uncommit it by definition as you've already finished third of it.

What you can do is either split it by creating a successor PBI (with a helpful title suffix that will remind your it's less important such as "Feature ABC - phase 2 - minor improvements") and relink the To Do tasks to it. Keep the Done tasks linked to the original PBI.