11 comments

Add a comment…

Sign in

prestine

Your email address

Check!

invalid email

(thinking…)

Reset

or sign in with

• 
• 

UserVoice password

Forgot password?

Create a password

Your name

I agree to the terms of service

Signed in as (Sign out)

Close

Close

Post comment Submitting...

• Staffan commented  ·  April 15, 2013 8:22 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  I, like many others, handle Bugs like a Task, and not a PBI. As Geert says, there is a way to add Bugs to the Task Board. However, there is a major drawback with that solution and that is that only child WI's are shown on the Task Board. A Bug should generally be linked to a Requirement as 'Affects' and not as a child. A Bug can affect more than one Requirement, but you can only have one parent.
  Also, if you add Bugs as children, then the parent Requirement will be associated with the next build after the bug has been resolved and that will make false assumptions.

• Geert Verhoeven commented  ·  December 10, 2012 1:16 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  Apparently this is already possible. See the following link for a how to: http://msdn.microsoft.com/en-us/library/vstudio/hh739073.aspx#feedback

  Just added Bugs to the Product Backlog without a problem. Make sure that you add all required backlog fields to the work item that you want to include in the product backlog. See the "AgileConfiguration.xml" for the required fields.

• James commented  ·  November 27, 2012 7:30 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  Also feedback items.

• Brett Richard commented  ·  November 13, 2012 9:53 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  This comment is a year old now, but I think it still needs more thought. The Task Board view gets very noisy when multiple bugs are entered for a backlog item. The bugs provide good tracking information, but the ability to hide/remove from the task board view would be helpful.

• Anonymous commented  ·  October 29, 2012 8:11 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  See how Urban turtle handles bugs. Very flexible

• Anna commented  ·  October 2, 2012 8:21 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  Hi, this is something we would also need, generally we don't need to add a task for each bug, it seems overkill for tiny bugs to have a bug plus a task. So I've added the field for 'remaining work' to the bug itself, however these do not update the burndown, which is a shame.

• Christian Mogensen commented  ·  September 2, 2012 12:32 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  We put bugs into the backlog, but we don't have hours remaining on a Bug. If a bug is larger than an hours work, we use tasks under the bug to record estimates.
  If you have a lot of bugs assigned, then this shows up as lower burn-rate in the sprint.
  i.e. you are doing less planned work because you are fixing past mistakes.

• Ricardo Costa commented  ·  July 9, 2012 9:35 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  I think for us it would be better to have bugs as tasks of a major "Bugs" backlog in the current sprint instead of appearing alongside other backlog items.

• Job Schepers commented  ·  March 27, 2012 7:07 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  This also get my vote. Currently with TFS 2010 we handle bugs about the same as tasks. If a tester finds a bug on one of the backlog item during the sprint, that bug will be added as a child of that backlog item. Additional the testers work with test cases and they are also handled the same as tasks. We currently use Urban Turtle which shows a clear color distinction between the items.

• Simon Kavanagh commented  ·  March 12, 2012 7:37 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  This is also something I look for in the preview of Team Foundation services.
  If Im testing a Story and it fails then I'll generally not make a Bug. I might make a task, or I might just chat to the developer.

  But if Im doing exploratory testing or testing a completely other story then I would like to be able to put a bug into the backlog. Similarly if a bug comes in from support department.

  This is all well and good but how do I get these bugs into a Sprint and on the Board?

  When I do Sprint Commitment, I want to be able to allow a team to commit to 3 Storys and 2 Bugs (for example). I can do this but the Bugs are not visible on the board.

  Similarly if a Critical Customer Error is reported mid-way through the Sprint I should be allowed to put this into the Board also (understandably this migh break commitment, but these should be rare).

  In short: Bugs and Stories should be shown as "parents" with Tasks underneath.

• Neo commented  ·  February 14, 2012 6:23 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  Hi, I would expect bugs to impact the overall burndown, just like regular task - so you could put remaining hours on the bug form. Currently as a work-around we are making a task for every bug, so that is affect burndown and show on board. You could also think of how to show tasks on the board - maybe they can have another color or border? Sometimes we have more than one taks thats solves the bug, yet in 95% of issues there is only one task which is a copy of bug item.
  I expect bugs to appear alongside tasks, yet this should be optional. Sometimes you just don't want to have then visiable.