How to use Atlassian Jira with Greenhopper to manage multiple Backlogs

At Metro our development project has multiple product owners who each have their own backlog and want to prioritise them separately using Greenhopper’s drag and drop interface. We didn’t want to create multiple projects to enable this and Greenhopper’s multiple backlogs support for a single project is something that had previously eluded me. Ade Shokoya who was our business analyst came up with the idea of creating an additional Kanban rapid board with product owner based swimlanes to achieve this. We now have one Kanban rapid board to manage the product owner backlogs and one to manage development priorities. They share a column which allow tasks to flow easily from one to the other.

We use components within our Jira project to categorise tasks by the business area and product owner that they deliver value for. Each component allows you to setup a default owner and this ensures that they are notified when any tickets are added or amended. We created an additional Kanban rapid board specifically for backlog management and added “Backlog”, “To Do” and “Scheduled for Development” columns to this. We then enabled swimlanes based on components so each of the individual backlogs can be prioritised separately within these. We also utilise quick filters based on component to allow each product owner to only see their tickets on the rapid board. As the filters are URL based this allows each product owner to have a browser bookmark to take them straight to their backlog.

Setup Swimlanes per Component

Greenhopper Multiple Backlogs Rapid Board Swimlanes

Setup Quick Filter per Component

Greenhopper Multiple Backlogs Rapid Board Quick Filters

Greenhopper Multiple Backlogs Kanban Rapid Board with Swimlanes and Quick Filters

Greenhopper Multiple Backlog Product Owner Board

Getting the business engaged with development process and priorities in Jira is a long term project of mine (as otherwise I am the only person who manages the board). The best way that I have found to do this is hold specific product owner stand ups twice a week where we have a look at the work in progress and discuss what the priorities are for the items about to move into the development stream. We have this around the TV that has our development Kanban rapid board displayed on it and can quickly switch between that and the backlog view. This allows each of the product owners to get a good view of overall priorities and where their requests fit into that. They also see how the process works and have an opportunity to provide feedback. This is complimented by a meeting every other week where we look at how each idea is delivering value based on performance data and then decide whether we do more or less of this based on our overall strategy.

Having multiple Rapid Boards for a more complicated flow that keeps each of the boards simple is one of the best moves that we have made. We are also now using a separate board to tightly manage our testing and release process as we have multiple environments and stages that overcomplicate the main board. Greenhopper has been really good at adding new features and streamlining their existing ones to provide a great way of managing the different stages of the project in a single dashboard.

Metro.co.uk Greenhopper Kanban Rapid Board Dev Board

Metro Greenhopper Development Board

Background

I have been using the Atlassian stack including Jira and Greenhopper to manage multiple Agile projects using its Scrum templates over the last three years. The great thing about Jira (and at times the most frustrating thing) is that it is pretty much infinitely configurable and Greenhopper gives a great drag and drop interface for Scrum and Kanban setups. Personally I don’t have the time to manage both an online system and a paper based post it system so we moved everything into Jira and got a 42″ television which is used for displaying boards during standups and as an information radiator during the day.

During the minimum viable product (MVP) phase of the metro.co.uk CMS migration we had a nice simple setup of Greenhopper utilising its Scrum template with a dedicated Business Analyst (BA) who managed the backlog. However he was a project resource and his contract was about to come to an end, we had also shifted from using Scurm to using Kanban but were initially struggling with the flow from the large backlog left over from the project.

Music to write this Code to

Treasure Fingers once again giving away a sparkling mix that makes you wish it was summer all year round.

Leave a Reply

Your email address will not be published. Required fields are marked *