Agile working is on many companies’ agendas. Sometimes it works well, sometimes less so: this tends to depend on how well agile principles and values are understood and ‘lived’. Whether a company works with classic project management methods or uses agile frameworks such as Scrum, some requirements remain the same. For example, a project should be able to maintain transparency and traceability of requirements. This can be achieved through status tracking.
In many of my previous projects, we worked with Jira or other project management tools to ensure transparency. For example, using a Jira Agile board makes it easy to plan and monitor sprints, as well as tracking and managing the status of a product using release plans.
However, if we look at projects in industries in which the topic of traceability and linking work artifacts has a higher priority, you can quickly reach the limitations of a ‘pure’ project management tool, especially if requirements come from diverse documents and sources. Consider the automotive sector, for example: traceability is a key aspect in this industry and a necessary prerequisite for successful Automotive SPICE assessment. Automotive SPICE is a quality standard that allows automotive manufacturers to assess the performance of suppliers' engineering processes. In essence, the goal of traceability is to track and expose the implementation status of a requirement. This allows project management to demonstrate and better plan the extent to which requirements are implemented at any stage. In addition, their effects can be identified with certainty, and retests adequately performed and documented.
How can this level of traceability be ensured in an agile process? How can you ensure that all system and stakeholder requirements are correctly linked to test cases and implementations?
I would like to show this with an example scenario. Suppose an automotive project team uses a Jira Agile board to track its work within sprints. How can the team track the initial requirements across multiple stages?
In principle, test plans can be created in Jira and simultaneously linked to user stories or requirements. It is also possible to process such test plans and identify bugs that result from non-compliance with the test plan automatically. These bugs are then connected directly to the respective user story and so to the initial request.
This works well as long as requirements are formulated in Jira as user stories, tasks, epics, and the like. However, if requirements or test cases are not exclusively within Jira, but also in other documents (Word, Excel, or requirement tools such as PTC Integrity or IBM DOORS), perfect traceability can no longer be guaranteed. If using only Jira, requirement documents cannot be linked with each other, and changes to such documents cannot be tracked.
There are other ways to track and link such requirements, for example by using a dedicated traceability tool such as YAKINDU Traceability (now itemis ANALYZE) (YT). YAKINDU Traceability (now itemis ANALYZE) allows you to connect artifacts from different data sources and then analyze them, regardless of whether they are connected via direct or indirect links. ‘Direct’ in this case means that a direct connection – that is, an implicit connection – exists, for example between a test case and its implementation (implemented in Simulink). See Figure 1.
YAKINDU Traceability (now itemis ANALYZE) offer many possibilities, including representing and analyzing existing links, creating new links and exposing broken and missing links. However, YT is not an agile project management tool, and certainly not a ticket system: tools such as Jira are best for this. So in agile projects it’s desirable to have a combination of the two approaches, to make a requirement’s current status visible and to ensure traceability across all requirements.
It’s helpful to use a concrete example to introduce the possibilities of YAKINDU Traceability (now itemis ANALYZE) when coupled with Jira.
Figure 2 shows a product backlog with user stories for the operation of a windscreen wiper system. The first sprint is planned and underway: user stories WW-3 and WW-4 are completed. Each user story is associated with an epic (“Auto Wiping” or “Disable Wiper Washer”) and has a version number, for example “WW (1.0.1)”. The initial requirements for this system come from DOORS and are divided into stakeholder and system requirements. In this example the user stories were written based on the system requirements.
Say project management or – in our example – the product owner wants to know when a particular stakeholder requirement has been implemented. To achieve this, YAKINDU Traceability (now itemis ANALYZE) can create a report that lists all stakeholder requirements and displays their linked user stories. In our example we can see that several stakeholder requirements are not linked (Figure 3, lines 2–10).
However, we can also see which stakeholder requirements are linked, which user stories correspond to them – including estimated story points – and to which release version they belong. Since project management in our example is interested only in stakeholder requirements and not system requirements, only the former are listed in the report. For example, the requirement “SH-R: 2.1.2 Configurable sensitivity of auto wiping” depends on three different user stories and will be completed in the second release (WW 1.0.2).
What cannot be seen in this report is which of the three linked user stories is the actual trigger for this schedule. However, this information can be derived from the YT overview (see Figure 4), which shows that system requirement Sys-R: 2.1.2 was derived from stakeholder requirement SH-R: 2.1.2 and is linked to three user stories, WW-4, WW-5 and WW-6.
As the release version is also shown in this overview, the project manager or Product Owner can quickly determine that user story WW-5 is responsible for the delay in the schedule, since it is only scheduled for the second release. The YT overview also shows requirement SH-R: 2.1.1. This is linked to a system requirement, which in turn is expressed in Jira by user story WW-3.
The YT overview was obtained using the following YT query:
Figure 5: YAKINDU Traceability (now itemis ANALYZE) query for “Wiper Washer”
For anyone who wants to learn more about queries, I recommend the blog post “A Language to Analyze Trace Data Efficiently”.
YT Report and the YT overview allow you to evaluate requirements from various sources (in our example from DOORS) and make statements about their implementation or completion. Working together, Jira and YAKINDU Traceability (now itemis ANALYZE) can become an agile tool for requirements planning that can assist the Product Owner to collate and track requirements from multiple sources.
Transparency doesn’t only play an important role in an agile environment. In the automotive industry especially, full traceability from initial requirements to their corresponding test cases is required to comply with standards such as Automotive SPICE. In other areas it can also be useful to deal with the traceability of requirements, as a study by Professor Patrick Mäder and colleagues has demonstrated. Using Jira projects can be planned transparently, especially in an agile environment, and tracked with the help of sprints, roadmaps and reporting options. However, project requirements are not always recorded in the form of Jira tickets, so traceability across all requirements cannot be fully guaranteed.
In such cases a dedicated tool such as YAKINDU Traceability (now itemis ANALYZE) helps by linking requirements from various documents and sources to the corresponding Jira tickets. Over the entire course of a project this allows not only an understanding of which requirements have already been implemented, but also their status, in which sprint they are scheduled, and which requirements do not yet have a user story.
If you want to know more about the functionalities and applications of YAKINDU Traceability (now itemis ANALYZE), please check out our product page.