How to tier a product backlog

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.

4 answers

1 accepted

0 vote
Timothy Chin Community Champion Jun 10, 2013

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.

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.

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 Chin Community Champion Jun 18, 2013

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.

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.

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.

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.

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.

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.

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published yesterday in Jira Software

How large do you think Jira Software can grow?

Hi Atlassian Community! My name is Shana, and I’m on the Jira Software team. One of the many reasons this Community exists is to connect you to others on similar product journeys or with comparabl...

240 views 4 9
Read article

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you