Backlog Tagging Best Practices

In a recent article, we discussed the importance of backlogs. You may be wondering how to organize backlog items in TestTrack. You can use folders or custom fields as a way to "tag" or categorize stories, bugs, and other types of artifacts found in a typical backlog bucket. Following are some pros and cons of each method.

Folders

Pros

• Flexible, with ability to drag-and-drop items to different folders
• Better visibility from the UI, with easily understood hierarchical relationship
• Multiple TestTrack item types (defects, test cases, user stories, etc.) can be in the same folder

Cons

• Limited ability to look at prior categorization decisions because history is not tracked

Custom Fields

Pros

• Can be required, forcing new bugs or feature requests to be categorized by the submitter
• Finer-grained control over who can change a value
• Integrated change history to track past categorizations
• Can be changed in bulk (bulk changes are typically an admin-level function)
• If you're tracking quantitative data, a numeric custom field can be used to permit list window summing

Cons

• Each item type (defect, test case, user story) must define its own custom field for priority with a shared list of values

Sharing Custom Field Categories

If you decide to use custom fields, you can make reporting, filtering, and general maintenance easier on your team by sharing custom fields across item types. Here's an example of how the Persona field might be shared with requirements and story maps. One field, across multiple item types, makes maintenance and searching much more reliable.

Folders or Custom Fields?

The decision of whether to use folders or custom fields depends on how stable a particular categorization is. For prioritizing tasks, use folders. Business priorities change often and there's nothing easier than dragging a task from P1 to P2 with a couple clicks. For categorizing tasks, we typically suggest using custom fields. Given that categories tend to be more stable than priorities, custom fields are usually a better fit. For example, if there is a bug in your application's email engine, it's unlikely to migrate to another part of the application. You should only have to tag it once under Functional Area = Email. You can make those fields required, putting the burden of initial categorization on the submitter and, with few exceptions, not have to worry about it after that.