Tips & Tricks: Create a Planned Version Field in Jira

Kitty de Ruijter

Kitty de Ruijter

Published: 2 August, 2018

tips-tricks


The objective of this post is to provide a way to easily record and view issues' fix versions as they were initially planned. Enter the 'Planned Version' field.

This field can be useful when you need to report on releases. This is often the case if you're working on a project in collaboration with a customer or a third party supplier.

 

Dealing with changes in Fix Versions

Typically, to create your release reports, you would generate an issue list in the issue navigator in Jira (via 'Search for issues') based on the 'Fix Version/s' field (you then see which epics and stories belong to which release). You can just add columns in the 'List view' to show the necessary details and simply export it to a workable format, in order to share it externally.

But what if a specific issue gets pushed back to a further release? Or what if it is released earlier than planned? The Fix Version/s field will simply be updated until the issue is actually fixed. So there's no way to easily spot issues that were released later or earlier than initially planned...

Aside from that, when a customer asks: "what was the original release planning again?" or "could we analyze the discrepancies with the current release planning?", you would probably have to dig in your mail, in Confluence or in some document in order to find previously exported reports. Then you might have to do some fancy Excel merging of data, or even worse: look into the history of every issue in order to track the changes in the Fix Version/s field...

Improve your reporting

This tip should provide you with a simple way to report on releases as they were originally planned and to quickly spot issues that have been replanned in your issue reports.

First, we'll need to create a new custom field called Planned Version of the type Version Picker (single version). 

Version Picker

This custom field will work just like the Fix Version/s and Affected Version/s field. Values that can be chosen in this field correspond to the available versions in your project. Just make sure this field is available on the screen(s) of your development project!

When a new Story is created, the Planned Version field can be filled in. Now, your Story only has a Planned Version associated (no Fix Version yet) and is ready for refinement.

Typically when a Developer starts working on the issue, it will receive a Fix Version (the Planned Version is a guideline for the Developer in this case). Along the way, the Fix Version may be changed. But in the end, you can always quickly compare the Planned Version with the actual Fix Version. You can also generate release reports using the Planned Version field as a comparison with the Fix Version.

image2018-7-31_14-46-33

OMG it's a tip inside a tip

 If you really want to enforce the Planned Version field to only get filled in upon issue creation (and prevent it from being edited afterwards) you can add the field to the Create Issue Screen only. Make sure the creator of an issue fills in the Planned Version though by making the field required via a validator or the Field Configuration Screen.

If you don't know the Planned Version upon issue creation, but still want to enforce the Planned Version to be set once and not changed afterwards, you could combine an automation rule (the add-on Automation for Jira is required for this) and a screen adjustment:

First you can create an automation rule which fills the Planned Version field with the value of the Fix Version/s field, the first time this is entered there (so when Fix Version/s changes from nothing to something). You will also need to remove the Planned Version field from your Edit Screen. This way, the Planned Version field will contain the first Fix Version that was entered for a particular issue and users are not able to edit the Planned Version, but are able to see it on the issue.

Related blogs

Did you enjoy reading?

Share this blog with your audience!