Many Application Lifecycle Management (ALM) tools have a baseline feature that can be used for defining Software Requirements Baseline. Jira out of the box does not have such a feature. So when one of my customers wanted to move their specifications from JAMA to Jira, we needed to find a way to fill this gap.
So what is a Software Requirements Baseline? In the context of Software Development Life Cycle (SDLC), you maintain the specifications for each product release. These are the requirements, tests, risks, and all other items. Together they build your traceability matrices and release documentation. These are constantly evolving and changing. New requirements are drafted and considered, bugs are fixed, new risks are being identified, and so on. This journey is punctuated by milestones. Each team will have its own milestones: the meeting when the scope of the first release got buy-in, sprint review meetings, etc. Software Requirements Baseline is designed to capture the specifications, as they were at the time of the milestone. It’s a way to document the milestone. Software Requirements Baselines provide also a fallback if you ever need to recover back into this milestone.
This is how the JAMA documentation described baselines:
“A baseline in Jama Connect is a snapshot of your project at a point in time. The current version of each selected item — and their relationships — are forever associated with that baseline.” With this background in mind, we found two ways to baseline your specifications within Atlassian. Both solutions assume that you manage your specifications in Jira already.
Solution 1: Baselining into Jira
Baselining into Jira means that you are copying your specifications into new baseline issues within Jira for each baseline. The baselines issues live in a dedicated project where editing is not permitted, and the data is not changed.
Once you have configured Jira this way, users can create new baselines like this:
- Select the issues that need to be part of this baseline. Like: All specifications issues in the project ‘SpaceShip’ associated with version 1.2. Use Jiras’ search feature to make this selection.
- Apply on these issues a Jira ‘bulk change’ operation, and transition them through the ‘create baseline’ action
- Complete the required information about the baseline, for example, the baseline name.
This results in a collection of new issues within our baselines project. Each one is the exact copy of one issue in the original group. The field ‘baseline name’ is also set as completed during the bulk transition.
Under the hood, it’s a workflow transition that triggers the baseline issues. The exact scope of the copy is customizable, especially if using Apps to extend Jiras native workflow options. You decide which fields from the original issue are copied, which link types, whether the summary has a prefix, and so on. You also control what baseline information the user provides on the creation of the baseline.
The baselined items can be viewed as a group and used in reports. Each one links to the original issue. When you are reviewing a specification item, it’s clear to see what baselines they have and compare between the issue as it is today and its baseline.
Solution 2: Baselining into Confluence with the Jira Snapshots App
The second approach creates baselines of Jira data in Confluence. It uses a marketplace App, our own Jira Snapshots – Time-Stamped Exports Into Confluence. This App exports a static copy of Jira data into a Confluence page. You control which issues are exported, the fields, and which links are brought along into the baseline. You may even create multilevel snapshots- capturing the complete traceability.
Do you need to create baselines for different milestones for the same collection of data? With Jira Snapshots, you have a neat way to compare between two baselines. It has a DIFF feature that redlines the latest snapshots against any previous one.
This approach is external to Jira and does not require any changes to Jira itself. No need to change workflows, create extra fields or projects, and no need to load your overstretched Jira administrators. Installation of this single app is all that it takes. Anyone who needs a baseline, for whatever Jira data and for whatever reason, can pull it into Confluence.
Which Solution Should I Choose?
The two methods of baselining differ in how the baseline data looks, as well as the complexity in setting them up and the tools you need. The first is within Jira and makes a lot of sense if you do not use Confluence. It will need extension to the workflow and other configuration work. Use JQL to show all the issues belonging to the same baseline. Its more difficult to show the hierarchy within the baseline data and there is no way to highlight differences between baselines.
If Confluence is part of your arsenal, you can install Jira Snapshots – Time-Stamped Exports Into Confluence and use it to create your baseline. No need to change Jira in any way.
Yes! You Can Create Baselines From Jira Data
Whatever is your chosen solution, it will tick the boxes for what you need from a baseline:
- It is a snapshot of your project at a point in time;
- It has a copy of the current version of each selected item, and their relationships;
- You can refer to it to see what changed
Back to our starting point that triggered our exploration. With these options available, our customer transitioned their specification into JAMA. They knew that they will not miss out on the baseline feature.
Looking for more inspiration about how to use Jira for Requirements management? Check out this webinar about how regulated teams can ace their traceability on Atlassian
