How to tier a product backlog

[Philip Winston]

In the screenshot in this post:

http://blogs.atlassian.com/2013/04/how-to-manage-a-product-backlog-with-ease/

How do they get the columns Not Ready Yet, Unprioritized, Ready for Feature teams, In Design. I know you can name columns whatever you want, but does this imply they made workflow statuses for all of these? I really like the idea of using a 2nd board for tiering the backlog, but I'm just unclear how exactly to set it up. Our backlog today have ~600 issues and the Plan view on the main board is too overwhelming to deal with. Having a separate whole board for backlog seems smart.

[Timothy · Accepted solution]

How do they get the columns Not Ready Yet, Unprioritized, Ready for Feature teams, In Design. I know you can name columns whatever you want, but does this imply they made workflow statuses for all of these?

A column can contain more than one status. This means you can create your own columns that make sense to you.

Our backlog today have ~600 issues

That's why you have Epics and quick filters to help you out.

Tier-ing your backlog means having multiple boards that take part of your workflow. They can either overlap or not overlap each other.

[Philip Winston]

I see you can create columns named whatever you want, but you have to map statuses to them. So do you suspect this screenshot represents a workflow with statuses like Not Ready Yet, Unprioritized, Ready for Feature Feature Teams, in Design, and then also the normal In Progress, Resolved, Closed? Like do you just end up with tons of statuses?

As for multiple boards we need to read up on that, we've been using 1 board for over a year and yes, it is not enough.

[Philip Winston]

Can you explain "having multiple boards that take part of your workflow" a little more?? We think this is great but can't find details.

[Timothy]

This is how i invision having 2 boards. Say, a workflow has 4 statuses. The first part of the process is planning. The first board will be a Kanban board that filters the 1st two statuses. The next board could either be a another Kanban board or a Scrum board which filters the last two statuses.

Each of these two boards can have its own quick filters, swimlanes, etc. to make it's progress smoother.

[Philip Winston]

I set this up as a test, like Dan's blog post, and it seems pretty neat. It would be nice if the Kanban board could handle Epics better, but with careful board-filers and swimlane-filters you can approximate it pretty well. Assigning issues to Epics is a weak point also, the scrum Plan screen does that well, but the kanban Work screen has no simple way to assign Epics except to edit issues. Would be nice if you could drag to a swimlane to join the epic in that lane. But we very well might try this anyway. It seems like a HUGE win over using one scrum board with 1000+ issues in a flat linear backlog.

[C]

I also have this question as it doesn't take much to quickly overwhelm JIRA's flat backlog. I read the atlassian post as well regarding use of the Kanban board. The issue with that solution is all workflows need to have those common preamble steps in order to allow the issues to flow through the Kanban board until they reach the magic 'ready-for-development' state, at which point the SCRUM board picks them up. For my part, I am considering using the Almworks Structure plug-in to manage all of my backlogs and, then, move the issues into a special branch of the structure which represents the top-level backlog. I'll write a filter query to pick out any issues which are in that branch.

[Jason Bailey]

Did you find any valuable guides to setup Structure to manage multiple backlogs?

[Philip Heijkoop _ALM Works_]

Hi Jason,

My name is Phil, I'm a solutions engineer at ALM Works. We make the Structure add-on.

If you are familiar with the Automation features, you can easily manage your backlog with Structure by inserting the issues you are looking to manage into an empty structure.

Then group them by sprint. This will show you all the issues and which sprint they are currently in. You can then easily drag and drop any items from the backlog to a specific sprint, and Structure will make the corresponding change in Jira.

Bonus feature: You can also add a second grouper (for example by assignee) to this structure board, and now as you drag and drop an item, it will update both the sprint and assignee of that issue.

If you are unfamiliar with our Automation features, they are the heavy lifters that enable the creation of dynamically updated structures. You can enable Automation Editing Mode by pressing the "Automation" button at the top center of your screen, then selecting the + icon next to it to add a Generator.

These Generators can perform a number of actions that are essentially the rules that build up the structure board. Two of these actions are the inserting and grouping that I have mentioned above. 

If you have any further questions or want to hear more, please feel free to reach out to our support channel at https://support.almworks.com or send us an email at support@almworks.com

Best,

Phil

[Chris McFadden]

The approach we follow, which I can't say exactly solves all problems, is to have a special JIRA project called "Product Backlog". The advantage of this is we can have a different workflow (similar to described by others here) and run it through a Kanban board. We can also have different permissions on the backlog project, keep Epics in the backlog project only, and have a separate Kanban board. Once a backlog issue gets "approved" it can be moved into what we call "Release Backlog" JIRA projects. It is possible to have one Product Backlog that perhaps is not super product specific, that feeds multiple Release Backlogs (for different specific products). The release backlogs are more rigorous and are controlled with Scrum boards. Each issue on the Release Backlogs must be qualified to the specific team or product.

[Philip Winston]

Oh interesting, two sepearate projects. I just seems like moving issues between projects is a heavy-weight operations, but I guess it's not really bad? Interesting anyway, I'm thinking we will start with a single project and a long workflow until we hit a wall with that, but I like having options.

[Philip Winston]

The question in here is "does this imply they made workflow statuses for all of these?" That is what confuses me. In order to have a 2nd board with these other columns, does that meant the workflow was modified to have all these statuses such as Unprioritized, etc.