Best way to implement a parking lot for user stories?

[Sou, Eric]

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?

Thanks, 

[mararn1618 _secretbakery.io_ · Accepted solution]

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?

[Sou, Eric]

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

[mararn1618 _secretbakery.io_]

@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?

[Florian]

Hi @mararn1618 _secretbakery.io_ 

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.

[John Funk]

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

[Bill Sheboy]

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,

Bill

[Florian]

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.

[Sou, Eric]

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.