Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

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

Best way to implement a parking lot for user stories? Edited

Hi everyone, 

I was challenged by my product owner, on what could be the best way to handle parking lot? As a matter of fact, we do have a huge backlog, and the Product owner would like to have a way to "hide" them from the backlog, but still keep them visible somewhere in the same project (not to be moved to another project).

Please note that I am using the next-get project type.

What could be your suggestion in implementing this the best way?


4 answers

Hey Eric,

what's the actual challenge:

  • Hide the Parkin Lot issues from the backlog view / More clarity about current items?
  • Organize the Parking lot issues?

Hi Mararn, I guess both challenges. Hide from backlog, but be able to organise as well the parking lot.

@Florian's suggestions sound good regarding the first challenge.


I'm actually really interested in the second point, organizing the parking lot, so here just some of my thoughts:

  • In one project we've deleted all items that were older than 2 years (after reviewing of course), that would clean it up a little bit.
  • However I feel like it's still difficult to get a grip on huge parking lots, since it's usually a huge list you don't look into very often. What would an ideally organized parkig lot look like for you?

Hi @mararn1618 

As Eric stated in his initial request he wanted to "keep them visible somewhere in the same project (not to be moved to another project)". That's why I suggested this simple approach. When you want to organize you back-back-back-log, I think the best you can to do is to enrich these issues with even more information. You might add a dedicated field where users can add a postpone reason (single value drop down) or a date when when you want to review these issues again. Then you can filter and sort these issues with plain and simple JQL.

It's hard to tell whats the best way without knowing all the details. How many issues (100, 1000, >10k?), how many participants, how long does/will the project last, just Kanban or Scrum, ...? So many questions. There is no golden bullet that will work in every environment.

Sometimes the problem lies in the organization structure, sometimes it's a team/team member that does not understand the tools, sometimes Jira is just the wrong tool.

But let's assume it can be solved within Jira. My experience tells me that it's best to start with some ideas an reevaluate in short cycles in a dedicated test environment. After a week or so usually I have created a mess and it takes me two or four weeks to clean it up. By cleaning up I mean remove everything that is more or less baroque/ornamental and does not bring any value instead of confusing somebody. Then I have something nice and simple that can be moved into our production system without causing any headache, not even to the least experienced user. Usually it's also a good advice to ask your coworkers what they want or need. 90% of their ideas are either useless, too complex or solve just one particular problem. But 10% will bring real value and can be used in a generic way for many problems.

When your Jira instance works like a Swiss clockwork your back-back-back-log will melt down and you won't have to care about it eventually. When Your Jira instance is a monstrous unorganized mess your back-log will grow more and more and you have to spend a lot of energy to manage it. So in the end it's the old say that will help you: KISS - Keep It Simple, Stupid.

Depending on your permission you can do several things. As global administrator you can modify the workflow and add a "saved for later" status. Then add a filter to keep track of these issues. You can also create a dedicated board that shows these issues based on that filter.

As a project admin without permission to change the workflow you can create some identifier (Component, Label, whatever) and exclude these issued from the backlog with a Quick-Filter.

Thanks Florian for your input. If I do create a new status, I will still see the issues in the backlog. Furthemore, I will see this status in the sprint board, wich does not make sense to me, as I do not want to see such a swimlane on my sprint, as those parking lots elements should not go directly to a sprint.

I am considering moving them to a new dedicated projet exclusively for backlog, that will exclusively remove those from the backlog.

0 votes
John Funk Community Leader Mar 05, 2021

Hi Eric,

What if you added a Component for Parking Lot. Then you could alter your board filter to exclude issues with that Component.

Then create a new one column board with a filter that just shows issues where the Component = Parking Lot

Hi @Sou_ Eric 

When a product owner gives me a challenge like you describe, I find it helpful to discuss symptoms with the team before discussing solutions to...well...the symptom rather than the root cause.

A larger backlog may indicate:

  • Nostalgia or stubborness ("one day, we will fix that defect from 5 years ago that stakeholders work around and no longer care if we fix...")
  • Requested items are not driven by recent product information, and so aging past their "best by date"
  • Splitting down items too soon before start of work
  • Putting items in the backlog which are not valuable enough to implement
  • And other backlog management issues, rooted in product management concerns

A large backlog is inventory to deal with and just creates more work: re-ordering, hiding/showing, categorizing, reporting, etc.  Please consider stepping back to examine why there is a large backlog before deciding how to proceed.  That may inform how you do so.

Thanks, and best regards,


Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Jira Service Management

ThinkTilt is joining the Atlassian Family!

This morning, Atlassian announced the acquisition of ThinkTilt , the maker of ProForma, a no-code/low code form builder with 700+ customers worldwide. ThinkTilt helps IT empower any team in their or...

354 views 19 20
Read article

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