Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

add columns to backlog

how can I see more columns in backlogs?

8 answers

2 accepted

19 votes
Answer accepted

What do you want from a column in a backlog?  A backlog is a list of issues to be prioritised and then drawn into a sprint, or a list of stuff that needs doing (Which, once you've started to look at it, by definition, isn't backlog any more)

Perhaps they are looking for useful information to help them prioritize items like story points or business value.

Like # people like this

I am also wanting to know how to do this.  I need it to help prioritize / categorize the tasks in the backlog.

Like # people like this
Deleted user Aug 31, 2017

I would love to see which issues are in which state of the workflow. It would be awesome to see if something is in progress (rolled over from the previous sprint) and if something is blocked. 

Like # people like this

If you're using Kanban backlogs, you can put multiple status into it.

I would love to see this added as well. Adding custom fields makes the rows too tall, and you can't see as many issues per page.

Like # people like this

Same here. I would like te see the status of an issue. 

Like # people like this

I would like to see status too.  Due to using the back log to prioritize, I want to make sure the top items are being worked on.  Currently I have to flip back and forth.

Like # people like this

I want my account managers and implementation specialists to have one simple, clear view of cases of interest. This one simple view should answer all their important questions:

1)  See/identify the cases they have reported, or cases where they are the case owner. Today they only see the current assignee.

2) Our process/project has a step that is called "ready to develop" (basically requirements done). It is really important that case owners and persons of interest knows that they have work to do before our scrum team has all the info they need to actually develop.

3) We use a field called "Release notes", to summarize the business value of a case. Release notes are then send to our customers. Case owner is responsible to provide release notes according to our routine. As a product owner, I'm responsible to make sure all case owners provide good release notes. Me and product owners have no way to get a good view of the release notes.

4) Where in the process is the case I'm interested in?

Hello everyone,

We understand the necessity of some teams to have more columns/fields in the backlog as a better way to filter/prioritize issues before adding them to the Sprint, and that's why we created the following suggestion to get all our customers feedback and ideas to make this feature better:

Ability to re-order the backlog from Issue Navigator using Drag and Drop. 

On the other hand, the action of simply adding new columns to the backlog view might add more complexity to a feature intended to simply list the items scheduled for the next Sprint. This would cause more confusion for the teams that use that feature as it was intended to work, and break the whole Scrum methodology that should be applied to a short-term backlog.

That being said, we have Advanced Roadmaps for Jira Cloud support as an option today that can help with the planning of a long-term backlog and might work well for most of the scenarios provided in this thread. Feel free to take a look and check if that option works for your team! 

Also, feel free to vote/watch and give your feedback on the suggestion mentioned above, as that is our direct channel to contact the product managers of Jira applications.

Best Regards,

Petter Gonçalves - Atlassian Support

Dear Petter,

I believe most of us know what they want to achieve and plan to add just a few columns that are really needed.

We for example would need an additional column to support the planning with our departments: when requirements are not specified clearly, we still need a rough estimate and would use a separate field for that to be shown in the backlog. 

Like # people like this

I want to add columns to my Backlog view because I want to add columns to my Backlog view. Limiting what users can do is not conducive to productivity in my opinion.

The reason for status is before an item can be added into a sprint it needs to be in Ready for Development.  The status for us prior to that is Needs Information and Ready to Refine.  Then once an item is in the sprint you can see the status on the "Active Sprint" screen, but you then can not see the priority.  With multiple developers, sometime the highest priority takes longer, so its nice to use the backlog view to see priority and status. 

Why is this accepted? We'd also like to see the status in the Backlog to know which items still need further refinement (specification) and which are ready to be drawn into a sprint (even if they do not have a high priority).

It's accepted because the answer (and/or its comments) are a good explanation of the current way things work, and why.

Jiras design for the backlog list indicates that Atlassian knows very well that you need an overview of the backlog AND the sprints, in order to plan and visualize the backlog.

But you're telling me that we don't need any information to plan? And if we need information, all companies, teams and processes need the same information?

Like Barend Scholtus likes this

@Nic Brough _Adaptavist_the only answer was yours "What do you want from a column in a backlog?"

This is not an answer. I'll try to clarify the request: When you click on an issue in a backlog, the right panel shows all the details from that issue. That panel only exists because sometimes it's important to see details of an issue in a backlog.

Now, imagine you want to see details of several issues at once, to help you prioritize them. This is what columns in list views are for.

Like # people like this

One of the big weaknesses of the Khoros (nee Lithium) system is that it does not let us comment on questions, we have to use "answer" when we want to do anything.  That, of course, includes clarification questions or comments that lead to a discussion.  This particular question is absolutely one that I would never have "answered" if I had the option to converse as a comment.

But I think that question still stands.  I, personally, cannot see any use for a column in the backlog.  What am I supposed to be differentiating between?  How would two columns help?

Anything that can help with prioritization should be a column. Eg assignee, estimate, epic, reporter, bug vs enhancement.

Let me reverse this question: Why would you want to hide this info?

Like # people like this

There's some misunderstandings here - the columns were interpreted as "columns" by some, but others, including you, thought the question was about "fields" (which are not columns").

If you have Jira Server, or your project is Classic on Jira Cloud, then you can add fields to the backlog display by customising the card view in the board settings.  Next-gen projects in Cloud do not have this function (yet)

Agree that there are misunderstandings. What we want are "columns", not "fields".
The "fields" implementation has the following disadvantages over "columns":

  1. You can only pick 3 of them.
  2. They appear on the 2nd row of each item, wasting vertical real estate (not very useful for wide screen monitors).
  3. There are no column headings. Eg I can see "None" "None" in my 2nd row. What does that mean? (It means this issue has no epic and no assignee, but you didn't know that).
  4. You can't sort by clicking on a column header. Yes, sorting can make sense in a backlog. Eg, you might want to see all issues belonging to particular epics.

What's disappointing about this is that Atlassian have already implemented this. Look at the "All issues" screen. On the top right, there's a dropdown called "Columns". It solves all of the problems above. If items could have a priority order in this view, I wouldn't need a backlog at all.

No.  In Jira Software, a column is a collection of one or more status to display for issues.

You are talking about fields, not columns.  Even though the issue navigator offers you "columns", it's not, it's offering you fields (there's a change request to get that corrected)

The best option you have at the moment is the fields you can add to cards.  They're not arranged in a columnar format because there's not enough space to do it that way in a backlog display.

Yes, I know that's the best option. It's not good enough (I've described why in 4 points above), which is why so many people have commented on this page. I'm not sure why you think there's not enough space. Clearly there is enough space, since that's exactly what they've done in issue navigator.

The issue navigator and backlog have differing amounts of space either side, and if you look over 99% of people's issue navigators, you'll see them scrollling left and right because there is not enough width for all the fields they have on the screen.

Doing that in the backlog would make it even worse - having the fields on a second line actually works significantly better.

Sounds like you're arguing for issue navigator to have a "2nd row for fields" feature.

But you can't understand that other people want issue navigator's "columns for fields" feature in the backlog view?

No, I'd like the issue navigator to stay single line.  What I'm saying is that the backlog and issue navigator are there for two different reasons.  The UI for the navigator works for searching and looking through issues, and should be single line, and I have control over what fields I choose to have there.

I don't want to be screwing around scrolling left and right all over the place, especially when I can't control the arbitrary fields that the board owner thinks are important, when I am trying to rank my backlog.

I understand you think you want loads of fields and single line.  I don't think that works for a shared backlog.

Of course you can control the arbitrary fields. They're your settings. Only the order of issues in the backlog needs to be shared, not which fields/columns you choose to show.

I am sorry, but you're wrong.  A backlog is a part of a board, which is a shared view, controlled and configured by the board owners.  If I am not the board admin, I cannot control the abitrary fields.  And that is correct because it is supposed to be a shared view with everyone looking at the same think. 

In the issue navigator, I can control the arbitrary fields, because it is my view.

Sounds like you haven't seen competing systems.
Azure DevOps Services (previously TFS), FogBugz, and a bespoke system I used previously all have user-chosen columns in their backlogs.

A backlog that doesn't allow users to select any columns is half-baked and inferior. It doesn't have to be that way.

Like # people like this

I have - and they fail because you have people looking at different views.  No-one I've seen using these (well) has different backlog views for different people.

In issue navigator, can you view issues in backlog order?

Of course you can.  "order by rank" is not exactly complex.

But apparently being able to *change* the rank in this view is complex. That's the ask.

No, it's not in the slightest bit complex.  Given a ranked list, change the rank by moving things up if they should be higher, and down if they are lower.

The issue navigator is not a backlog.  It is a list you have asked for.

If you want to rank things, use the functions that are intended for that.  That means, the backlog.  (Don't get me wrong, I think the issue navigator should allow ranking as well, but the issue navigator is part of core jira, not software, so you're into thinking about what non-software users might use it, and how not to break it for non-software users, and, and, and.  I really do think it should be done.  But I do see it's not as simple as we think it is)

And going back to the more recent point, when you're ranking stuff, you really really really do need to all be looking at the same criteria.

Everyone - please vote for this feature here:

I need a column that is between the backlog and the sprint.

Call it "Ready for Development" or "Defined" or whatever.

The Backlog is where new requirements land.

The "Defined/Ready for Development" column is where they move after they have been force ranked and estimated.

Sprint planning involves pulling from the "Defined/Ready for Development".

Having this ability is a huge benefit to managing the project and should be considered a mandatory feature.

Like # people like this

I need more fields/columns as well. I need them to help me prioritize. Also I need ways to differentiate certain issues from others that are more sprint-ready. 

Although adding columns to the Backlog view is something I'm also looking for, I think you need to be careful which columns you believe are needed.  Up above a user asked for the State (or Status in Jira language).  The fundamental problem with this is nothing in the Backlog should have an associated Status with it because it hasn't been assigned to a sprint, so why is somebody working on it.

Having said that, I would like to see the status in the scenario when a developer sees a related bug in the Backlog and fixes it even though it hasn't been assigned to a sprint.  I need a visual clue that the bug should be moved into the sprint so it can be verified.  It breaks the rules of scrum a little, but is a very realistic situation.

I see your point, but for us the backlog view contains the backlog + all planned sprints for the year.


KAM:s and Sales people can come to me for a high level estimate and a planned delivery. I plan it for a sprint five months from now. Any person involved in the business side of things, will know that they have gotten an initial OK from the product organization. But before any scrum team will develop, the requirements will have to be accepted by the PO and Scrum Master. Until the requirements are accepted, no development team will touch your case. 


Right now, we have zero visibility. Sure, I can create seperate dashboards for people, but it's hard enough to get people to just log into Jira. We have maybe 100 people that, from time to time, are interested in their case. They have no idea what the case number is, nor do they have any interest or knowledga about sprints, Jira or anything like that. The routine to follow up their case should be simple:

1) Log in to Jira

2) Look in the backlog

3) If it's not planned - we won't do it.

4) If requirements are not accepted by the team - we won't do it.

Any outcome on this? I have exactly the same circumstance as described, and simply looking to add some columns in the view - there's a lot of real estate wasted here!


Like # people like this

I have the same request. 

The same for me - it would be a help to see the status in the backlog.

Same request for me and my Product Manager team. 

I echo this request.

This is insane - please allow me to see the status in the backlog view - I am using it to provide an overall prioritization within the Sprint before it is shown in swim lanes per developer. I need to see what is in progress so that we can complete what we started.

Please just add this feature. How can we be agile if we cannot see the information. We cannot drive around in the dark with no lights on.

TFS had this years ago, eg see "Column Options" button in

Atlassian we need this please.

I need it too... :-(

I would also really like to see this feature.

This feature request is SUPER important for us as well (we're using jira cloud).


We should actually be able to customize the Backlog listing table and add more columns (-> fields) to the table, not only the status - for us, all tickets showing in our backlog are of the same status - but extra fields that will help us manage tickets priority by drag-and-dropping tickets to the right spot, based on such additional insight that is missing today.

For example, ability to show tickets labels in that table (if you use labels, could be convenient to see what label(s) a ticket has, could influence the priority decision e.g. position in the backlog, just like any other field that you are using on your tickets in general..). 

Would be nice also to see "time spent in backlog / in current status", that could also influence how we prioritize our tickets, and probably many more fields, but would be nice to support a least a few fields to start with, and the board admin could go in the board settings and select which additional fields he/she would like to be added to the backlog listing.

Today, such listing is not showing much (lots of wasted horizontal blank space), hence not helping to make such important decisions, e.g. backlog tickets prioritization, which is key to [kanban] backlog planning; this is usually not as simple as a FIFO, so we need to get more insight to make the right decisions.


Here is the solution to your request:

Not columns, but you will be able to see the status in the backlog at least.

Why is this still not fixed? 2021 and I need to add columns to backlog so I can see if the work in preparing a ticket is done before we can allocate these to a sprint.


In non trivial projects, there are lots of work to do on backlogs before you can allocate them to sprint!


Jira is too big to fail? doesnt listen to people doing the work?

There is nothing to "fix" here.  The problems people think would be ameleorated by botching columns in won't be.

You said yourself "A backlog is a list of issues to be prioritised and then drawn into a sprint" 

The decisions of which items to draw will depend on what stage of preparation they are at. Design, Allocate,Estimate,Review,Ready For Sprint. So if you see 200 backlog tickets there is no way to know which ones are Ready For Sprint. If you added a column for status, we would know!

Please post the alternative solution for this if there is one.

The alternative is to ignore this pointless backlog screen, and use Issue Navigator to see those details. Unfortunately we can't re-order items in Issue Navigator - see

Taking snippets of an answer, out of context, is pointless as a response, it changes nothing.  Have another read of the conversations.

If you genuinely can't tell what is ready to go into a sprint, then you have a problem with complexity, poorly defined stories, or your refinement process.  An arbitrary column is not going to help with any of those problems.

When you have those problems, I'm mostly with Jj Smith here - use tools that better suit what you're doing, like the issue navigator.  It doesn't support ranking or (a quick and easy) way to get to "ready for sprint", but it does help you a lot with refinement.

"As a product owner I want my backlog to contain the information I need to prioritize and plan sprints

"As a product owner I want to be able to identify if backlog issues/cases contain all vital information, so that I don't waste time on cases that need more work before they can be planned or prioritized"

This is the most fundamental need of each and every product owner on earth. You can hide behind all kind of fancy arguments you want, but if you create a product with a standardized view called "Backlog", and you don't give me an overview of the backlog - you have failed to comply with the most basic needs.

If that's not the place to handle the backlog, you have a problem with your naming, and you have a problem that the core "plug'n'play" part of your product doesn't contain any support for backlog handling.

"If you genuinely can't tell what is ready to go into a sprint, then you have a problem with complexity, poorly defined stories, or your refinement process.  An arbitrary column is not going to help with any of those problems."

First you accuse your paying customers of not being genuine. That's very hostile for a community leader. It's not a question of not knowing what to put in the sprint. Thats up to priorities and time allocation. It's about seeing them differently amid the 200 other tickets sitting in the Backlog. As your customers who use your product are trying to tell you, adding a column allows differentiation. 

Or you need some other type of backlog like 'Staging' if you are really adverse to adding columns(!)

Like # people like this

No, I'm not accusing anyone of not being genuine, you're twisting my words.

If you're going to do that, then I'm going to have to assume that you are not understanding what has been written.  I can't explain it in other ways I'm afraid, I've tried everything already.  I can't understand it for you.

I'm not going to bother engaging any more, as you're not going to get it.

Nic, the right column will certainly help managing complexity. You’ve got stories of all sizes and priorities in the backlog. As a product owner one needs to have the tools to manage that complexity and turn it into a more manageable list. Denying complexity is denying reality. 

Yes , I am also very keen to know that how to add extra fields according to user choice in the backlog data under Boards .. I cant get any idea here. Can someone please share the exact process to add different fields vertically as columns

If I understand Atlassians idea behind product backlog, the basic idea is that the product backlog is a list of issues that should be dispatched to different sprints. Typically during a sprint planning. Nothing more, nothing less. It is a simple view.

If your cases are too big, if they are not actually ready to be put in a sprint, or anything else, then you should have a work process to break the issues.

While I understand the thought behind it, most Product Owners have a reality with constant chaos. We've gotten the fourth owner in 9 years, we've grown from 30 to 350 i five years, we've merged and aquired several companies and we've yet to get a real grip of the ownership of Jira. So I have my backlog and my sprint board. That's it. It's all I can work with.

And right now, my experience with Jira is not good. We've moved from a physical board to Jira, and the board is just lacking in so many aspects.

We've moved the backlog from a physical board to Jira, and it's been a major let down.

I just want to be able to tag cases with the information I need, and then see that information in my board and backlog view. It's extremely simple. 

With respect, I find it very condescending to say that we can't configure our backlog view because you already know how to use our tools better than we do.  My teams try new experiments all the time.  If they want to see specific PBI info listed in a backlog column, why shouldn't they be allowed to do so?  Because someone decided years ago that there's only one way to work?

It's one thing to say we can't do this in Jira right now.  It's quite another to suggest we're stupid for even asking, or that we're "not going to get it."

Like Adam Cameron likes this

I do understand that some of the stuff said here comes across as condescending.   I do know my some of my writing looks that way.  I can't defend my style, it's just the way I write, but I would like to say that I do not want to be condescending and I am sorry that it has turned out that way.  I am trying to explain and help, not look down because something might look "wrong".

So, yes, it is one thing to say "Jira doesn't do this now" and another to say "you're stupid for asking for something you won't get".   The first statement that it doesn't do it now, I think everyone agrees on.  

The second is a misrepresentative though.  It's not stupid to ask.  My opinion is that it is the opposite - it is probably stupid not to ask.

So, going back to the original question:

There's a long essay I could write here with loads of examples, but I'll just pick out one small example this week - someone I have complete confidence in as a process expert turned to me and said "and how would you do this in Jira?".  My response of "simplify" and "don't do things like estimate sub-tasks, complixify your backlogs and boards, or add  a hundred and eleventy twelve fields you'll never report on" was well received.  My move on to "punt complexity upwards" also went well, and the example there was "why does a development team need a backlog with seventy eleven states?  All they need is "please do this" in their to-do column"

TLDR: I'm NOT saying this is a bad or useless thing to do.  I am saying that Jira is bad at it (and probably won't ever improve) because it is not something Jira is intended for.

You just strawmanned the argument. We do not want "backlog with seventy eleven states", or "a hundred and eleventy twelve fields". 

add ONE field called Status. So team can manage at a minimum Ready or Not Ready backlog items during Sprint Planning.

We are moving to Microsoft DevOps (slowly) because Jira is not fit for purpose for Sprint Planning, which is a key part of sprint. Why would you ruin your marketability and market share by not listening to practitioners? It's free gold plated research.

Um, no, it was actually one of your comments earlier that "strawmanned" it.  And a strwman is not a bad thing - it is there to frame attacks upon it with clarity.  But let's move on from that logical failure and look at your points:

>We do not want "backlog with seventy eleven states", or "a hundred and eleventy twelve fields". 

That's great, you want to do things the right way.

>add ONE field called Status.

The whole thing Jira (and its competitors) is built on is a status.  Don't be silly about this, Jira handles it fine.

MS-Devops is a great tool, by all means, move to it if you think it will work for you.  In my experience, it's not that good at being agile, it's trying too hard to do waterfall and agile at the same time, and I'd advise that you should choose which way you want to go and bin off the stuff you don't want (credit to Jira there - it doesn't pretend it can do both at the same time, just gives up on waterfall by default, rather than fake it)

>> The whole thing Jira (and its competitors) is built on is a status. 

Yet this highly important in your words "whole thing is built on" field is not visible on the Backlog list. Please do the right thing and escalate it to your product manager.

So your problem now is that you aren't being shown something you can easily infer from the fact that an issue is in front of you?   You know you can put that status on the cards in the backlog too?

Hi Nic,
I'd like your input on how to solve my sprint planning problem, and feel free to tell me that I've misunderstood the process rather than the tool.

The backlog is maintained as stories of minimum business value, prioritised by product owner (me).

When it comes to planning, the technical lead sometimes says that stories have dependencies between each other, sometimes clean blocked-by, but mostly the dependency is at the task level, so that the highest priority story cannot be pulled into the next sprint. For example both of the top two stories may depend on a data setup task included in the top story.

This doesn't show up easily on the backlog so I am not aware that my business priority cannot be followed by the team.

The problem is then magnified (from my pov) because naturally the team only want to bring stories into the sprint that they know they can complete; hence dependent stories are in the next sprint at the earliest.

Where the dependency has been obvious we've tried splitting stories into enablers (tasks up to the point of dependency) and the remainder, but actually this just pushed even more tasks into the next sprint.

The relevance to this thread is that simply showing the 'blocked-by' story on the backlog would solve 90% of the problem.

Suggest an answer

Log in or Sign up to answer

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you