Setting up next-gen boards and backlogs for optimal performance

[#1]

Hi everyone!

My name is Ivan, and I’m a Product Manager working on next-gen projects in Jira Software Cloud. Based on previous conversations with customers, I’ve noticed some UI settings that result in slow performance on next-gen boards and backlogs.

I understand that every team is used to their unique way of working, but we have some recommendations on how to set up your next-gen projects in order to improve performance.

Note that next-gen is different from Classic, as it has a feature toggles setting page to enable you to change your agile methodology to adapt your working style to the dynamic environment.

Feature toggle page (Project Settings → Features):

Board and backlog / settings recommendations

• Loading a board / backlog requires fetching the required data, and rendering all issues on it. Therefore, the time taken to load is directly related to the number of issues.

• We currently recommend that the next-gen backlog contains < 300 issues and the board < 200 issues. We optimize for these use-cases, and offer the best experiences for this.

There are a few ways to reduce the number of issues.

If your project has enabled Sprints (Scrum teams):

• Sprint length: If you have a sprint that takes a very long time (>= 4 weeks) to complete, then you tend to end up with too many issues in your sprint (see Agile Coach on Sprints and Retros).

• Sprint planning and regular retrospectives every 2 weeks help your team refine your team process and approach.

If your project has disabled Sprints (Kanban teams):

Clearing your “Done” (resolved) issues from the board (see Blog on Manual Board Clearing).

Still searchable in the Project Issue Navigator (see Blog on Project Issue Navigator)

If your TO DO column on the board has many issues, enable Backlog:

• Reduce number of cards by using a backlog (see Agile Coach on Kanplan).

• This is to provide ruthless prioritization for the team, so you can focus your team only on the most critical work for the coming 1-2 weeks on the board view.

  • Backlog has epic/versions panel to bulk-update issues (see Blog on Epic panel)

If your team does not practice continuous releases:

If your team does fixed releases (meaning that you don’t release to customers whenever it’s dev-complete, but wait for a scheduled time monthly or quarterly), then it would be better not to have a column on the board representing issues waiting for a customer release.

• Impact of this behaviour: You will wait a long time to move the issues to Done, if your Definition of Done is that the issues need to be released first to customers.

  • The board should ideally be used for something that is important to everyone in the team, not just the Product Manager or Team Leader.

  • Over-optimizing to track or plan everything there will result in problems with focus for the team and slower performance as well.

• Change Board’s Definition of Done from Released to Dev Complete/Merged.

  • Track release dates in the Releases view and add the version to each issue, so you don’t clutter the board.

• If Releases is not enabled:

  • Enable it, and track issues related to releases in the Releases View (see Blog on Releases).

If your team uses GROUP BY EPICS on the board:

• Reduce the number of epics by moving all the child issues under epics to DONE, as well as making sure the epic’s status is DONE.

  • This will auto-clear epic from the board and backlog (if it doesn’t have any incomplete child issues and its own epic status is done).

If you use a mix of mouse and keyboard:

• Use keyboard shortcuts to navigate board and backlog, and assign tasks quickly (see Blog on keyboard shortcuts)

If you want to edit issue fields in backlog during backlog grooming and sprint planning without opening issue:

• Use quick edits when updating issue fields in the backlog (without opening issue view)!

  • Quick-edit issue status / assignee / story points by clicking on the issue field directly in the backlog view

If you want to create issues with relevant fields without opening issue:

Avoid using the Global Issue Create, and use the Filtered Issue Create instead. This will allow you to create the fields you need without having to open the issue view and then editing the fields.

• Use inline issue create paired with the quick filters applied.

  • Not many people know that by activating the avatar, epic, version or label quick filters while creating issues, you can create the issues together with all the required fields together.

Recommended software for optimal Jira performance

Browsers:

We recommend Chrome or Safari for optimal Jira performance. Firefox don’t support pre-loads.

• Firefox is currently developing preload support (released on Nightly and Early Beta), though unsure when it’s available for GA:

  • https://caniuse.com/#feat=link-rel-preload

  • https://platform-status.mozilla.org/#link-rel-preload

  • https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content

  • Source: https://phabricator.services.mozilla.com/D76164

Multiple tabs can impact browser performance. Each tab eats up memory that slows down the CPU, which causes the computer to work harder to load up Jira as Jira also has to consume memory.

Using bookmarks causes pages to reload all assets. Bookmarks lead to a refreshed initial load which downloads all assets from scratch. Instead, use transitions if you’ve already loaded that view in the same session.

• An initial board load has to download resources for all the views plus assets like images. Switching between views is then faster, because most stuff is already loaded.

  • First time loads: We call this "Initial Load", and it includes resources for all the views plus assets like images, so it is usually longer.

  • Subsequent time loads: We call this "Transitions", such as loading a board a 2nd time after transitioning from the backlog (board → backlog → board) through clicking on the project side navigation, where the board load is faster now because most assets are already loaded.

Multiple Applications:

Be aware of what other apps are running and use the Task Manager (Windows) or Activity Monitor (macOS) to keep an eye on CPU and memory utilisation.

[Bill Sheboy]

Hi @Ivan Teong 

Thanks for centralizing many of the concepts for NextGen board usage, and explaining why performance management via settings is needed for this newer product from Atlassian.

Please also consider looking at some of the NextGen versus Classic project differences, and where performance may suggest switching back to Classic.

Thanks again!

Best regards,

Bill

[Ivan Teong]

@Bill Sheboy There are some main differences between Classic and next-gen, which I didn't want to go into here too much as it'll be a rabbit hole, but since you brought it up, I'll mention them.

We built next-gen through years of research where customers who wanted to adopt more agile ways of working believed that Classic's style of centralized project administration felt restrictive. We developed next-gen to allow teams to be more independent and autonomous, as many agile teams today have different ways of working within the company.

Next-gen was built to beat the competition, not to compete with Classic. However, there was a lot of comparisons between Classic and next-gen as they both lived within Jira Software.

• Fundamentally, next-gen is more for independent teams, where there is delegated administration for teams at a project level for issues types and fields, project access and its features can be toggled on and off by the team (backlog, sprints, roadmaps).
• Classic is for teams that work in a larger program, where the project configuration needs to be centrally controlled and administered by the organisation (no delegation) through schemes. Classic also does not have feature toggling to mix-and-match features that you want, so if you want to change your agile methodology, you'd have to create a new board within the project.

Because we built next-gen from the ground up like a startup, it lacked a lot of power that Classic has in terms of features initially. However, we've developed a lot of features over the past year and things like subtasks, reports, releases have been built to satisfy the needs of teams with basic needs. We're also going to be shipping the highly-demanded workflow editor in the coming weeks, it's already shipped to new customers (existing customers is next).

We launched to the market so that we can grab back market share for software teams that would have never considered JSW in the first place, and many customers who churned to our competition (for ease-of-use) have returned. Now we need to continue building out our feature set to satisfy the needs of advanced teams (and existing customers), which we will over the next few years.

In terms of project differences in terms of performance, there are some things that exist in next-gen today that increases efficiency and performance that does not exist in Classic, such as using a backlog for non-sprint boards, manual board clearing that isn't tied to Releases, quick edits and filtered issue create. There are also some things that exist in Classic that help with efficiency and performance that don't exist in next-gen YET, such as custom quick filters, multiple boards per project and some others.

Next-gen today is currently slower than Classic for larger backlogs and boards, but we're working hard to address that with a series of experiments.

• Since June, we've reduced the load times of next-gen boards with 300-500 issues by 26%, and for next-gen backlogs with 300-500 issues by 28%. This will continue through the rest of the financial year (till June 2021), so hopefully you'd stick around to see that happen!

We're aiming to slash load times by 2-3x before doing a larger marketing campaign around our work, so bear with me while we're at it! Please feel free to schedule a chat with me if you need to chat about performance concerns.

[Bill Sheboy]

@Ivan Teong thanks for your response and additional thoughts.

It is good to hear some of the thinking behind the decisions being made for NextGen.  Often for Jira features, some of the choices seem unclear in the "what problem is being solved"/value-add area.  :^)  Which is why customers may be frustrated by going to the effort to craft suggestions in public backlog to help the community, only to find great ideas languishing for a decade or more. (not an exaggeration)

Please keep up the good work, and best regards,

Bill

[Monika Rani]

@Ivan Teong useful information please keep up the good work and sharing your knowledge with us.