Vivid Trace 1.4 Solution Guide
This document outlines general practices and topical solutions for implementing traceability with Vivid Trace and Jira. We define traceability as:
traceability noun The quality of being able to trace the progression of the materials and units of work that ultimately produce an output or deliverable. In Jira, traceability enables us to relate i.e. requirements with design decisions, implementations, and test case results by following paths formed by relationships between issues (the units of work).
These solutions are proposed starting points that you can use and adapt to your situation, be it software development life cycle (SDLC), application life cycle management (ALM), ITSM/ITIL, or customer support and help desk scenarios. While the figures in this document are abbreviated, your data sets are probably large. A strength of incorporating traceability into your systems and workflows is in empowering you to process larger volumes of information with vastly greater speed.
You can get ideas on how to beneficially apply traceability just by browsing the list of topics in this document.
- Traceability Implementation Checklist
- View an Issue Dependency Graph
- Graph Exact JQL Query Results
- Trace Requirements to Implementations and Tests
- Conduct Change Impact Analysis
- Embedding Traces in Confluence Pages
- FDA Medical Device Software Traceability Analysis
- Find Unblocked Issues
- Identify Blocking Issues
- ISO 15504 SPICE Compliance
- Monitor Support Request Chain of Events
- Scan for Prematurely Resolved Parent Issues
- Scan for Completed Tests of Unfinished Implementations
- Scan for Escapee Issues
- Scan for Excessive Aggregation of Issues
- Scan for Non-Blocking Issues with Blocker Priority
- See All Issues in Jira
- Watch Issues in a Graph
Prerequisites: Familiarity with Issue Relation Graphs. Familiarity with the Trace Studio. Some knowledge of JQL, Atlassian's Jira Query Language for searching for issues. Awareness of Vivid Trace's JQL functions.
Range of Traceable Project Artifacts: The Vivid Trace proposition is traceability between project artifacts, currently defined as issues inside a single Jira instance. Source code commits, test case information, Confluence objects, issues in multiple Jira instances, and other project artifacts are slated to come into direct range in ensuing releases during (see Vivid Trace Product Roadmap).
Traceability Implementation Checklist
Use this checklist as a guide to implementing traceability. If you would like assistance, contact Vivid Support.
- Traceability Information Models Define your traceability goals. Agree on what information is necessary and how it should be structured in traceability reports to be useful to team members, other stakeholders, and/or regulatory authorities. Agree on how to model traceable project artifacts in terms of issue types, issue fields, and which projects they will live in. You might be using Jira add-on tools that provide task-specific idioms, such as for requirements management and test management, which already provide issues, issue fields, and relations that can be incorporated into the tracing and reporting strategy. Agree which relation types to use between project artifacts and on the interpretation of each. When thinking about how items should be related, consider the idioms that your Jira system offers and that your teams are using.
- Decisions Determine which portions of information will be: Managed in Jira, synchronized with or mirrored into Jira from other systems, and housed outside of Jira. Decide how to display issue and relation information in trace results. Decide how project artifacts will reference each other within, straddling, and outside Vivid Trace's traceable range. Decide how to preserve the referential integrity between artifacts in order to produce accurate traceability analyses.
- Team Pre-Flight Stakeholders and participants buy in to the traceability goals and the measures required to implement them. Set up Vivid Trace in your Jira system (See the Deployment Readiness Checklist). Prepare the projects that are involved: Project configuration, issues, and issue fields. Prepare the issue link types and other relations that will represent relations between project artifacts. Project administrators know how to adjust Vivid Trace project configurations. Team members know to properly manage issue data and relations. People who will conduct traces are capable with the Trace Studio and its prerequisites. Create initial drafts of your saved traces in the Trace Studio.
- Recommended Practices Maintain issue relations at the time of artifact creation and work. Although Jira offers some conveniences surrounding its Sub-task feature, such as time tracking summation, Vivid recommends that you avoid and even disable the feature altogether, if possible. Instead of modelling an issue as being subordinate to another issue by way of a special-cased Sub-task issue type, model the relationship using Jira's premier idiom for modelling relationships between issues: issue links. Create a generalized issue link type to model work breakdown and superior/sub-ordinate relationships. For example, to model a parent and sub-task relationship, create a new issue link type named "Sub-task" with outward description "sub-task" and inward description "is sub-task of". Thus, with this proper abstraction, you'll be liberated to model multi-level decomposition of requirements, user stories, implementations, and nearly anything else with the utmost flexibility. See the Product Roadmap regarding replacements for some of Jira's own sub-task convenience features. Prefer tracing criteria that is too wide rather than too-narrow to avoid costly omissions. Give names to saved traces that help you correctly and quickly identify them in the Trace Studio. Validate the trace criteria of a saved trace before using it to create reports. Inspect the resulting trace data for errors and omissions before relying on the results. If the trace data does not properly cover the traceable items then the tracing criteria may need adjustment, and missing and erroneous trace data must be remediated. Ensure that any modifications made to the saved traces and the Traceability Information Model are agreed upon, saved, and communicated. Generate trace reports meant for sharing from freshly-loaded, unmodified saved traces. This practice promotes reproducibility of the reports and improves the likelihood that decisions are based on accurate reports. Judge a compiled report as to whether it objectively demonstrates traceability among the desired items as agreed.
View an Issue Dependency Graph
You can use this method to immediately view the issue dependency graph for an issue, several issues, or the results of a JQL query. In the Trace Studio, just input one or more issue keys (separated with spaces and/or commas) or a JQL query into the Seed issues and press the Enter key to run the trace. You can edit the seed issues as often as you like, pressing Enter after each edit to re-run the trace.
Start with a new trace in the Trace Studio and apply the following changes to its configuration:
| Seed issues | Issue keys or JQL query |
|---|
Issue dependency graph illuminating all of an issue's dependencies. This dependency map was instantly and automatically generated on live data by tracing the issue key MD-51 in the Trace Studio.
Explanation: The Trace Studio accepts issue keys or the results of JQL query and uses them as seed issues to run a trace. When you first started a new trace, the Trace Studio was set to its default configuration where all issue relationships in all directions are enabled and at unlimited distance. This resulting trace configuration (the default configuration plus your seed issues criteria) produces a full dependency graph.
Going Further: The resulting trace is a good starting point for examination, and for experimental investigation and refinement of the trace results by way of adjusting the various trace settings. To visit issue detail pages for particular issues, instead of clicking on issues to navigate to them, open issues in new tabs so that the web browser doesn't navigate away from the trace causing you to lose the trace configuration. Add issue fields to the Issue Field Layout to understand more about the dependencies. Experiment with the Distance, Issue Link Types, and other settings to improve signal-to-noise in the graph. Explore the other entries in this document to see what else is possible.
Graph Exact JQL Query Results
To graph the exact results of a JQL query without expanding the trace beyond the query results, simply use the JQL query as the seed issues in the Trace Studio and trace at a distance of zero.
Start with a new trace in the Trace Studio and apply the following changes to its configuration:
| Distance | 0 |
|---|---|
| Seed issues | JQL query |
Explanation: With the results of JQL query being used as the seed issues, setting the distance to zero instructs the tracing process to not expand the trace beyond the seed issues. The Trace Studio, thus prevented from tracing beyond, advances to graphing the issues resulting from the JQL query according to the trace configuration. In this case, we started with a new trace meaning that the trace configuration is initialized to display relations of all types as per the default configuration.
Trace Requirements to Implementations and Tests
You can confirm which requirements for a given release are implemented and tested, and which ones are still incomplete (known as Requirements Fulfilment and Requirements Satisfaction).
Assumptions: Requirements, implementations, and tests are mapped as Story, Task, and Test issue types, respectively. The three types are related using issue links leading outward from the requirements.
Start with a new trace in the Trace Studio and apply the following changes to its configuration:
| Distance | 0 |
|---|---|
| Seed issues | issue IN relations('jql = issueType = Story AND Scope', 'direction = outward') AND issueType IN (Story, Task, Test) |
Set Scope to the characteristics of the requirements of your interest, such as to a specific project version: project = ABC AND fixVersion = 1.2.3. You'll need Browse permission on all of the associated projects and issues. The larger the scale of your results, the more likely you'll encounter the Graph Traversal Time Limit and the Issue Count Soft Maximum add-on settings, which will truncate your traces. (Fine-grain control of this limit is scheduled in the Product Roadmap ) Your Jira administrator is able to increase these add-on settings to accommodate your needs.
Requirements traced to their implementations and tests. This figure is a small clipping from a much larger trace report. According to the figure, requirement ASX-1 is waiting on the implementation of ASX-10 and the completion of the majority of testing in the QA project, whereas requirement ASX-7 has been fully implemented and tested.
Explanation: Starting from the seed issues JQL query, the jql parameter passed to the relations() JQL function identifies the requirements that you are interested in. Taken with the other parameter, relations() traces everything downstream from the requirements. The trailing conjunctions in the seed issues JQL restricts the resulting issues to those belonging to our assumed traceability information model; this restricted set becomes the seed issues in terms of the Trace Studio. Setting the distance to zero in the Trace Studio causes just the trace results (the seed issues) to be graphed; all actual tracing work from requirements to implementations and tests was done by the inner JQL query in the seed issues.
Going Further: Instead of just depending on the datum of whether an issue is resolved or not, it is probably wiser to add, at minimum, the Status and Resolution fields to the issue field layout to determine which work breakdowns are properly complete and which have been abandoned. You might even be able to save time over your development period by refining a duplicate of this trace that reports only on incomplete and abandoned sets.
Conduct Change Impact Analysis
Change impact analysis essentially identifies what is involved in executing a change, often for the purpose of understanding the impact on resources and scheduling and to calculate cost and risk estimates. As impact analysis is an investigation into some body of project artifact information, this activity requires such information to already be in Jira.
As an example from the world of regulated medical devices, a manufacturer of a portable medical device used for cardiographic diagnosis and monitoring can learn through impact analysis that the addition of a tethered pulse oximeter would cause changes to (partial list): the materials and safety specification, the electronic I/O sub-system, the case molds, the software responsible for reading, recording, and displaying sensor data, and the electronic health information privacy compliance documentation concerning the product's technical safeguards. Furthermore, the impact analysis can reveal domino effects: Modifications to the electronics and software would give rise to the need to re-audit both the hardware and the software for regulatory compliance. Some of the impacted items might be immediately obvious or a matter of course for the project team, and other items might be afterthoughts or forgotten entirely. Importantly, all items crucial to the successful production of the product and to receiving regulatory permission to market the finished product are identified through impact analysis. Once the scope of the impact of change is identified, you can calculate cost and risk estimates, enabling you to make better-informed decisions.
Note that a portion of the data required for this analysis might not be within Vivid Trace's traceable range and won't be included in these trace results. See the Product Roadmap for planned expansions in traceable artifacts.
Conducting Impact Analysis
The following procedure outlines the general steps in conducting impact analysis.
- Identify the items subject to the change. How are those items represented within Jira?
- Determine how other items are related to these items, such that they could be impacted. How are those relations and items represented within Jira?
- Within the Trace Studio, determine and set the tracing criteria.
- Run the trace and use the results to identify the items subject to change.
- Process the found items to develop an objective understanding of resource, schedule, cost, and risk.
Recommended Practice: When thinking about how impacted items could be related within Jira, consider the idioms that your Jira system offers and that your teams are using. Are impacted items likely to share the same project components, labels, keywords, top-level requirement, or individual source code changesets? Also consider how impacted items are not conclusively related in order to avoid pitfalls; for example, impacted items can span projects (projects can be structured along functional or team lines while their aggregate output all goes into the same deliverable) and they can also span versions (newer features in coming versions can impact the behavior of older, existing features introduced in prior versions). You can develop knowledge of how impacted issues actually relate by comparing and contrasting issues directly in Jira that are known to be impacted as well as those that are known to not be impacted. Thinking on this topic can also be leveraged to develop and improve your data management practices in Jira so that your system becomes more conducive to impact analysis.
Recommended Practice: Prefer tracing criteria that is too wide rather than too-narrow to avoid omissions. The point of this impact analysis is to have the system aid you in producing a reliable estimate of a proposed change. If the tracing criteria is too narrow such that some of the impacted issues are not identified, the omitted factors might not be incorporated into the resulting estimate and ultimately degrade the quality of the impact analysis.
Embedding Traces in Confluence Pages
Embedding traces in Atlassian Confluence pages can be tremendously useful for requirements management and test plans, among others. Refer to Confluence Integration for complete information.
FDA Medical Device Software Traceability Analysis
This information references Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, dated 2005 May 11.
This section is relevant to medical device manufacturers who intend to market a medical device that is subject to approval by the U.S. Food and Drug Administration (FDA). The FDA Medical Devices Guidance Document recommends that manufacturers include in their premarket submission package a Traceability Analysis document that objectively demonstrates "traceability among requirements, specifications, identified hazards and mitigations, and Verification and Validation testing." The FDA Guidance further recommends submitting a Traceability Analysis document for devices at all Levels of Concern (Minor, Moderate, and Major), according to "Table 3. Documentation Based on Level of Concern." For convenience, the "Traceability Analysis" section of the Guidance is repeated here:
A Traceability Analysis links together your product design requirements, design specifications, and testing requirements. It also provides a means of tying together identified hazards with the implementation and testing of the mitigations. We recommend that you submit for review explicit traceability among these activities and associated documentation because they are essential to effective product development and to our understanding of product design, development and testing, and hazard mitigations. The Traceability Analysis commonly consists of a matrix with line items for requirements, specifications and tests, and pointers to hazard mitigations. It is possible to document traceability simply through a shared organizational structure with a common numbering scheme; however, we recommend that you include some mechanism, such as a matrix for guiding the reviewer through the information you submit.
The objective of this section is to outline the general process of producing this Traceability Analysis document or some portion of it within the scope of the project artifacts being managed in Jira.
Preparation
Determine which traceable items and item information will be included in the Traceability Analysis document, and then consider:
- How to represent units of requirements and specifications as Jira issues.
- How relations will be represented between units in Jira.
- How to represent verification and validation test results in Jira, and how to display their result values in Vivid Trace traces.
- Whichs portions of information will be managed in Jira, mirrored into Jira from other systems, and kept outside of Jira.
- How to guarantee that the integrity of this information in Jira is maintained over the course of development in order to produce an accurate traceability analysis.
The decisions made during this preparation form the traceability model that is used to produce an FDA medical device traceability analysis report.
Producing a Traceability Analysis
- Within the Trace Studio, start a new trace.
- Configure the trace according to the prepared traceability model. Once configured, save this trace configuration for future recall.
- Run the trace, and inspect the output for errors and omissions.
- Use the export feature in the Trace Studio to capture the report in a common file format.
- Compile the exported file into the Traceability Analysis document for inclusion in the premarket submission package.
Recommended Practice: Validate the trace criteria and trace results before relying on the results. Prior to compiling the trace output into the Traceability Analysis document, run the trace and inspect the resulting trace data for errors and omissions. If the trace data does not properly cover the traceable items then the tracing criteria may need adjustment, and missing and erroneous trace data must be remediated. If you are operating on a saved trace, consider saving modifications made to the trace configuration. Look over the compiled traceability analysis and judge whether it objectively demonstrates traceability among the aforementioned items.
Find Unblocked Issues
Query for issues that are unblocked, tasks that are available to be worked on next. These are issues whose immediate upstream blockers are all resolved.
Start with a new trace in the Trace Studio and apply the following changes to its configuration:
| Distance | 2 |
|---|---|
| Issue field layout | Issue Type Key Priority Summary |
| Issue link types | Blocks |
| Seed issues | issue IN relations("jql = issue IN relations('direction = inward', 'issueLinkType = Blocks') AND resolution IS EMPTY", "direction = inward", "issueLinkType = Blocks", "distance = 1") AND resolution IS NOT EMPTY AND Scope |
Unblocked issues. In this figure, issue JET-14 is the only blocker and has been resolved, unblocking JET-15 which is now ready to be started.
Explanation: This trace is composed of three parts, and contains a relations() JQL function nested within another relations() function. This sample JQL seed issues criteria clarifies the nesting levels through the use of double quotes for parameters to the outer relations() function and single quotes for inner function parameters. (See Quoting Function Parameters within the Searching Issue Relationships section for a discussion on nesting quotes.)
The jql parameter to the outer relations() JQL function produces its seed issues using a nested relations() to select unresolved issues that have inward Blocks issue links. The other parameters to the outer function trace from the blocked seed issues to their blockers. The distinction between the two relations() functions is their mode of usage: The inner function searches for issues strictly based on whether they have an inward issue link of type Blocks, while the outer function traces from supplied seed issues to other issues according to its other parameters.
After the outer function produces the blocking issues, the only issues kept as seed issues to the Trace Studio are blocking issues that are resolved and satisfy Scope. Finally, the Trace Studio traces from the resolved blocking issues. Because it's possible that an issue can be waiting on several blockers, only a portion of which are resolved, setting the distance to at least two (2) and keeping all directions enabled ensures that any unresolved peer blockers will also appear in the graph, helping to prevent misunderstanding.
Going Further: If you have too many results, narrow Scope with more conditions. If you seek to delegate work to a particular person, add the assignee to Scope such as .. AND assignee = User Account. Get more information to aid prioritization by adding Due Date, Status, and Resolution to the issue field layout.
Identify Blocking Issues
Identify blocked issues, the issues causing the blockages ("blockers"), and the knock-on effects. Reading the results will help you understand the broader impact of the blockages and assess their impact and the value of resolving them, information that is useful for prioritizing work, directing resources, and communicating with others.
Start with a new trace in the Trace Studio and apply the following changes to its configuration:
| Directions | Outward, Sub-tasks |
|---|---|
| Seed issues | issue IN links('issueLinkType = Blocks') AND Scope |
Set Scope to the properties that define your field of interest, such as by project and version: project = ABC AND fixVersion = 1.2.3
A blocked issue, its blocking issue, and the downstream blockage.
Explanation: The trace is built in two stages. First, blocked issues and their blockers are identified using the links() JQL function according to your Scope criteria; these issues become the seed issues for the Trace Studio. Second, all downstream blockage is traced by the Trace Studio to complete the picture of blockages and its knock-on effects.
ISO 15504 SPICE Compliance
This information references Automotive SPICE Process Assessment / Reference Model, Version 3.0, dated 2015-07-16.
Implementing ISO 15504 SPICE compliance with Vivid Trace and Jira entails that relevant and correctly-formed issue and relationship information is in Jira prior to producing trace reports. Ideally, work products mandated by SPICE or by your particular model are managed as objects in Jira that are traceable by Vivid Trace, and relevant issue and relationship information is properly maintained throughout the project life-cycle. Pragmatically, it might be your case that not all SPICE work products are being managed in Jira directly (or perhaps mirrored into Jira from other systems) or are reachable by Vivid Trace, including requirement and architecture items, software implementation units and static verification, and change requests. In such cases, the tracing information produced here will need to be combined with information derived from other sources in order to form a complete and satisfactory traceability document for inclusion in the regulatory submission package.
Use the reports produced by Vivid Trace as a basis to satisfy the corresponding specifications for SPICE Annex D.4, "Traceability and Consistency":
- SYS.5 BP5 System qualification test results
- SYS.4 BP7 System integration test results
- SWE.6 BP5 Software qualification test results
- SWE.5 BP7 Software integration test results
- SWE.4 BP5 Unit test results
- SUP.10 BP8 Static verification results
Preparation
Traces need to be created for each of the desired reports. You can achieve this by creating a trace in the Trace Studio for each of the reports. The traces must ensure that:
- The seed issues and other trace settings net all of the work products required by the report.
- Each work product is clearly identified in SPICE terms, perhaps by capturing the identity on a per-issue basis in a custom field which in turn is made part of the trace's issue field layout.
- The status of each work product is indicated, by including the Issue Status and/or other fields in the trace's issue field layout.
- The resulting issue and relation information is coherent.
Recommended Practice: Give each saved trace a name that indicates the corresponding project and SPICE report. When periodically running the set of traces over the course of the project, this naming scheme will help you to correctly and quickly identify the set of traces.
Using the Traces to Produce Reports
Run the saved traces to produce traceability reports. With the trace reports in hand, you can use the export feature in the Trace Studio to capture the reports in common file formats for inclusion in other documents. You can also obtain an enumerated list of a particular report's issue results by using the "List issues" feature, producing the same issues but in the form of JQL query results in Jira's Issue Navigator, from where you can work sequentially and further process and output results at will.
Recommended Practice: Validate the trace criteria and trace results before relying on the results. Prior to each use of the reports, run the traces and inspect the resulting trace data, confirming the degree to which the SPICE criteria are satisfied and by extension the admissibility of the report. If the trace data does not properly cover the work products then the tracing criteria may need adjustment, and missing and erroneous trace data must be remediated. Ensure that any modifications made to the saved traces are saved.
Recommended Practice: Generate final trace reports from freshly-loaded, unmodified saved traces. This practice promotes reproducibility of the trace reports and improves the likelihood that decisions are based on accurate reports.
Monitor Support Request Chain of Events
Monitor the chain of events stemming from a customer support or help desk request. This enables support personnel and their managers, as well as other participants along the chain of events, to:
- Report progress of a particular support request to the customer.
- Confirm whether a fix has been shipped to the customer in response to their bug report.
- Plan and estimate work and change requests.
- Monitor progress on each and every outstanding request chain.
- Coordinate operations and optimize communications between teams, departments, suppliers, and partners.
- Continuously improve processes as new issues come to light through incident reports.
- Satisfy your stakeholders by giving them direct visibility into the chain of events and by seeking their verification when work is complete.
Assumptions: The support project key is SUPPORT. Support case issues are closed only after the customer affirms resolution. Issues created as a consequence of the request are related directly or indirectly to the request, meaning that issue links are created and maintained correctly.
Start with a new trace in the Trace Studio and apply the following changes to its configuration:
| Directions | Outward, Sub-tasks |
|---|---|
| Issue field layout | Issue Type Key Assignee Summary Status Resolution |
| Seed issues | issue IN relations('jql = project = SUPPORT AND resolution IS EMPTY') |
Visualization of support requests that are still in motion. Evocative of Lorenz' Butterfly Effect, a simple request can spark a flurry of activity, but in our case, cause and effect can be traced both forwards and backwards.
Going Further: Monitor areas of responsibility and time pressures concerning each chain by adding the Due Date, Reporter, Resolved, and priority fields to the issue field layout. Once you have a trace set up, save it so that you can conveniently recall it whenever you wish to monitor progress and changes. If you are interested in a specific case, identify an issue that lies somewhere along the chain and open it in a new browser tab. Alternatively, get a trace of the case by visiting its issue detail page in Jira or tracing its issue key in the Trace Studio.
Scan for Prematurely Resolved Parent Issues
In a parent and sub-task relationship, the sub-tasks can be viewed as dividing the workload represented by the parent issue. In this sense, the parent represents the totality of the work and can only be considered completed or resolved when all of its work breakdown sub-tasks are resolved. This health check visualizes parent and sub-task arrangements of issues that might be violating this resolution ordering, where a parent is resolved before all of its sub-tasks have been, and gives you a quick jumping off point to inspect questionable cases.
Start with a new trace in the Trace Studio and apply the following changes to its configuration:
| Directions | Sub-tasks |
|---|---|
| Issue field layout | Issue Type Key Status Resolution |
| Seed issues | issue IN relations('jql = issueType = Sub-task AND resolution IS EMPTY', 'direction = parents') AND resolution IS NOT EMPTY AND Scope |
Set Scope to the characteristics of the parent issues of interest, such as to a specific project version: project = ABC AND fixVersion = 1.2.3
A parent issue that is resolved ahead of some of its sub-tasks. In this figure, despite the issue statuses appearing to be proceeding normally, JET-1 has been resolved ahead of its incomplete sub-tasks JET-4 and JET-5 and therefore merits investigation.
Explanation: The pattern we are sifting for is resolved parents with unresolved sub-tasks. The jql parameter of the relations() JQL function finds unresolved sub-tasks, which in turn become the seed issues from which relations() will find the parents of. Only resolved parents matching Scope are kept and these become the seed issues for the Trace Studio. In turn, the Trace Studio traces from these resolved parents in the direction of sub-tasks, finally producing visualizations of each parent/sub-task arrangement exhibiting unresolved sub-tasks with a resolved parent.
Going further: This pattern can be applied to any type of work breakdown structure where a superior unit can be resolved only after all of its subordinate units have been. Primarily, the jql and direction parameters of the relations() JQL function and the directions trace setting need to be adapted to map to the issue types and relations in use.
Scan for Completed Tests of Unfinished Implementations
Testing of a feature should be concluded after the feature has been fully-implemented, not before. Run this health check to find implementations and their tests that might be in violation of this principle. Open suspect test and implementation issues in new tabs so that the web browser doesn't navigate away from the trace causing you to lose the trace configuration.
Assumptions: Implementations and tests are represented by the Task and Test issue types, respectively. They are related using an issue link type named Tests.
Start with a new trace in the Trace Studio and apply the following changes to its configuration:
| Distance | 0 |
|---|---|
| Issue field layout | Issue Type Key Status Resolution |
| Seed issues | issue IN relations('jql = issueType = Test AND resolution IS NOT EMPTY', 'direction = inward', 'issueLinkType = Tests') AND issueType IN (Task, Test) AND Scope |
Set Scope to criteria that identifies your test cycle, release version, or even the whole project.
Explanation: The relations() JQL function traces from resolved test issues (provided by the jql parameter as seed issues) following inward Tests issue links types. Task and Test issues that match Scope are graphed, and nothing further (controlled by the Distance of zero setting in the Trace Studio).
Scan for Escapee Issues
Scan for issues that should be related with issues in your current working set but are not. Project artifacts not linked into your working set might be escaping your purview.
Start with a new trace in the Trace Studio and apply the following changes to its configuration:
| Seed issues | Scope AND issue NOT IN relations() |
|---|
Set Scope to the characteristics of the issues of interest, such as to a specific set of projects: project IN (ABC, DEF)
Explanation: The first half of the AND conjunction ensure that only issues in Scope are considered. The relations() JQL function can operate in either of two modes; this mode, identified by its lack of seed issues criteria, will select issues based on whether they have relations to other issues or not. While relations() in this mode is able to select issues based on specific properties of their extant relations, this particular usage of relations() has no parameters and therefore simply selects a given issue as long as it doesn't have any relations whatsoever.
Going Further: Open issues in new browser tabs to modify them and establish relationships with other issues, bringing them into the working set. Add fields to the issue field layout to better understand each of the issues you are sieving through. Improve the quality of results by excluding false positives, for example by adjusting Scope or by parameterizing relations() to discriminate certain types of relations: relations('issueLinkType = Audit').
Scan for Excessive Aggregation of Issues
Epics and stories can be expected to aggregate a maximum number of work units as determined by you, but there might be some that aggregate an order of magnitude more. This health check makes such project management symptoms, or "smells", visually obvious, and gives you the opportunity to investigate and refactor these issue aggregators. At this time, issues cannot be selected on the basis of having a certain number of issue relations so it is necessary to visually inspect the graphs to identify such outliers.
Start with a new trace in the Trace Studio and apply the following changes to its configuration:
| Directions | Outward, Sub-tasks |
|---|---|
| Seed issues | issueType = Epic AND Scope |
Set Scope to select issues of interest, such as by project.
An Epic issue aggregating an unhealthy quantity of issues. Do you have any egregious cases like this?
Scan for Non-Blocking Issues with Blocker Priority
This health check scans for issues with blocker priority but do not have Blocks issue links out to other issues. When looking over the results, ask: What is it blocking and why? Is the team aware of this blocker? By relating blockers to your working set of issues, everyone can be aware of the existence and status of blocking issues and properly sequence work around them.
Assumptions: An issue priority named Blocker is in use. Blocking relationships between issues are managed, using the Blocks issue link relationship.
Start with a new trace in the Trace Studio and apply the following changes to its configuration:
| Distance | 1 |
|---|---|
| Issue field layout | Issue Type Key Assignee Summary |
| Seed issues | priority = Blocker AND issue NOT IN relations('issueLinkType = Blocks', 'direction = outward') AND Scope |
Set Scope to the properties that define your field of interest, such as by project and version: project = ABC AND fixVersion = 1.2.3
Explanation: The issueLinkType parameter of the relations() JQL function selects issues with Blocker priority. The direction parameter sets selection to that of outward issue links. Setting distance to one (1) provides some context for those issues that have other relations.
See All Issues in Jira
This trace, perhaps driven by curiosity, digs up all of the issues in your Jira system and graphs them, but with some limitations: Issues to which you do not have browse permission will be omitted, the tracing process will continue only until the Graph Traversal Time Limit is reached, and the results will be capped at the Issue Count Soft Maximum.
Start with a new trace in the Trace Studio and apply the following changes to its configuration:
| Seed issues | project IS NOT EMPTY |
|---|
Explanation: The use of a JQL query is necessary because the Trace Studio will not perform a trace with an empty seed issues criteria. And so we need a JQL query that selects all issues. This particular query exploits the fact that every issue in Jira must have an associated project, meaning that the project field always has a value and is therefore never empty.
Watch Issues in a Graph
By watching issues in a graph you will be instantly alerted to progress, changes in status, and problems as they occur. With such timely information, you can shrink communication and feedback lag with your report line, customers, partners, and other stakeholders, generally improving communication and satisfaction for everyone involved. Use the following process to watch some or all of the issues in a graph.
- Perform a bulk operation on the issues in a graph by selecting Bulk change issues from the Tools menu from the Tools menu in the Trace Studio or from the context trace menu.
- In step 1 of 4 of the bulk operation, choose the issues to start watching.
- In step 2 of 4 of the bulk operation, select the "Watch Issues" operation to watch the selected issues.
- Successfully complete the bulk operation.
watchedIssues() JQL function.