How to handle left over tasks in TFS [closed]

Question

What is the best approach to handle tasks and user stories that didn't make the end of the sprint in TFS ?

My approach:

• Set every task to 'Closed' with the right Reason substate. I copy this task + orginal estimate + remaining hours to Notepad.
• Remove the iteration from the user story (so that it will be on the Product Backlog again)

For the next sprint:

• Add the tasks from Notepad to TFS as new tasks, assign it to the right user story and set the user story to the current sprint.

This is just an approach. Do you have better ideas or suggestions ?

Bakunin

Answer 1

If you are truly doing Scrum, you will see the only important metric for any team is "Remaining Work". The thing is that many people are obsessed with metrics, statistics, data and loose track of the essence of Scrum.

So keep it simple. In sprint review, simply agree with the PO to when to complete the work and then assign the outstanding tasks to the agreed sprint.

If you want a bit of a productivity boost; then create a query of undone tasks and simply replace the iteration column value to the next sprint and publish back to TFS.

Mohair

Check! This is the way I really liked and evaluated during some sprints. We focus on remaining work, that's the true story. – Bakunin

Answer 2

There are two schools of thought:

1. Leave these and create new ones in the Product Backlog iteration (often the Team Project root). We would leave them and remove the points (for Velocity report), because they represent what our sprint was planned.
2. Update the iteration to the Product Backlog and deal with them as any other Story during the next sprint. (I would subscribe to this one).

Every team is different with the tasks. If you pick the story again in the following sprint, update the task iteration path and be done. If you don't pick it back up, I would remove the tasks so that you discuss how to deliver on the need in the context of the software as it exists when you do pick it back up. Leaving the tasks on a story for over a sprint has a way of giving us a false sense of security that those are still all the things necessary. I'd rather re-evaluation how we'll deliver on it.

Gigantopithecus

If you just update the iteration of the tasks, then the unfinished tasks will appear on the task board. So when you look at the iteration backlog of the previous sprint you see the user story with the finished tasks. When you look at the current sprint you see the user story with the unfinished tasks. – Traylor

Answer 3

We do the exact same thing you do, but instead of using Notepad, we simply copy the task into a new one & then assign this into the new iteration. By default, the copy-Task is linked to all work items that the original was, as well as the original task itself.
The older Task stays in the old iteration & gets marked as 'Closed'.

Shushan

Answer 4

Maybe i didn't get your problem right, but here is my opinion: The main idea of undone tasks is that the backlogitem/userstory isn't done. So after the sprint all backlogitems/userstories that are done -> new increment. If a backlogitem isn't totally ready then the whole backlogitem doesn't get delivered, even if its just a few tasks that are left. Just roll everything back (keep the code:) ) and finish the sprint. The backlogitem/userstory goes to the next sprint.

Creeps

Answer 5

Marking them closed, in my opinion, isn't necessary. Simply keep the remaining tasks, flag / tag them as unfinished, start a new sprint, and apply all tasks with that particular flag as being of the new/upcoming sprint (and if necessary, re-evaluate their times and difficulties).

Audiphone

Can you describe in more detail how you 'flag/tag' them as unfinished ? – Bakunin

Answer 6

It is a very common scenario, and we have something on our backlog to create a fit for purpose solution for this, but we have not prioritized it yet over other work.

If you think this is important, feel free to add the suggestion at user voice. We use that site in our prioritization: it is your chance to influence us

Ewald Hofman (TFS Product Group)

Traylor

We're reaching the end of our first TFS 2012 sprint today. So I'm looking forward to hear some 'official' advice on this. I guess we will just move unfinished PBIs and bug work items back into the product backlog and move them into the next sprint iteration when fit. – Dowski

Notice that my approach was done that way to keep track of 'old'/previous iteration backlog charts. When moving WI to the next sprint you lose the original charts view... – Bakunin