Do you have to create a TASK for every BUG in TFS (Cloud) to track time?

Question

Using TFS Cloud (myproject.visualstudio.com), there are no Estimated, Completed, Remaining fields to add time to a bug. Do we really have to create a TASK work item basically called 'fix - bugname' for every bug, just to log how long each took to fix?

I appreciate on larger bugs this makes sense, but some are spelling mistakes or other minor problems.

This then doubles the number of work items in lists for all?

any suggestions?

Answer 1

Well, having looked into this, the quick answer is yes.

The benefits of doing so are simple. A TASK is the 'smallest' thing you can do in TFS, and it is always assigned to one person.

Given this, by creating tasks to do the 'work', you can at least see who did the work and account for it (without looking at the history of an item).

You can also 'bounce around' the assigned to for the actual BUG, e.g. to get someone else to verify it, or leave it assigned to whoever 'owns' that bug, while fixing it can be assigned to others (the tasks).

Answer 2

If you are using Agile or CMMI template the bugs will not appear on the task board.

Ideally, you need to create tasks to represent the work that you or team members are doing. For instance you need to create development task for fixing the issues and a QA task for testing.

Also you should keep an eye on the statuses of the bug in parallel to the task. i.e. if the developer is working on the fix the bug should be assigned to the Developer and it should be Active and the development task also should be active as well.

Once the development work is completed the the developer can close the underlying task and Resolve the bug and assigned it to QA for testing. If everything goes well the test engineer will close the testing task and at the same time he/she should close the bug as well.

Answer 3

Technically yes. What we've decided to do (purely for simplicity and not to bog us down with even more user stories in TFS) is we create one user story per sprint and name it: "BUGS - SPRINT#". Under that we will have tasks that track the work/time spent on bugs.

We also name the tasks by category. For example, if there is a bug in the UI, we name it (example) UI - arrows not reappearing.

Not sure if this is the best way to do it, but it accomplishes effort tracking and keeps TFS clean.

Answer 4

I take it that you are using the "Microsoft Visual Studio Scrum" template. The fields in the work items vary based on the template you are using.

For bugs in the Scrum template, we usually cover the effort in the "Effort" field.

Answer 5

We are Using Visual Studio 2012. This is the way we are handling this situation. We have created a user story “ Resolving, Re-testing bugs.” Every iteration developers who have to fix bugs create a ONE task for all bugs. The developer adds comments to each and every bug resolved, and update time accordingly. QA person also adding a ONE task for the iteration for re-test bugs. QA person update his task accordingly for each and every bug. All Developers and all QA personal create child tasks for the same user story.