Work Item Traceability
The traceability of the work items shows the relationship between them in Azure DevOps (ADO).
Intended for
Configuration managers, software engineers, release owners, scrum masters, product owners, and quality control managers.
Work item definitions and hierarchy
The key work item definitions are as follows:
The following image shows the hierarchy of the work items. User stories and tasks track work, bugs track code defects, and epics and features group work under larger scenarios.
System requirements and system epics
In PCP, product managers log business requirements into Decision Focus as system requirements. These system requirements are logged at a high level and need to be handled by multiple agile teams. The system requirements are replicated in ADO as system epics. Teams then derive their work items from the system epics. There can be multiple epics derived from a single system epic.
Work item traceability - bringing order to chaos
Linking work items to other work items gives a clear view of work item relationships and dependencies. It also helps to:
- Track dependencies, related items, and work hierarchies.
- Track which work items are tested by test cases and test results.
- Provide an audit trail of code changes and the supporting work items.
- Provide end-to-end traceability.
- Share information by linking work items to a network share, storyboard, or document.
The pre-defined link types in different colors provide valuable information about the relationship between work items.
Traceability - epics
| Epic type | Description |
|---|---|
| Epic (Enabler) | Epics are derived to build the necessary infrastructure or capabilities required to achieve the system epics. |
| Epic (Architecture) | Epics focuses on technical or architectural work that supports the implementation of system epics. |
| Epic (Test) | Epics describing the system substream test scenarios. |
| Epic (Product) | Product management epic represents a significant feature or functionality that aligns with the product’s strategic goals. |
Enabler and architecture epics owned by the system stream shall also have features / user stories derived from them to break down the work. The product owner identifies the need for new functionality from the system epic and derives the epics from it.
- "Area" shall be set to the affected product.
- "Iteration" shall be set to the "Root".
Traceability - features
The agile team decides to bring in a requirement, and the product owner ensures that:
- The epic is broken down into features for the development teams to implement the requirement.
- "Area" shall be set to the target release of the requirement.
- "Iteration" shall be set to the backlog of the development stream.
- A user story to implement the feature is created for the affected development team.
- "Area" shall be set to the target release of the requirement.
- "Iteration" shall be set to the affected team’s backlog.
- "Assigned To" shall be set to "blank" (the team assigns the story to a team member to work on).
At this level, product owners, architects, and configuration managers have significant roles in the agile team.
Traceability – user stories
The development team breaks down the feature into several user stories to implement it.
- "Iteration" shall be set to the sprint when the story is planned to be implemented.
- "Assigned To" shall be assigned to the team member responsible for the story.
The agile team, including developers, product owners, and scrum masters, contributes to this activity.
- Prioritizes the user stories and bugs.
- Follows up on the implementation and verification.
- Closes the user stories and bugs.
Traceability – tasks
The responsible developer / team member plans the implementation of the user story for one or many tasks.
- "Iteration" shall be set to the sprint when the task is planned to be done.
- "Assigned To" shall be set to the team member.
The check-in (changeset) shall be related to a task when changing code. When a component/product is built, "Integrated in Build" is filled in with the build ID defined in the build definition.
There is a script that can update "Integrated In Build" in "all" the parents to the check-in related task (task → user story → feature → epic)
- Each build that includes a change related to a feature, bug, epic, etc., updates the "Integrated In Build".
- "Integrated in Build" is not visible in all work item types but can be used in queries and reports.
- This script can be integrated with the build definition of a formal build.
Traceability – bugs
Product defects are usually discovered during development and testing, or reported by customers to our support organization. Anyone who finds a defect, or receives a defect report, should create a bug:
- "Found In Build" shall be set to the build ID of the product build.
"Found In Build" can be set as a link to the build execution or as a text field. The link is preferred because it is better integrated with build and release pipelines and allows multiple links. The agile team decides if a bug should be corrected. - "Area" shall be set to the target release of the bug.
- "Iteration" shall be set to the affected team’s backlog.
- "Assigned To" shall be set to "blank" (the team assigns the story to a team member to work on). The bug shall be related to a feature or epic.
- Test cases on the feature and epic verify and validate the bug. This allows us to prioritize the bug, follow up on the implementation, and verify and close the bug.
Traceability – document updates
Sources of document updates include Product Management and the process areas Requirements, Software and Hardware Development, Quality and KPIs, and Release. ADO is used as a document control plan (instead of a single-user Excel sheet) and provides traceability to features and epics.
- Multiuser environment.
- It is used for project documents, product documents, user documents, etc.
User stories can be used but don't have the specific document (document ID, document type, revision, etc.) and review fields.
Traceability - test plan, test suites, and test cases
For a description of test stages and levels, see Test Overview.
-
Test plan: For each development cycle and release, a test plan can be created and divided into different test suites; test cases are added to the test suites. Existing test cases can be reused in different test plans/suites. Copying or cloning the test cases is also an option.
-
Test suite: A test suite is a collection of test cases intended to test a software program to show that it has a specified set of behaviors. Static test suites can contain any type of test suite and are not based on specific requirements.
-
Test cases: The product test engineers develop the test cases using the information in the epics, mainly the acceptance criteria. If any issues are found during testing, they are reported as bugs for further investigation and corrections.