Learn about configuring scrum-type boards within Jira.
- [Instructor] Next up, let's go over versioning within Jira. As you are most likely already aware, the incremental way in which a piece of software progresses in life is displayed via a software's version. As each incremental change is added to the software, its version number is increased by a point. This can be a small point change, indicated by a small number going from 1.01 to 1.02, or a massive change shown by a large number being modified, such as 1.10 to 2.0. Some software is also known by name changes.
Such as Apple giving names to each of its versions, like Snow Leopard, or Yosemite. These version releases are usually accompanied by the developer, with what are known as release notes, which display an easy to read list of items that have been added or changed within the latest release. The main thing to remember, is to have a consistent and well-communicated way to differentiate between versions that is understood by all team members. Jira integrates versions in an easy to understand fashion. But it is layered above the idea of sprints.
Not every sprint needs to match a new version. This is again depending on your team's process, and not dictated by one hard and fast rule. Consistency is key. Within Jira, we can view a board or project's different versions by proceeding to the releases panel. In our demo project, you should see both 2.0 and 3.0. Above these, you can see some quick filter buttons. Click the Released button to see the released version 1.0. When software is released, it's considered live. Meaning it's in the wild and available to your customers.
Unreleased means either still in development or planning stages. You'll also see an Archived quick filter, which displays archived versions. There's none here right now. To archive a version removes it from the main list. So it's to no longer display in development areas, or change logs created by the actual release process, and other connected Atlassian applications. Next to each version name is the status of the version. Be it released, unreleased, or archived. When you create a new release, you designate a release date.
If a release is not in a released status by the time that date is hit, it will automatically update into an overdue status until released or archived. Next to the status, you'll see a progress bar for each version. This measurement is based on the tickets that are in each version that are currently done within a specific release. Let's go ahead and click on version 2.0. Now we are looking at the detailed view of this specific release. More importantly, individual issues within the release.
Remember, releases and sprints are different. You may very well have items from two different sprints within the same version, and it may take longer to fill up the items to complete an actual release. We can click into a ticket in to-do status if we'd like more information about it. We can also mark it as complete. Now we'll go back to the overview, and as you can see, the progress bar has increased a little bit.
Let's go ahead and go back to 2.0. Next let's click the blue Release button. Similar to the complete sprint pop-up, this prompt is asking us what to do with the remaining tickets in the release that have yet to be completed. Now we can choose to ignore this prompt, which will keep the items in the release, albeit incomplete, or we can choose to move the items to a future release. In this case, 3.0. We will move the items to the next release, because in our hypothetical scenario, we couldn't quite get to the items before our anticipated release date.
So they needed to be differed until later. We can modify the official release date from here as well, as it seems to be preplanned for a bit in the future. Let's change it to today's date. We then click Release on our pop-up, and this release has been completed. If we add a connected plugin like Bitbucket at this time, we could also automatically generate a build in our repository based on this. More on that later. Let's click the Releases again, to return to the main version page.
At the bottom you can see space to add a new version. We can also add a start date, projected release date, and a description, all optional. Remember, consistency is key. So let's call this one Version 4.0. Use today's start date, and a release date a week from now. In real life your versions are most likely going to take longer than a week to develop. We will skip the description, and then click Add. And voila! The version appears at the top of our list.
If we click into it, we can see that it currently contains no issues. That is easily remedied. Let's click the backlog, and choose any existing issue, then choose to edit it. From here, let's find the Fix Versions field. As you can see, currently it is version 3.0. We'll go ahead and click this dropdown, and as you can see, we have our unreleased version 4.0 at the top of the list. We'll go ahead and select this dropdown, remove the 3.0 version, then click Update.
When creating new tickets, you can also select the Fix Version field and the sprint field, provided they have already been created in the way I've just described. When creating bugs, you can also use the effects version field. So you can show on your bug which version it was found in, and which version it was fixed for. One last note, let's go ahead and go back to releases. You can click the Merge Version button to merge multiple versions into one release. Either due to scheduling or development issues not foreseen. Beware that this cannot be undone, and should only be performed if absolutely necessary.
You shouldn't be planning your releases anticipating a merge and if it occurs too much, you may be planning incorrectly. By properly using versions in your software release plan, you can easily plan large scale releases with just a few clicks.
- Creating new Jira boards
- Creating cross-project release plans in Portfolio
- Managing Portfolio dependencies
- Configuring Bitbucket for code management and version control