JIRA Agile classic boards are no longer supported by Atlassian. That’s the reason why I have evaluated to migrate two existing projects from classic boards to the new rapid boards in JIRA Agile. In this blog post I want to share my experience and highlight some problems that have occurred during the migration.

Migrating from classic boards to the new rapid boards in JIRA is very easy at first glance. I only have to create a new agile board, choose between Scrum and Kanban template and select a project or a filter as the basis for the board. However, that is not all. Therefore the first step after creating a new rapid board is to check the amount of issues in the backlog and compare it with the number of all issues in the issue navigator. The easiest way to find out if issues are missing is to use the advanced search in JIRA and create a JQL query to find out all existing issues in your project. JQL means JIRA Query Language and use a similar syntax to SQL. If you want to find out all issues within a project you can type in the following JQL query in the advanced search tab inside the JIRA issue navigator.

Don’t be irritated if the number of issues in your backlog is smaller than the number you get in your issue navigator. In the Backlog you will only see issues that are not closed or resolved and not type of sub-task. If you have additional issue types defined of type sub-task you need to add them to the query as well.  In addition epics will be organized in the left-hand side panel in JIRA Agiles plan mode. Therefore epics will not be listed in the Backlog. In most cases missing issues results from unmapped workflow states. This means that there are workflow states that does not relate to any column in the rapid board. You can create new columns and map workflow states to them. By accumulating the amount of all issues in the mapped columns you will receive the amount of all issues. Basically this should be in balance with the number that you found out in the issue navigator above. The sum of issues in the backlog should be equal to the sum you received by entering the query below in the issue navigator.

UnmappedStatusColumn

Mapping Workflow Statuses to Columns in the Agile Board

Rapid Boards consists of two parts- the work mode and the report mode. Scrum Boards also have a plan mode where you plan and prioritize your backlog as well as creating and planning your sprints.

  1. Plan Board: Sorting and prioritizing issues within backlog and moving them to a sprint
  2. Work Board: Moving issues in an active sprint between different workflow steps
  3. Report Board: Analyzing completed sprints in different reports (e.g. Burndown Chart)

If you have worked with Epics in Classic boards you have used the customfield “Epic/Theme” to create a relation between an epic and issues. The new rapid boards use another customfield called “Epic Link” to determine the epic for an issue. Since JIRA Agile 6.1.3 JIRA offers a way to migrate existing Epics to the new Rapid Boards. As JIRA administrator you will find the menue within the Add-on section –> JIRA Agile –> Classic Migration. In this step JIRA will move all issue keys within the customfield “Epic/Theme” to the new customfield “Epic Link”. After the migration you will find all your epics on the left hand-side panel of the Plan Board next to the version tab.

Migrating Classic Epics to JIRA Agile

The previous classic boards do not offer a specific field for creating and planning sprints. Therefore we used versions to define sprints and assign issues to it. In the new rapid boards sprints are no longer planned as versions. Migrating from classic board to rapid board brings the problem that the original “sprint versions” are no longer needed. When migrating to new rapid boards- the sprint versions of the old board will still exist but are useless.  If an issue remains  to more than one version in the classic board, be careful when assigning it to another version by drag and drop the issue into the new version on the left hand-side version panel in the new scrum board. Issues will be removed from previous versions. To avoid this you have to edit the issues manually and add a new version in the fix Version field.

The classic task board is the place where our running sprints are listed. According to the workflow steps, cards(=issues) can be moved from one column (=status) to another. In addition to the three standard columns – open, in progress and done, I added the column “In Integration” and assigned the corresponding workflow steps to it. If an issue is in this step I can either accept the integration or set to failed. Multiple workflow steps can be mapped to one column in the work board. Too much workflow steps will be confusing, therefore I recommend to use one column for one workflow status or at least map only similar workflow status (resolved and closed) together in one column.

A very nice feature for seperating and organizing issues in the new rapid boards are swimlanes. Swimlanes group issues with similar criteria. Atlassian offers default swimlanes based on assignee or user stories.  The most flexible way for configuring swimlanes is JQL. Another way grouping issues is by using quick filters on the top of the board. Based on JQL you can specify which issues should be excluded from the board by clicking a filter. Most of the time I am not interested in closed issue so I defined a filter named “Hide closed issues”.  Another configuration issue you have to keep in mind is time tracking. JIRA Agile offers several methods to estimate the effort of an issue. You can configure the estimation method in the configuration of your board by choosing between story points or estimated time. Next to the estimation you can enable time tracking. With this function you are able to track your work log on single issues even if you have chosen story points as your estimation method. The Burndown chart in the report board will always take the estimation method for tracking the effort of your sprint.

-Natalie

Leave a Comment

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close