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.
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.
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.
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.
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.
Did you find any valuable guides to setup Structure to manage multiple backlogs?
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
It looks like you're new here. Sign in or register to get started.
