Managing a product backlog with ease (2/3)

I received a number of comments on the post Managing a product backlog with ease. Because there were several key questions around the larger workflow and how the product managers interact with engineering, I wanted to do a follow-up blog post on that side of the process. The Jira team is quite a large team, divided into smaller teams surrounding themes. Theme teams can include areas like issue tracking, Jira administration, or the out-of-box experience. In this article I was able to sync up with Josh Devenney who is the product manager for the administrative side of Jira.

The theme teams are able to use the process that works for them. Some use scrum while other use kanban. The Jira team does, however, use one Jira project and shares a common workflow. Let’s take a look at that workflow so it’s more apparent how the team works with each other.

–

Effective workflows allow teams to be collaborative, yet still gain the efficiencies of being independent as ownership across the team is clear. Workflows make change of ownership a distinct operation through a state change and/or by a reassignment. States describe the status of a task while the assignee designates the responsible person for that task.

The Jira team divides their workflow across three areas. Product management owns populating and prioritizing the backlog (blue) while the engineering team owns delivering those stories to the customer (red). Everyone celebrates the green area!

Note, there are many ways to manage a feedback/feature delivery pipeline. Josh and the team are working on a theme team known as Casper, which is focused on the admin experience in Jira. He’s focused on fields and workflows. The Jira team uses one project. How can they effectively manage their issues in one project? With Jira Agile, the team can filter down the issues in scope with JQL.  Josh created a filter called “Casper” that shows the relevant issues. Theme is a custom field in Jira that the Jira team uses to route issues to the different teams.

Pro Tip: When defining “project queries” be sure to include the negative cases as well. For example, the predicate OR fixVersion is EMPTY adds the issues with no fix version so they get prioritized. Including these cases makes your board “issue tight.”

Josh uses a scrum board in Jira Agile for the backlog management features. Jira Agile helps him focus the teams on the most important features first. Josh prioritizes stories and bugs for the team. Once a story or bug is fully fleshed out, he moves it from To Do over to Ready for Development. The development team then knows that the issue is ready for action.

(note: issue content and epics obscured slightly)

The team uses labels to denote if an issue is related to workflows or fields in Jira. Since the fields work and workflows work are not related, Josh has a quick filter to highlight each area so it’s easier to prioritize work within the feature area. Untriaged issues don’t have a label set. The bugs filter just filters on all issues of type bug.

Quick filters work only on the issues in scope of the current board. How do you know what’s in scope? See the filter tab shown in the first screenshot. Thus in this agile board, the future ideas are not future ideas for the whole team, but just those future ideas in scope for the Casper team.

Jira Agile maintains priority order (rank) across agile boards so the dev team’s board shows the same order as Josh’s product management board. In the next next article, we’ll take a look at how the development team engages once features are ready for development.

For more, visit The Agile Coach – our no-nonsense agile tutorial site.