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:

  1. Create the project and select permissions
  2. Create board columns
  3. Add users
  4. Create issue types
  5. Create custom fields
  6. 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.


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:

Different Jira Issue Types

What is the difference between an Epic, Story, Task, and other issue types?  Which Issue Types are standard and which are custom?  Which issues types are added by Jira Service Desk?
Continue reading “Different Jira Issue Types”

How to Audit Your Jira Custom Fields

How many custom fields do you have?  For most of us the answer is: too many!  With research and diligence, you can clean up your duplicate and unused custom fields and get your count down to a manageable number.

The first step in any clean up process an audit.  You need to understand what fields your application has and how much that differs from the default Jira set up.  Use the free Jira Clean Instance worksheet to compare your application to a default installation.  Use this to get a count of all your standard and custom fields.

There are a few ways to approach your audit.  You can do a manual examination, use an add-on from the Atlassian Marketplace, or use a combination of both.  For helpful add-ons, check out:  Cleaner for Jira, Custom Fields Usage for Jira (Server only), and Admin Tools for Jira (Server only).  Jira Data Center users can leverage the built-in Custom Fields Optimizer.

While these plugins can help tremendously with your research, only a human can determine the value of a specific custom field for your organization.


Next, make a list of all field names and types for examination.  Copy the all the fields on your Custom Fields admin page and paste them into Excel or Confluence.  Use the free Jira Custom Field Audit worksheet to enter your data, collect your research findings, and total the fields to remove.  Now that you have the list, start researching and classifying each field

First, flag the fields created by Jira.  These fields are likely needed, locked and can’t be removed.  Don’t spend time researching these.

Second, flag the fields created by an add-on or plugin.  When plugins are deactivated or uninstalled, their custom fields remain.  You’ll need to determine if data in those fields needs to be retained.

Finally, flag all the fields created by admins.  These will require the most research.


It’s time to find out everything you can about each add-on or admin created custom field.  Start by determining which plugin created which field and add this information to your spreadsheet.  Look for clues in the following places:

  • Jira’s application audit log,
  • the add-on audit log,
  • the field’s description on the “Manage add-ons” admin page,
  • login as an end user, use the add-on, and see which fields are displayed,
  • or check the plugin’s documentation.

Next, research the remaining admin created fields.  Are there duplicates, misspellings, or poor naming choices?  Are any fields associated with unused projects?  How is each field used today?

Determine the scope of each field’s use by looking in the following places:

  • the Custom Fields admin page,
  • on screens,
  • in workflow behaviors (conditions, validators, and post functions),
  • and in user JQL queries.

TIP:  For each field, do a JQL query and note how many issue were found, how many issues are in unused projects, and the business value of the data returned.  Just because data is returned doesn’t mean it’s still useful!

Finally, check how many users have saved queries using the custom field.  If you have Jira Server or Data Center, and read-only access to the Jira database, you can get this information from the “reqcontent” column in the “searchrequest” table.

Next Steps

Now that you’ve uncovered some unneeded fields, it’s time to take action!  We’ll cover the clean up process in an additional article in this custom fields series.

Take the Jira Custom Fields & Clean Up Course!

Learn how custom fields work, how to determine when a new custom field is warranted, and how to clean up custom fields added by application admins and add-ons.
Take the 20 minute online course

“Jira Admin Scary Stories” in Columbus and Palm Beach

Zombie Rachel Wright

In honor of Halloween, Rachel Wright will present scary Jira admin stories at the Columbus, Ohio Atlassian User Group on October 9, 2018 and the Palm Beach County, Florida Atlassian User Group on October 23,2018.  Hear stories of spooky security, freakish custom fields, and the potential horrors of user-created projects and issue types.  These stories are based on the gruesome mistakes in the Jira Strategy Admin Workbook.

Atlassian Users Groups are where users meet, learn, network, and share best practices. The groups meet locally, all over the world, on a quarterly or more frequent basis.  User Group members are newbies and veterans who like to “talk shop” about Atlassian software, about Agile development, and about related business topics.  At these events, you can network with your peers, share solutions, meet Expert Partners, get special content from Atlassian, and enjoy a beer.

Will you be in Columbus on October 9 or Palm Beach on Oct 23?  Join us, join the User Group in your city, or start a group!

Users Create Jira Projects. A Good Idea?

Atlassian just announced a new feature for Jira Cloud users:  anyone can create a project, issue type or custom field.  No need to engage the admin team!  When I heard this at the Summit user conference, I cringed at the thought of cleaning up the new messes that end users will inevitably create.  I’ve spent many years fixing poor decisions made by application admins and now end users, with even less knowledge and application management experience, are unleashed on the config?  Yikes!  A fellow conference attendee sitting near me exclaimed “but I just got our application cleaned up” and let out a large sigh.  Atlassian also announced the 2,000 Cloud user limit is upped to 5,000 users.  Now even more people can create a bigger mess!

President Jay Simons: Open & Fluid

A theme throughout the conference was “open.”  It means being open in your communication, your intentions, open to new ideas, and more.  I enjoyed that talk and I took it seriously.  So, I’ve challenged myself to reject my original pessimism, embrace this change, and find the good in it.  I spoke with a Jira Software representative at Summit but initially that didn’t ease my fears.  It wasn’t until I tried out the new project creation feature that I calmed down, the fear subsided, and I saw the potential.  I can appreciate Atlassian trying to simplify a complex process and free up time for busy application administrators.  This also aligns with the concept of added workflow and screen editing abilities introduced in Jira Server versions 7.3 and 7.4.  And yes, I was scared of those changes at first too.  But guess what?  The world did not explode and I didn’t have to fix too many botched workflows.  😉

Good to Know

“Create independent projects” Global Permission

These new project abilities are configurable.  It’s a global permission, so you can decide which groups receive the power.  You don’t have to use the default “Anyone” setting.

Projects created with this method are structured totally different from previously created projects.  These projects are independent entities that don’t impact or share schemes with the other types of projects.  I know what you’re thinking:  sharing schemes is “the way” to easier maintenance!  It will be interesting to learn how best to manage projects built in two very different ways.

Quick Tests

I created a project of this new type, created a new issue type, and a created a new custom field.  Since these objects are decoupled from global settings, there’s nothing I’ll actually have to clean up later at the application level.  For example, there’s no new entry on the Admin > Issues > Custom Fields page.  I wonder how these objects are stored?  Since this is Cloud, I can’t access the database to see.

The new issue type creation wizard prevents you from creating an issue type that already exists, which is great news.  See screenshot.  But, it can’t prevent other “human caused” problems, like dupes (think “Bug” vs. “Defect” in the same project), plurals, and misspellings.

Duplicate Issue Types

As a test, I created a new issue type and called it “Epics” (with an “s”.)  Now the test project has both “Epic” (which has the special association behavior you expect), and “Epics” which is simply a standard issue type.  It’s not pretty but luckily this unfortunate action is constrained to the project where the issue type was created.  All users will see both options in the JQL search however.

Poor “Date” Type Choice

I also created a custom field with the new fields designer feature.  I created a field called “Date” and selected the type as “Text” instead of “Date” like it should be.  It’s a common mistake and end users are bound to make it.  In the screenshot, you can see my lovely new field on the right and its purposefully ridiculous value.  Again, since this unfortunate decision is constrained to the project, maybe it’s not too much of a problem.  This team won’t be able to properly sort or query data in this field, but it’s not the end of the world.

One Observation

This leads me to my only real gripe.  Atlassian also announced a project archival feature (yay!), but it’s only for the Data Center version of Jira.  I think the Cloud version needs this feature now more than ever!

What happens when all your users create their own personal projects for every little item on their “to do” list?  How does an application admin clean those up when they aren’t needed or when the creator leaves the company?  What happens when you visit the “all projects” list and there are 500 more entries than there were yesterday?  How does a user know which “Marketing” project to file their issue in, now that there are 5 to choose from?  I’m not sure there’s a good way (yet?) to manage these scenarios.  A bulk clean up tool is really needed.

Also, my Cloud instance is very small, yet very slow.  I know performance is improving and is a priority.  But I worry that adding all these extra elements (even the cool new stuff) could slow it down even more.

Being Open

After my very brief look into the new features, I’m willing to be open.  Change is hard but I’m choosing to embrace it.  New concepts and features certainly deserve a fair shot.  It will be interesting to see what, if any, issues arise and how application admins can best address them.

What do you think?  Are you open to this change?  What are some pros, cons, scenarios, and considerations?  Post your opinions in the comments field below.

Learn more about these features in this post or watch the Summit keynote starting at 1:02:50.

How to Make Atlassian Summit Suspenders

The Problem

Summit Flair

After attending every Atlassian Summit user conference since 2013, I’ve acquired a lot of buttons, or “Summit flair” as I call them.  I’ve run out of room for them on my conference lanyard however, and honestly, they were getting heavy!  So this year, I needed a different solution.  How could I display my flair?

The Solution

I thought for a while and came up with nothing.  Then, somehow, I thought of suspenders!  Now, being a girl, and never being a farmer, I’ve never worn this contraption.  But I asked my boyfriend where I could get them and we found some in the men’s section at Walmart.  $6.50 USD later and I had a craft project!  Follow along below to make your own.

How To

Step 1:  Configure suspenders
Realize you don’t know how to wear suspenders and watch many YouTube videos until you can successfully adjust the length.  Learn that women should wear thinner versions.  Ignore that tip; it won’t be the first time you’re not “on trend” in fashion.  PS – A wardrobe of only Atlassian t-shirts is always “on trend”!

Summit Materials

Step 2:  Gather Summit materials
Your Summit hording pays off!  You have 4 lanyards from previous Summits ready for a second life.  Realize you’ve collected far too many Atlassian pins though.  Choose your favorite ten, give the other twenty a hug, and put them away.

Step 3:  Gather craft materials
Realize that you travel full-time in an RV so craft materials are scarce.   This is the one time where a can of WD-40, a drill, and awning repair tape won’t fix it.

Look in the tool box and the office supply drawer.  Find a glue stick, a needle, less than a yard of thread, scissors, permanent markers, a seam ripper (why is this needed in an RV?), a label maker, safety pins, a putty knife, and something called “Super Weld.”  Put half of that stuff away because it won’t help this project.

Step 4:  Get crafty
Use the scissors to cut the lanyard fabric from its hardware.  It frays immediately.  Run back to the tool box and find the “Super Weld.”  Use it as super glue on all the lanyard ends.  Do it quick because it’s unraveling!  Try not to super weld fingers together.  Use the needle and scarce amount of thread to affix the lanyard to the suspenders.

Realize that you haven’t sewed anything since seventh grade home economics class.  Remember?  You attempted to make jean shorts.  Floral.  Denim.  Shorts.  Horrific!  How did you even pass that class?

Step 5:  Add finishing touches
With the pins and two pieces of lanyard on the front, it’s time to decorate the back.  People standing behind you need to know about your Atlassian devotion too!

Resist the urge to glue the remaining lanyard with the “Super Weld.”  Sew a few stitches with the remaining inches of thread.  Curse loudly as you struggle to knot the thread by the dim light of a lantern.  Only stab yourself with the needle once.  Impressive!  If this Jira consulting thing doesn’t work out, maybe you can be a seamstress?

Step 6:  Finish up
It’s way past your bed time but you have a completed an almost respectable attempt at custom suspenders.  Costs, injuries, and permanent damage to the RV is minimal.  Congratulations!  All that’s left now is to put them on and get yourself to Atlassian Summit!

Find Rachel and Her Summit Suspenders

Will you be at Atlassian Summit, in Barcelona, the week of September 3, 2018?  Meet Rachel Wright and win her Jira Strategy Admin Workbook or one of 5 new training courses!  Rachel will be hard to miss with her custom-made Summit suspenders.  Find her in these locations.

Not at Summit?  Use coupon code SUMMIT for 15% off your order in the Strategy for Jira store!

Atlassian Summit Survival Guide

The grand Atlassian event of the year is approaching!  Use this guide to navigate Summit and make the most of your time at this year’s user conference.

Not at Summit?  Use coupon code SUMMIT for 15% off your order in the Strategy for Jira store!

Before Summit

  • Use the “Atlassian Events” Android or iOS mobile app to pre-plan which sessions you want to attend, but be flexible.  Continuing your conversation with that Expert partner or Atlassian employee may be more valuable than attending the next session.
  • Don’t be a slave to power!  Bring an extra battery or portable power source. Consider taking notes on paper.  You won’t want to fight for an outlet to recharge devices.  If you find yourself needing power, swing by the Atlassian Community or Certification lounges.
  • Be prepared to network!  Pack your business cards.  Don’t have work business cards?  See if your company has any “generic” ones you can write your info on.
  • Check the weather and the time zone in the conference city.  Bring a light jacket in case it’s chilly in the conference center.
  • Arrive the day before conference activities start.  Check in at the registration booth as soon as you arrive.  Avoid the long registration line on the first morning.
  • Walk the conference center, before it gets busy, to get a feel for where activities will take place.  If there’s a map, take a phone picture.

During Summit

  • Don’t try to work AND attend Summit at the same time. It is too hard to do both well.  Instead, turn on your “out of office” email autoresponder, set the expectation that you’ll be unavailable, and delegate your tasks to coworkers while you’re away.
  • Find the Atlassian User Group and Community lounge.  The user group leader from your city might be at Summit.  No user group in your area?  Find out how to start one!
  • Sessions fill up quick;  get there early.
  • At the event, login to a chat program so you can communicate in real time with your colleagues also at Summit.  Ex: “I’m going to the X session next.” or “Meet you at noon in the lobby!”
  • Write a quick note on the back of any business card you receive so you’ll remember how/if/why to follow-up later.
  • Pace yourself on day one and during Summit Bash!  It’s a long conference and you want to make it to the party.
  • Find Rachel and Her Summit Suspenders

    Atlassian feeds you a lot on conference days.  You won’t need to spend much money on food.

  • Meet Rachel Wright and win her Jira Strategy Admin Workbook or one of 5 new training courses!  See:  Find Rachel  She’ll be hard to miss with her custom-made Summit suspenders.

After Summit

  • Try to leave the day after Summit activities conclude.  It’s no fun leaving early to catch a flight.
  • After Summit, the major session recordings are available online.  Don’t worry if two sessions you want to attend happen at the same time.
  • Leave room in your luggage for the return trip.  You will acquire new goodies!  (At least a few new t-shirts.)  Some die hard collectors even bring an extra bag or plan to mail back items.
  • Share your notes and the most important information with team members who could not attend.
  • If eligible, submit your travel expense report.

Also see: How to Get your Boss to Send you to Atlassian Summit User ConferenceAtlassian Summit Travel Guide, and Summit Through the Years.

Rachel Wright is an consultant and an Atlassian Certified Jira Administrator.  Rachel also uses Atlassian tools in her personal life for accomplishing goals and tracking tasks.  Her first book, the “Jira Strategy Admin Workbook“, was written in Confluence and progress was tracked in Jira!  Follow her on Twitter at @rlw_www.

Meet the Author: Atlassian Summit in Barcelona, Spain

Find Rachel with her Summit suspenders

Will you be at Atlassian Summit, in Barcelona, the week of September 3, 2018?  Meet Rachel Wright and win her Jira Strategy Admin Workbook or one of 5 new training courses!

Rachel will be hard to miss with her custom-made Summit suspenders.

Find her and win in the following locations:

Also spot Rachel walking the conference floor, attending sessions, and enjoying Summit!

Find Rachel Wright at Summit
Not at Summit?  Use coupon code SUMMIT for 15% off your order in the Strategy for Jira store!

The Jira Strategy Admin Workbook is different – it’s not documentation. It’s over 150 recommendations that stem from years of cleaning up horrible Jira configurations.  This book includes 32 real life examples of what NOT to do, over 50 worksheets to get you organized, and templates, code snippets, and wording samples to help you establish and streamline processes.

Summit is the grand Atlassian event of the year.  With the palpable enthusiasm of the employees, the knowledge of the presenters, and the immense networking opportunities, this is the place to experience all that is Atlassian.  Add the next annual event to your calendar now.  Visit for details.

Retrospective: Boondocking with Jira and Confluence

Menu:  Intro | Day 1-2 | Day 3-4 | Day 5-7 | Retrospective

Retrospective in Confluence

In the software development world, each time you complete a project, you review what went well and what you could do better next time.  It’s called a “retrospective” or a “post-mortem.”

We did a retrospective on our boondocking adventure, using Confluence’s template.  These are the results.

What We Did Well

  • Excellent preparation, research, and pre-event testing
  • Used Jira and Confluence to plan and track the adventure
  • Didn’t ruin or damage any critical systems (except for the battery)
  • Bought the right equipment (generator, drill pump, water tank filler attachment)
  • Built a structure in truck bed to transport and store gas and water containers
  • First try was at a large event attended by experienced boondockers
  • Had fun and connected with new people
  • Stayed close to town in case other supplies were needed
  • Managed and conserved water well
  • Parked facing the best direction for temperature control
  • Planned for known cell reception issues
  • Have future plans for solar equipment

What We Should Have Done Better

  • Develop a use and charging schedule
    • Charge with generator more often
      • Took longer than expected
      • Requires us to remain onsite
      • Only possible during day hours
    • Recharge devices on AC (not inverter) power
    • Utilize existing USB and solar chargers
  • Understand the measurement for 50% battery draw (12.06 volts – see chart below)
    • Killed the battery
    • Battery may have already been weak from age (no good baseline stats)
    • Failed to maintain needed distilled water levels
  • Failed to realize cell booster requires constant electricity
    • Device is not generally reliable
    • If not attending an event, we would have switched locations
  • Neglected “day before” moving list
    • Was having fun and decided to do the “day before” tasks on the “day of”
    • Was rushing and made stupid mistakes
      • Closed slides out of order
      • Caused injuries:  Hit face with drill, cut leg on screen door (again!)
  • Remove hitch when driving on dirt roads (cleaning takes more time than removing)
  • Develop a better system for managing grey water levels
  • Spent more than normal on food and entertainment (due to social events)
    • Saved on camping costs however

Subsequent Mistake

Overall, we met our goals of living off the grid for one week.  By gaining boondocking skills and equipment we’ve enabled ourselves to camp in different types of locations.  City power, water, and sewer are no longer a limiting factor.  We also had fun networking with other full time campers.

We were so confident with our experience that we decided to try it again immediately.  We needed a one night stop between Pagosa Springs, CO and Santa Fe, NM.  We searched the online camping directories and decided on a free overnight spot, in a municipal park, near the half way point.  The location was excellent and we had the entire park to ourselves.   How could this go wrong?

We neglected to check the weather report.   RVs and travel trailers heat up very quickly, just like a vehicle does.   When it gets hot, you put our your awning, unfold your camping chair, and work outside until the sun goes down.  It’s not too bad if you also have a cold glass of iced tea to enjoy.

113° F (45° C) Temp

It’s Summer in the United States so we expected it to be hot – but not this hot!  The truck’s thermometer read 113° F (45° C) and the analog thermometer inside the RV read 106° F!  For the first time ever, the inside of the RV was just as hot as the outside.  There was no escape and no amount of iced tea provided a reprieve.  We had to sweat out the afternoon and night and learn a hard preparation lesson.  I always check the weather report for storms and high winds, but never for excessive heat.  The learning continues…

I hope you enjoyed following along on our adventure and alternate use of Jira and Confluence.  Atlassian tools can track anything!  I encourage you to experiment with alternate uses from both your work and personal life.  Happy Jira issue and Confluence page creating!