Bugs - Do you know how to handle Bugs on the Product Backlog?

Last updated by Tom Bui [SSW] 10 months ago.See history

Bugs that are introduced and found because of the current work in the Sprint are included in the Sprint and estimated immediately so the burndown remains accurate. All other bugs found independent of the work on the current Sprint are placed on the Product Backlog.

See Do you know when to create bugs? for detailed information on identifying when something is a bug, and when to just fix it.

Using the Agile process template

In the Agile template, you can't assign Story Points to bugs, meaning that they will negatively impact on Sprint velocity.

Bugs found that are independent of the work on the current Sprint are placed on the Product Backlog as a work item “Bug”. The product Owner then ranks the Bugs with priority amongst the User Stories. Bugs cannot have Story Points allocated to them so User Stories need to be created with Bugs as Child Work Items. This is only done when the PO has prioritized the Bug and the Bug is likely to make the next Sprint. At the Planning Meeting, the PO elects which Bugs are to be included and new User Stories are created to group them appropriately with due regard to Severity and Stack Rank. Once the User Stories have been created, The Team estimates the Story Points for each one; the Product confirms User Stack Rank and the Sprint Backlog is planned as normal.

This process:

  • Works around the problem of Bugs not having Story Points
  • Allows Bugs of the same rank to be sensibly grouped together
  • Prevents arbitrary groupings of Bugs which cannot be properly ranked
  • Follows the estimate just-in-time philosophy of Scrum
  • Prevents small Bugs taking up a whole Story Point

Using the Scrum process template

In the Visual Studio Scrum template, bugs are just another PBI and you can assign a business priority and an effort estimate in Story Points. Bugs that make the cut for the next Sprint can be broken down into tasks and estimated as required.

As bugs from previous Sprints are just PBI’s, the PO agrees to a list of bugs that will be fixed in the current Sprint.

The team just fixes any new bugs they introduced in the current Sprint.

If the team finds bugs due to functionality accepted in a previous Sprint they log it as a PBI and will complete the fix in a future Sprint, unless it is a critical bug, in which case they raise it as an impediment to the current Sprint to the PO.


  • Small bug – Text on a label is spelled incorrectly
  • Big bug - There is an error thrown when transitioning from page 1 to page 2 when you hold down the Ctrl key

2016 02 08 12 02 29
Figure: Bugs can be added "out of Sprint" directly into the Product Backlog in Azure DevOps (was TFS)

The Visual Studio team provides good guidance on managing bugs in VSTS

Adam Cogan
Martin Hinshelwood
Eric Phan
We open source. Powered by GitHub