Question

Some bugs are found in released code by customers or whoever, other are discovered internally during development in a sprint for example.

So when looking at the backlog content for a release I do not know which bug fixes should be communicated to the customers and which is just internal information.

Are there any best practices for this? Do you use naming conventions or can the template be changed to better suit our needs?

Was it helpful?

Solution

This is how I deal with release bugs.

A bug is just another PBI and is added to the product backlog. The PO then triages the bug and orders it with other work as some bugs are critical whilst others can be for the next release and then others are low value and cosmetic.

From a coding point, I use a branching strategy for next release, production and service packs.

On the System Tab, of the defect I use the Found In Build to identify which build it was, e.g. dev, release, SP.

I then schedule it to be fixed in a sprint using the iteration field, as with any other PBI.

The challenge is that many teams battle with build numbers and builds, if this is the case you may want to add an additional field to the bug that indicates the branch to work in. And if you are paranoid, build a custom rule on that validates check-ins linked to requirements are on the correct branch (using the field).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top