team-managed Archives - Strategy for Jira®

Built-in Jira Software Reports

Jira comes with many built-in reports to provide insights into progress, release health, time logged, forecasts, and more. Each Jira application type, deployment type and project type contain different reports however. I’ve compiled a list of the report types and their definitions in Jira Software, so you don’t have to!

Tip: Be sure to consider reporting options when choosing between project types.

Jira Software: Cloud

COMPANY-MANAGED SCRUM PROJECT

Report count: 23
Unique reports: Cycle Time Report, Deployment Frequency Report, and Workload Pie Chart Report

Agile

Burndown Chart – Track the total work remaining and project the likelihood of achieving the sprint goal. This helps your team manage its progress and respond accordingly.
Burnup Chart – Track the total scope independently from the total work done. This helps your team manage its progress and better understand the effect of scope change.
Sprint Report – Understand the work completed or pushed back to the backlog in each sprint. This helps you determine if your team is overcommitting or if there is excessive scope creep.
Velocity Chart – Track the amount of work completed from sprint to sprint. This helps you determine your team’s velocity and estimate the work your team can realistically achieve in future sprints.
Cumulative Flow Diagram – Shows the statuses of issues over time. This helps you identify potential bottlenecks that need to be investigated.
Version Report – Track the projected release date for a version. This helps you monitor whether the version will release on time, so you can take action if work is falling behind.
Epic Report – Understand the progress towards completing an epic over time. This helps you manage your team’s progress by tracking the remaining incomplete/unestimated work.
Control Chart – Shows the cycle time for your product, version or sprint. This helps you identify whether data from the current process can be used to determine future performance.
Epic Burndown – Track the projected number of sprints required to complete the epic (optimized for Scrum). This helps you monitor whether the epic will release on time, so you can take action if work is falling behind.
Release Burndown – Track the projected release date for a version (optimized for Scrum). This helps you monitor whether the version will release on time, so you can take action if work is falling behind.

DevOps

Cycle Time Report– Understand how much time it takes to ship issues through the deployment pipeline and how to deal with outliers.
Deployment Frequency Report – Understand your deployment frequency to understand risk and how often you are shipping value to your customers.

Issue analysis

Average Age Report – Shows the average age of unresolved issues for a project or filter. This helps you see whether your backlog is being kept up to date.
Created vs. Resolved Issues Report – Maps created issues versus resolved issues over a period of time. This can help you understand whether your overall backlog is growing or shrinking.
Pie Chart Report – Shows a pie chart of issues for a project/filter grouped by a specified field. This helps you see the breakdown of a set of issues, at a glance.
Recently Created Issues Report – Shows the number of issues created over a period of time for a project/filter, and how many were resolved. This helps you understand if your team is keeping up with incoming work.
Resolution Time Report – Shows the length of time taken to resolve a set of issues for a project/filter. This helps you identify trends and incidents that you can investigate further.
Single Level Group By Report – Shows issues grouped by a particular field for a filter. This helps you group search results by a field and see the overall status of each group.
Time Since Issues Report – For a date field and project/filter, maps the issues against the date that the field was set. This can help you track how many issues were created, updated, etc, over a period of time.

Forecast & management

Time Tracking Report – Shows the original and current time estimates for issues in the current project. This can help you determine whether work is on track for those issues.
User Workload Report – Shows the time estimates for all unresolved issues assigned to a user across projects. This helps you understand the user’s workload better.
Version Workload Report – Shows the time estimates for all unresolved issues assigned to a version, broken down by user and issues. This helps you understand the remaining work for the version.

Other

Workload Pie Chart Report – A report showing the issues for a project or filter as a pie chart.

COMPANY-MANAGED KANBAN PROJECT

Report count: 15

Agile

Cumulative Flow Diagram – Shows the statuses of issues over time. This helps you identify potential bottlenecks that need to be investigated.
Control Chart – Shows the cycle time for your product, version or sprint. This helps you identify whether data from the current process can be used to determine future performance.

DevOps

Cycle Time Report – Understand how much time it takes to ship issues through the deployment pipeline and how to deal with outliers.
Deployment Frequency Report – Understand your deployment frequency to understand risk and how often you are shipping value to your customers.

Issue analysis

Average Age Report – Shows the average age of unresolved issues for a project or filter. This helps you see whether your backlog is being kept up to date.
Created vs. Resolved – Issues ReportMaps created issues versus resolved issues over a period of time. This can help you understand whether your overall backlog is growing or shrinking.
Pie Chart Report – Shows a pie chart of issues for a project/filter grouped by a specified field. This helps you see the breakdown of a set of issues, at a glance.
Recently Created Issues Report – Shows the number of issues created over a period of time for a project/filter, and how many were resolved. This helps you understand if your team is keeping up with incoming work.
Resolution Time Report – Shows the length of time taken to resolve a set of issues for a project/filter. This helps you identify trends and incidents that you can investigate further.
Single Level Group By Report – Shows issues grouped by a particular field for a filter. This helps you group search results by a field and see the overall status of each group.
Time Since Issues Report – For a date field and project/filter, maps the issues against the date that the field was set. This can help you track how many issues were created, updated, etc, over a period of time.

Forecast & management

Time Tracking Report – Shows the original and current time estimates for issues in the current project. This can help you determine whether work is on track for those issues.
User Workload Report – Shows the time estimates for all unresolved issues assigned to a user across projects. This helps you understand the user’s workload better.
Version Workload Report – Shows the time estimates for all unresolved issues assigned to a version, broken down by user and issues. This helps you understand the remaining work for the version.

Other

Workload Pie Chart Report – A report showing the issues for a project or filter as a pie chart.

TEAM-MANAGED SCRUM PROJECT

Note: Application and project administrators need to enable this feature at: Project Settings > Features. See screenshot

Burnup report – Visualize a sprint’s completed work and compare it with its total scope. Use these insights to track progress toward sprint completion.
Sprint burndown chart – Track and manage the total work remaining within a sprint. After the sprint, summarize both team and individual performance.
Velocity report – Predict the amount of work your team can commit to in future sprints by seeing and reviewing the amount of value delivered in previous ones.
- Note: A completed sprint is required
Cumulative flow diagram – Shows the statuses of your project’s issues over time. See which columns accumulate more issues, and identify bottlenecks in your workflow.
Cycle Time Report – Understand how much time it takes to ship issues through the deployment pipeline and how to deal with outliers.
Deployment Frequency Report – Understand your deployment frequency to understand risk and how often you are shipping value to your customers.

TEAM-MANAGED KANBAN PROJECT

Note: Application and project administrators need to enable this feature at: Project Settings > Features. See screenshot Additionally, some reports require sprints. Enable them on the features page too, if desired.

Same as the team-managed scrum project above.

Jira Software: Server and Data Center

SCRUM PROJECT

Same as the company-managed scrum project above without the following reports: Cycle Time Report, Deployment Frequency Report, and Workload Pie Chart Report

KANBAN PROJECT

Same as the company-managed kanban project above without the following reports: Cycle Time Report, Deployment Frequency Report, and Workload Pie Chart Report

Extending Reporting Capabilities

Most reports are customizable and if you can’t get to the data you’re after, there are plenty of apps available in the Atlassian Marketplace.

Default Jira Global Permissions

Sometimes it’s important to understand how far your Jira application has strayed from the default configuration. Was that setting there from the beginning or did an application administrator add it eons ago?

To find out, visit Admin > System > Global permissions in your application. Then use this baseline list to compare your Jira settings to the default.

Initial settings for Jira Cloud and Jira Server/Data Center v8.15 are included below. I keep fresh and untouched application instances around so you don’t have to!

Jira Software Cloud Global Permissions

Administer Jira

Create and administer projects, issue types, fields, workflows, and schemes for all projects. Users with this permission can perform most administration tasks, except: managing users, importing data, and editing system email settings.

Users/Groups:

system-administrators
atlassian-addons-admin
site-admins
trusted-users-xxx (unique alphanumeric string)
administrators
jira-administrators

Browse users and groups

View and select users or groups from the user picker, and share issues. Users with this permission can see the names of all users and groups on your site.

Users/Groups:

system-administrators
site-admins
jira-software-users
administrators
jira-administrators
atlassian-addons-admin

Share dashboards and filters

Share dashboards and filters with other users.

Users/Groups:

atlassian-addons-admin
jira-software-users
system-administrators
jira-administrators
site-admins
administrators

Manage group filter subscriptions

Create and delete group filter subscriptions.

Users/Groups:

jira-administrators
jira-software-users
administrators
system-administrators
atlassian-addons-admin
site-admins

Make bulk changes

Modify collections of issues at once. For example, resolve multiple issues in one step.

Users/Groups:

atlassian-addons-admin
jira-software-users
site-admins
administrators
jira-administrators
system-administrators

Create next-gen projects

Create projects separate from shared configurations and schemes. Next-gen projects don’t affect existing projects or shared configurations like workflows, fields or permissions. Only licensed users can create next-gen projects.

Users/Groups:

Public, anyone on the internet, including logged in and anonymous users.

Jira Software Server & Data Center Global Permissions

Jira System Administrators

Ability to perform all administration functions. There must be at least one group with this permission.

Users/Groups:

jira-administrators

Jira Administrators

Ability to perform most administration functions (excluding Import & Export, SMTP Configuration, etc.).

Users/Groups:

jira-administrators

Browse Users

Ability to select a user or group from a popup window as well as the ability to use the ‘share’ issues feature. Users with this permission will also be able to see names of all users and groups in the system.

Users/Groups:

jira-administrators
jira-servicedesk-users (If installed)
jira-software-users

Create Shared Objects

Ability to share dashboards and filters with other users, groups and roles.

Users/Groups:

jira-administrators
jira-servicedesk-users (If installed)
jira-software-users

Manage Group Filter Subscriptions

Ability to manage (create and delete) group filter subscriptions.

Users/Groups:

jira-administrators
jira-servicedesk-users (If installed)
jira-software-users

Bulk Change

Ability to modify a collection of issues at once. For example, resolve multiple issues in one step.

Users/Groups:

jira-administrators
jira-servicedesk-users (If installed)
jira-software-users

Browse Archive

Ability to browse all archived issues.

Users/Groups:

None (empty)

Evolution of Jira Design

A better navigation for Jira Cloud is coming soon! While we wait I thought it would be fun to dig up some old screenshots and take an unofficial and outsiders look at how the Jira interface has changed over the years.

When Jira was first released in 2002, it was purely for software development. But these days, all kinds of teams, like Legal, Marketing, HR, and IT, use Jira to track their work and their team’s “to do” list. Jira is useful for any industry and it’s not just for software development anymore!

The modern Jira experience is much different than what launched in 2002. Jira has evolved into different application types and different deployment methods. You can choose between Jira Core for business teams, Jira Software for development teams, and Jira Service Desk for support teams. You can also choose Jira Cloud (Atlassian hosted), Jira Server (hosted on-premises, in a data center with your other internal applications, or in a Cloud server environment like Amazon AWS), or Jira Data Center (also self-hosted but built for mission critical environments.)

It’s no surprise that the application’s design, look, and navigation has changed drastically over the years. Here are a few examples of the visual evolution.

In the Beginning

In 2002, Jira looked just like all the other web applications did at the time. As a web developer, I remember web application design closely mirrored desktop application design. It felt like developers were porting their applications to “web format” and wanting them to behave the same way as the PC versions did. User interface standards were just emerging. Websites were mostly grid based and layouts were in box or table format. In the Jira 2002 screenshot example you can see the familiar “logo in the top left header” standard that we all still expect today.

Jira circa 2002. Source: Happy Birthday to the Atlassian Community

In 2007 the logo and header changed slightly but the overall layout remained the same. The issue screen doesn’t yet have the right sidebar to display people and date fields. This design reminds me of what you see today when you export Jira filter results for printing.

Jira circa 2007. Source: Atlassian Marketplace

In 2009 Atlassian acquired GreenHopper which added release planning, burn down charts, and many of the agile features we use today. I still remember installing GreenHopper as an app and when “Agile” was a link in the top nav.

Into the Cloud

In 2011, Atlassian created a cloud-based version of Jira. It looked and functioned just like the self-hosted version. It was originally named “JIRA OnDemand” and the on-prem version was called “JIRA Download.” The names were re-branded in 2014.

Also in 2011, the Jira admin interface received a new project-centric design. I’m very thankful for the quick nav and keyboard shortcuts. I use the “gg” shortcut daily to move around the admin area.

Originally named RapidBoards, Scrum Boards graduated from the labs sandbox and became a standard feature in 2012.

Boards circa 2012. Source: Jira Server 5.10 release notes

Just two years later, the board design looked more polished with assignee avatars, different placement for priority icons and estimates, and improved spacing.

Boards circa 2014. Source: Form nimble agile teams

In 2012, the Atlassian Design Guidelines (ADG) were published to unify the customer experience across products. Hooray for consistency and standards! This meant the typography, spacing, and layout in Jira would be similar in Confluence. Jira 6, released in 2013, was the first “ADG compliant” version.

In 2013, the workflow designer was rebuilt in HTML 5. I remember when HTML 5 was the latest and greatest thing in web development! We all hoped it would replace Adobe Flash. Flash support officially ends in Dec 2020, but I haven’t seen a Flash-based website in years.

Back in 2013, all the workflow statuses were one color. We didn’t see different status categories, colors, or lozenges until version 6.2 in 2015. Different status colors helped end users understand whether they were in the beginning, middle, or end of an issue’s life cycle.

Custom status icons were also eliminated in 2015. Anyone remember those? I don’t think anyone misses them.

Workflow Status Icons

New Designs for new Application Types

In 2015, Atlassian split Jira into two application types: Jira Core and Jira Software. Core featured a simplified interface aimed at business teams. Software retained development-specific features like versions, sprints, and dev tool integration. In the Jira Core screenshot below there are few links in the left nav.

Jira Core circa 2015. Source: Say hello to Jira Core

As the applications diverged, sometimes new features were built in one type but not in the other. For example, Jira Cloud got a new visual roadmap feature and Jira Data Center got archive abilities. Design differences emerged and even some terminology changed. Cloud has a global permission called “Share dashboards and filters” but the same feature in Server is named “Create Shared Objects.” All these small differences are certainly challenging for me. It’s harder to use both application types at the same time and to keep training materials up to date. Even Atlassian has to maintain separate sets of documentation.

In 2016, the atlassian.design domain was registered to house their design principle documentation and brand information. Their style guide is a fabulous example for other organizations to follow. I especially like how easy their logos are to download and the “don’t do this” logo crime samples.

Also this year mobile Jira apps for IOs and Android were launched with their own platform-specific features and design.

Jira Android App. Source: Jira Software for Android has landed

New Jira logo

In 2017, Atlassian re-branded their entire corporate identity introducing a new logo, individual product logos, and renaming “JIRA” to “Jira”. Branding modifications are inevitable as companies grow and change. This is the fifth Atlassian logo change in 15 years. There’s a great graphic showing the logo evolution here. The new logo symbols feel multi-dimensional, fresh, and modern. It will be a long time before I can update every instance of “JIRA” to “Jira” in my book and on my website though!

Jira Cloud UI Overhaul

Also in 2017, Atlassian departed from their previous interface strategy. They announced “Jira Cloud will get an updated look and feel, including a collapsible sidebar navigation and enhanced search, to help your teams get things done faster.” The new nav was completely different from the top horizontal navigation in Jira Server and in previous Cloud versions.

I had trouble finding my way around and noticed more clicks were needed to get to some areas. The large left side bar commanded a lot of visual space. It was collapsible but you’d need to expand it again to access certain links. Sometimes the navigation loaded after the page contents loaded. Most annoyingly, the nav’s vertical scroll bar made it hard to print or screenshot pages. This navigation reminded me of designing with HTML frames in early 2000.

Source: Your teams are getting better navigation in Jira Cloud

In 2018, Atlassian took inspiration from the Japanese, Taiwanese, and Chinese bento box to redesign the Jira Cloud issue view. This design divided and grouped key actions and information, much like how rice, meat, and vegetables are separated in individual portions.

Also In Jira Cloud:

Workflow transitions were simplified. They ware displayed vertically and at the top of the right sidebar.

The separate “view” and “edit” screens were collapsed into a single screen. As such, there’s no “Edit” button and and all fields received inline edit capability.

New search capabilities were added. A keyword search very quickly returned recent issues, boards, projects, and filters. I found myself wishing I could enter simple queries in this search bar.

Clicking an issue from a board opened it in an overlay. When you closed the issue, your board was still there in the background.

Joining the Next Generation

In 2018 Atlassian introduced the concept of next-gen projects for Jira Cloud. This special project type is scheme-less. Project settings aren’t shared and settings don’t impact other projects. The simple configuration interface lets end users quickly create new projects on their own. Read my thoughts on next-gen projects here. Another Cloud feature, Agility boards were also introduced.

The Next-gen interface for adding custom fields and organizing them on screens is simple and intuitive. (Left screenshot below.) But I find the issue screen itself unbalanced. (Right screenshot below.) Most of the fields are stacked on the right side. When there are a lot of fields, they are collapsed and you have to click around to find them. Without a long description, attachment, or comment list, there’s a lot of unused white space on the left.

*Jira Cloud Next-gen Project Configuration*

Also in 2018, Atlassian split their design guidelines, creating one version for Cloud and one version for Server. The Atlassian Design Guidelines version 3 was published and workflow statuses received new colors.

2020 and Beyond

The new Jira Cloud horizontal navigation launches in March 2020! I’m looking forward to returning to Jira’s navigation roots and what I’m used to. As another user put it “What’s old is “new” again?” Yes, it appears so and I’m very happy about it. Since I use both Cloud and Server, I’m also glad that the nav will be similar again.

Change is the only thing that’s certain. We must all learn to work with it and retrain ourselves and our end users when necessary. I haven’t loved absolutely every change Atlassian has made, but every change is an opportunity (either for me or for them) to learn something new. I’m looking forward to the changes in 2020 and beyond.

While you’re waiting for the new Cloud nav to arrive in your instance, here are some early screenshots of the latest look and feel.

Update:The experience was fully delivered to all new and existing applications in June 2020. As of September 2020, the old navigation is no longer available for users to switch back to.

System Dashboard
Project Settings
New Search Bar
New “Your work” Page

Like Atlassian history? Also read: Summit Through the Years and Jira Cloud Navigation Comparison

Jira Next Gen-Projects: From the User’s Point of View

I’ll admit that I didn’t expect to like next-gen projects, Atlassian’s answer to making Jira more simple, and creating self-contained projects that won’t impact the performance of your entire Jira instance. First off, I felt vaguely resentful of the timing – just as I’m finally figuring out the complexities of Jira, they come out with a “Dummies” version. Second, I’m not a drag-and-drop type of person. I learn through language, by hearing and reading. I tend to find tools built for visual learners to be imprecise and a bit annoying. But I decided to put my reservations aside and create a next-gen project. Here’s what I found.

The Great Things About Jira Next-Gen Projects

Set up was fast and easy. I had mapped out my project on paper so it was pretty quick to set up the issue types I wanted. I added and ordered the fields I needed right there as I was creating the issue types, creating custom fields and adding choices to my dropdowns – all on one easy screen and with no schemes to worry about.

I set up my screens at the same time that I created my first issues. Again, it was simple and intuitive. I simply clicked on Configure Fields on the Issue Create screen and now all of the fields I wanted are there.

These are two big advantages of next-gen projects. Set-up was simple and it’s really, really nice to know that I can create a project specific to my needs, without worrying that I’ll screw things up for everyone else.

And the Risks…

Time will tell if those two advantages also turn out to be the biggest disadvantages of next-gen projects. While setting up the next-gen project was certainly easy, I wonder if the simplicity itself may cause users to miss out on something. When you wade through issue type schemes, field configuration schemes, etc. you are getting the benefit of learning from those who have gone before you. Seeing the fields that are used in other projects may trigger you to think about aspects of your project that had slipped your mind, aspects that may not be relevant to you, but are crucial to other users. I’m curious to see if, as my project evolves and I make needed adjustments, it will end up looking a lot like one of the default schemes.

While it’s nice to be able to create a project knowing that you won’t mess up what anyone else is doing, it also implies a higher level of responsibility. If this is my standalone project, with my issue types and my custom fields, then it’s my job to get them right and to clean up the mess when I get them wrong. It will also be my job to deal with maintenance – to keep the project clean, to make needed changes, to clean up the data when garbage gets entered. Simplified maintenance is one of the key advantages of shared schemes. It will be interesting to see, as use of next-gen projects grows, if maintenance becomes an issue. Atlassian has said that they will soon be providing the ability to extract next-gen project settings into their own template, and link two or more projects’ settings together. (However, they also say that if you want to share configurations, it’s best to go with a “classic” project.)

The other limitations of next-gen projects relate to them being new. Atlassian has published their roadmap, letting us know when features we’re used to using in traditional projects will become available for next-gen projects. App developers will also need time to catch up. For instance, ProForma – which allows you to create forms that embed in Jira issues – does not yet work for next-gen projects. I think I’ll create an issue for that.

Are You Ready for the New Jira?

Atlassian’s introduction of “Next-gen” projects in Jira Cloud represents a paradigm shift in the way they build and deliver features. They are moving from a massive monolith of code to microservices structure. In their recent webinar “The new Jira begins now” Atlassian shared that they operated from a single code base for almost a decade! I used to work in an environment of large and aging software, so I know how challenging it can be. Your team is ready with a new feature, but you can’t release it until all teams are ready to also ship their code. Or, your team changes one variable and it breaks everything for all the other teams. No fun!

It sounds like Atlassian is now able to build software the way I wish we could have back then. They are leveraging “feature flags” to better control rollout and delivery. For example, they can deploy code in an “off” state and turn it on later. Additionally, they can turn code “on” for a subset of customers, or launch features in a controlled and measurable way.

Sounds great! If I didn’t love Jira consulting so much, I might be tempted to get back into software development.

What does it mean?

So what does this shift get Atlassian? It means the freedom to re-architect, try new things, and build a new project creation and management experience in Jira Cloud. The Next-gen projects launched without expected features, like Epics, Sub-tasks, and required fields. But with their new release capabilities, features like these are shipping quickly.

Atlassian has shared their development roadmap, which is a most welcome addition. I always appreciate any insight I can get!

Do we want this?

Atlassian says we do! They surveyed customers and learned that teams want flexibility and that centralized administration creates bottlenecks. Waiting for your Jira admin to create your new project doesn’t scale. I can understand that and I know users and customers have waited on me to perform an “admin only” task.

Atlassian also says admins have expressed the desire to delegate some of the more mundane tasks so they can focus on more important and impactful work. I get that too. There are some things I don’t love to do, like managing group membership, for example. As long as there are no collisions, impacts to other projects, or messes for admins to clean up, delegated administration could be very helpful.

Key Differences

Atlassian uses the word traditional to describe the original projects we’re more familiar with. Traditional projects utilize configuration schemes. The new Next-gen projects are “schemeless” and totally independent. Atlassian says that future Next-gen projects will have template abilities. I’m interested to see how that differs from the traditional project’s concept of “Software”, “Service Desk”, and “Business” project types.

Not only are Next-gen projects created by different users but the creation process differs too. I have a very specific set up process for traditional projects and even a new project configuration checklist. I’m careful to complete steps in a specific order to avoid extra clicks.

With Next-gen projects, the configuration order is different. It is:

Create the project and select permissions
Create board columns
Add users
Create issue types
Create custom fields
Connect to other tools

It’s strange to me to configure a board before the workflow, but if the workflow is based on the board (not the other way around) then it makes sense. Atlassian’s use of Jira is definitely more board-centric than my own. I’m not a heavy board user; dashboards are more helpful to me. But that could be because I used Jira before boards had today’s list of features.

The Next-gen boards continue to evolve and improve with new features like:

bulk issue update abilities,
column display limits,
background color changes for “flagged” issues,
rules – like auto assignment based on status change,
and visual integrations with dev tools.

Finally, Atlassian shared that the new project model improves performance, stability, and helps prepare them for the next decade of software development.

What will happen to “traditional” projects?

Will development for “traditional” Jira Cloud projects continue? It’s uncertain. It sounds like all these new cool features are only for Next-gen projects and won’t be back-ported. That’s sad but understandable. Essentially they would have to develop the same feature twice, once for each code framework. That doesn’t make a lot of sense to do – unless customers are clamoring for it.

How do Next-gen projects impact apps and app developers?

To answer this question, I asked ThinkTilt, the maker of ProForma, a forms and custom fields add-on for Jira Server and Jira Cloud.

ThinkTilt said that the Next-gen projects have quite an impact for them and other Marketplace app developers. Atlassian is still working on supporting apps in the new projects. Some screens, like the project configuration screens, didn’t appear until recently, meaning many apps didn’t work at all for the new project type.

The next step is for Atlassian to update their APIs so app developers can access the new features of Next-gen projects. Today, apps can see what has been configured for a project, but there are no abilities yet for doing more, like adding or editing the configuration. When all the Atlassian pieces are ready, app developers will need to update their apps to make them work well.

Expectations

What are your expectations of Atlassian and their new Jira Cloud experience? What are the expectations of your Jira admin team or your users? Share your opinions in the Comments section below.

Learn more about Next-gen projects at: http://atlassian.com/get-next-gen

Keeping It Clean: Containing Jira Custom Field Growth

You did it! You audited, deleted, merged and substituted and now your Jira instance only has the custom fields it should have. Congratulations – that was hard work! Pat yourself on the back, eat some chocolate, do whatever you do to celebrate. Then take a deep breath and get ready to go to work again, because now that you’ve got your Jira instance nice and clean, you need to take a few steps to keep it that way.

The good news is that custom field clean-up isn’t like laundry, where you never really get it all done. Once you’ve cleaned up your instance you can put processes in place to keep it that way.

When to Create a New Jira Custom Field

There are times when creating new custom fields is justifiable, but you want to make sure it’s really necessary before you create one. Here are a few things to consider:

Is it needed? In tech, we’re often tempted to do things just because we can. That’s not a good enough reason to create a custom field. When users request a new field, ask them for the business case for collecting that piece of data.
Does the data need to be in its own Jira field? Will this data be queried or reported on later? If not, could you just as easily capture it as a ProForma form field? Or prompt users to include it in the Jira description field?
Would the field be used by different teams across the organization? Jira assets should be shared whenever possible. Making usability across multiple teams one of your criteria will help contain custom field expansion.
Is there a Jira system field that you can use? Make use of existing options. Teams can set their own protocols for what to include in a summary field versus a description field, or create a project-specific plan for how they will use the label field, etc. Encourage users to use what’s there before asking for more.

In order to have the above information whenever a new field is requested, you’re going to want to implement a process for requesting new custom fields. ProForma offers a template that users can use for requesting custom fields and Rachel Wright offers a new custom field request worksheet.

In the Jira Strategy Admin Workbook, Rachel also recommends publishing a list of currently available custom fields. This encourages users to look and see what’s already there before requesting something new.

Custom Fields and Next-Gen Projects

Note that these processes assume that you’re working the old-fashioned way, with traditional, classic, old school Jira projects. If you’re using Cloud, then you may have empowered your users to create “Next-gen” projects. Next-gen projects are pretty new and it’s fair to say that the jury is still out. The idea is that users will be empowered to create their own projects, issue types and custom fields. These projects are self-contained and the inevitable balloon of new custom fields should not impact Jira performance. However, there’s nothing to prevent users from making errors such as misspellings and incorrect field types – errors which they may, or may not know how to clean up.

So what are our recommendations for managing custom fields in Next-gen projects? First, the new project capabilities are configurable. The default setting is “anyone,” but you can decide which groups to grant this power to. Once you do decide, give these newly empowered users some training, which should include when to and when not to create a new custom field. Initially, alternatives may be more limited for Next-gen projects than for classic Jira projects. Like many Jira apps, ProForma doesn’t yet work with Next-gen projects, but as use of Next-gen projects expands, options will too.

Will be exploring the possibilities and impact of Next-gen projects in upcoming articles. In the meantime, enjoy hanging out in your nice clean Jira instance!