Our newly signed star, Thorbjørn, shows you how Jira can help visualising your Kanban flow. Jira provides you with the option of setting up different views for different interest groups, giving everyone the information they need.
CREATE SEVERAL DIFFERENT BOARDS WITH THE SAME DATA
It’s been somewhat popular to bash Jira for having a less than decent support for Kanban. However, if you can live with its shortcomings (and they are getting fewer), it has one really powerful feature you might find interesting. A feature many other virtual kanban tools are missing.
It is really easy to set up and highly customize a kanban board in Jira (columns, swimlanes, statuses, issue types, classes of service, issue colors, card content, etc), either connected to a new or existing project. And the interesting part of the previous sentence is project. You see, a kanban board in Jira is just a visual representation of issues returned from a project filter. This is important. That essentially means you can create several different boards displaying the same data. Allow me to explain why that is useful.
A lot of teams only visualise their development process, not the entire product development flow. The development part of the process usually consists of steps that fail to engage upper management, and often even marketing and product management. The result is that you miss out on the benefits of transparency.
YOUR DEVELOPMENT PROCESS IS TRANSPARENT, BUT NOBODY IS LOOKING
You need to visualise everything from idea to production. The problem is that in order to help everyone understand what they are looking at, you need to provide different lenses to different people.
Jira solves this problem beautifully, as you may set up as many boards as you like against the same data set. Each board may have a different set of columns, different naming, show or hide parts of the process, hide certain issue types, use colors to highlight issues differently, split issues in different swimlanes based on i.e class of service in one board and on teams in another. If you like, you can even display issues from multiple projects in the same board. All of this is made possible with JQL, The SQL-like filter language available when configuring boards in Jira.
Suddenly you have a window into your process for any interest group. Management has a broad program view that focus on features across several projects, hides subtasks and shows the entire development process as only one column. Product owners have a planning view for each product, focusing on the discovery steps prior to development. The tech team has a backlog populated with selected issues from product owners, and can pull issues into a detailed development board focusing on the technical steps of the process. Finally, the testers has their own custom board focusing on items ready for test and issues they have blocked or reopened. You could even open up your process to customers. Show them a limited view of the world by showing only issues related to the product modules they have a licensed, or maybe only the issues they have reported.
Below are some illustrations from Jira showing what can be done (they are all from the same process):
The illustrations above are borrowed from the product development process belonging to a meeting and event software called Qondor. Running their own, highly transparent development process based on Kanban, they are able to continously deliver value to their customers. Product management can easily view the state of the issues they have selected for development, without being bogged down with too many details. When capacity is available, the development team pulls issues into another board that focus on their part of the process.
That brings me to another nice and quite recent feature (currently in JIRA software labs and only available for cloud instances), the Kanban backlog. This is a simple but useful backlog view to the left of any board of your choosing. Again, the cool thing about this is the flexibility made possible by the fact that any board is an independent view of the same data. You could easily set up one main backlog for product management where they process incoming ideas and put them in a queue for development. Then you could set up another backlog downstream that contains the output from product management. Suddenly development has their own backlog they can pull issues from.
The Qondor team from the illustrations above has even configured the development backlog to be a combination of both the output from product management and internal issues like architecture, refactoring and bugs. The tech team are then responsible for balancing new features against bugs and platform changes. It’s all pretty cool, and allows for a high level of self management within the technical team.
That’s it for this post, I hope you learned something! feel free to respond with your comments or thoughts, or if you need more detailed information about how to set this up!
(This article originally appeared in @thorbjorn.sigberg’s Medium stream.)