When should I assign an Iteration to a task in TFS 2010

Question

I am working on a project that is using the Agile template with TFS 2010 and I'm trying to decide when I should assign an Iteration to a task. At the moment I have a bunch of User Stories and these User Stories have been assigned an Iteration. I've then created Tasks for each User Story and linked them.

So, my question is should I assign an Iteration to the tasks even through the User Stories have already been assigned an Iteration? And what should I do about "general" tasks that are not really associated with a User Story? For example, I could create a task that involves updating references for controls or performing a code review. Should these be assigned an Iteration and is it worthwhile managing two types of tasks, i.e. those assigned to User Stories and those that aren't?

Answer 1

Iteration is to be set when your team is committed to work on these tasks. If after reviewing the tasks you decide to defer some, then set the iteration to a later sprint.

An excerpt from MSF for Agile Software Development v5.0 on MSDN:

You can assign the area and iteration fields to most work items based on a process template for Microsoft Solutions Framework (MSF). You specify values for the area and iterations fields when you create a work item or during a review of the product or iteration backlog. If you defer a work item to a later time, you should change its iteration accordingly.

And from the work item definition guide:

In the Area and Iteration lists, click the appropriate area and iteration, or leave these fields blank to be assigned later during a planning meeting.

Regarding the general tasks, there are special work item for this such as Issue (Agile) and Impendiment (Scrum).

Answer 2

You should definitely check out this resource, it's a presentation by A.Bjork that presents with a way to deal with what you 're after.

We tend to assign UserStories to future Iterations, and before an iteration starts, at the time 'planning poker' takes place - we generate & assign the Tasks to the team.
Doing so is vital, for TFS to keep a proper tracking of your efforts: the only Work Item where 'hours' are inserted is the type 'Task' - so this is what feeds the Burndown charts that show how effective you work.

If you add another Task to a team-member during the sprint, that would be perceived as 'unplanned work' by TFS (simulating an interruption!) and will mess up the calculations for your Team's velocity.

Try breaking your long-running Tasks into smaller ones, that shall fit into each sprint. At worst, for example if you have a huge refactoring Task, you can make several child-Tasks assigned to each sprint and then have the umbrella-Task assigned to the last iteration - where your refactoring is completed.

Apart from time-tracking (which is solely based on Tasks) you need to also add into your iteration backlog all other work items that are important for the sprint, so you 'll be able to track in the future when each Issue, User Story etc was considered.