Introduction
In Scrum, the product backlog is the list of requirements for the system. In this article we are going to see how the Product Backlog Items (PBIs), test cases, tasks and bugs are linked. This article is a continuation of the previous article (Scrum with Team Foundation Server 2010 - Product Backlog).
Linking artifacts
As per the diagram below, once PBI details are specified by the product owner:
- The team defines tasks and test cases from PBI.
- If the test case or task fails, the team creates the bug(s).
- Even bugs can be created from PBIs.
- If a task, bug or PBI is blocked then an impediment is created.
Note: Impediments are obstacles to progress.
Next we will explore the following in detail:
-
Linking PBIs to Test Cases
-
Linking Bugs to Test Cases
-
Linking PBIs to Bugs
-
Linking PBIs, Tasks and Bugs
-
Linking PBIs to Tasks
-
Linking Tasks to bugs
-
Linking Impediments to PBIs, Tasks and Bugs
Linking PBIs to Test Cases
Once PBIs are created, the acceptance criteria should be well defined. Otherwise the product owner and team may have different views about the feature and it's definition of done. Test cases are more specific than acceptance criteria and are separate work items. Test cases can be created, assigned and tracked over time whereas an acceptance criteria is part of the PBI. 
As shown below, PBI is tested by a test case, and a test case tests a PBI.
One can create a test case from a PBI by setting the Link Type to Tested By, rather than Tests.
Linking Bugs to Test Cases
Bugs are discovered when running manual tests or unit tests. Linking bugs to test cases, ensures that the test cases are heavily exercised for validating the PBIs and that the team is fully involved in the test cases.
As per figure below, PBIs are tested by test cases, which in turn may have associated bugs.
As shown below, one can create a new bug and link it to test cases using a child relationship.
Linking PBIs to Bugs
Bypassing the test case and linking the bug directly with PBI, one can count and track quality at the PBI level. As shown below, in terms of the relationship between a bug and a PBI, a bug is a child of a PBI.
To measure quality, in a Test Driven Development (TDD) at unit and acceptance level testing, the test cases are used. Here test cases, defined for each PBI, are populated with automated and manual tests. Whereas if you are using TDD but not necessarily defining all the artifacts for tracking and running tests within TFS, then linking bugs to PBIs is more appropriate.
As shown below, one can create a new bug and linked it to PBI using a child relationship.
Linking PBIs, Tasks and Bugs
A task is the smallest unit of work. Each person on a software development team has a task list that he or she uses to organize and prioritize his or her work.
In Scrum, you use tasks in two ways:
-
to assign and track work associated with a PBI.
-
to assign and track work associated with bugs.
Tasks associated with PBIs represent things you have to build, while tasks associated with bugs represent things you have to fix.
The figure below shows the relationships among a PBI, a task, and a bug. The PBI is the parent of both tasks and bugs, which are, by definition, children of PBIs. By defining a task from a PBI, you're defining the work to implement the PBI. By defining a task from a bug, you're defining the work to fix a bug.
Linking PBIs to Tasks
As shown below, one can create a new task and link it to PBI using a child relationship.
In the following figure, the list is shown having PBI with associated tasks.
Linking Tasks to bugs
During each sprint, you create, find, and fix bugs in the software. In order to track the nature, severity, and impact of each software bug, you create bug items in TFS. Each bug item in TFS stores the essential criteria about the bug. This includes:
-
the steps to reproduce the bug.
-
environmental data such as builds and server and desktop configurations.
-
the acceptance criteria for fixing the bug.
As shown below, one can create a new task and link it to a bug using a child relationship.
At a minimum, you should create one task for each bug. For simple bugs, the task will be assigned to the person who is responsible for fixing it, which is normally the same person assigned to the task.
In the following figure, the list is shown having:
Linking Impediments to PBIs, Tasks and Bugs
In a nutshell:
-
PBIs define the features to be built into a product.
-
Tasks define the work necessary to implement them.
-
Test cases are used to verify quality.
-
Bugs track problems as they're found in the product.
Sometimes things don't always go according to plan. Impediments are obstacles to progress. Dependencies among technical components, dependencies among team members, and unclear requirements are three of the most common impediments. The Scrum Master's primary job is to remove impediments that are blocking or slowing down the team.
As per figure below:
-
PBI may be blocked because the product owner needs to get information from someone external to the team
-
A task may be blocked by a bug in an underlining component or third - party control.
-
A bug may be blocked, maybe pending environmental resources required to adequately reproduce the bug in a lab.
As shown below, one can create a new impediment and link it to a task or PBI or bug using a child relationship.
Conclusion:
In this article, we have seen how PBIs, Tasks, Bugs, Test Cases and Impediments are linked to each other in Scrum using Team Foundation Server 2010.