This is a guest blog by Dan Mihalache, a Jira and Confluence expert with a passion for designing, implementing and optimizing processes. Dan is a senior project manager at Murex, a leader in software development for trading, risk management and processing solutions.

The Process Roadmap

What makes Jira a great tool for me is that it allows the easy implementation of processes in general. You can model whatever you want to model, define steps, validations, conditions, roles and responsibilities, roadmaps, schedules, milestones, releases, etc. Moreover, once a process is implemented, Jira is a great vehicle to make the process evolve: you can easily add steps that can bring value or you can eliminate steps that are no longer necessary.

This is why we have started to implement and evolve more and more complex processes in Jira. I am in charge of designing, implementing and optimizing the Processing Roadmap process for our clients, one of the strategic directions of the company. This rather complex process involves over 70 people directly from start to finish: determining the business requirements, developing a product strategy, finding and specifying functional and technical solutions, validating requirements and specifications, analyzing development demands, prioritizing, developing, testing, ensuring quality control and releasing.

The implementation of such a complex process at such a scale is not easy. Making everyone pull in the same direction in a controlled and predictable manner is challenging. It is difficult for many people (especially the non-geeks) to understand the whole process and the workflow we use. This is even more difficult when the process needs to evolve, when a new step or activity is added or eliminated and the responsibilities change. We use role-based dashboards in Jira to eliminate this problem for them.

Solution & Benefits

For every role there is a specific dashboard that shows relevant information for the dashboard owner’s role: what he has to do, what is in progress, what has been done and, if relevant, what he has to monitor. This brings a lot of benefits:

  • People don’t need to understand the whole process, they only need to understand their role and what is expected from them and this is captured in their specific dashboard. The dashboard hides the complexity of the process. (Of course, this does not stop them from understanding the whole process if they are interested).
  • Everything relevant to a particular user is in a single place.
  • Because people understand easier what they have to do, this brings flow to the process.
  • Since I have created and shared all the dashboards, when I modify the workflow/the process, I also modify all the associated dashboards which are automatically updated to the users. Those involved don’t need to understand the details of the modification as long as their dashboard remains coherent and functional. This allows easier modifications of the process without causing disruptions.
  • If someone has several roles then he also has several dashboards, one for each role.
  • The dashboards can be multi-project. This means that you can stream issues from several projects that require a similar type of treatment in the same dashboard. As an example of how one dashboard has evolved over time, initially each developer had a dashboard with the development requests related to the project roadmap. Later we added defects in the same dashboard, since it made sense for a developer to have all the development demands in only one place. Since the developers interact primarily with Jira via the dashboards, it doesn’t matter if behind there are multiple projects. As long as the steps visible in the dashboards are clear, even the workflows don’t need to be the same. This allows more granularity in the administration and management of different types of issues.

What it really boils down to is one person (or a few people) own the process as a whole, so individual contributors don’t need to work within a process, they get to just focus on their part of things and actually get work done.

Example Roles


The reporter works directly on client implementation projects. He identifies business requirements that need product developments. He has a dashboard with all the issues he owns and where he has to provide:

  • Business requirements
  • Solutions (specifications)
  • Clarifications for the developers
  • Release notes

This is his To do list. Each time he has to move the issue to the next status where someone else needs to act on it.

Functional supervisor

An expert in a functional area in charge of reviewing and validating business requirements, specifications and release notes. He has a dashboard with all the issues where he needs to review the business requirements (To approve), the proposed solution/specifications (Pending check) and release notes once completed (Resolved). These are his to do lists and the actions are to validate or to reject.

Dev lead

The developer in charge of the development of the roadmap block. He has a dashboard with his part of the workflow, his backlog (Ready for dev), and the completed issues (Ready for merge). In this dashboard you can note that the issues are from different projects, some are roadmap development (PROAD) and others are defects (PDEF). The developer doesn’t care that the two types of issues have different selection processes/workflows – he has his dashboard and he knows what he has to do.

 Set these up for your team

If you want to implement this, the approach I would use is:

  1. Define the process. What are the steps that need to be done?
  2. Define the roles and responsibilities. Who is in charge of what?
  3. Implement the process in Jira. For each status there should be only one role in charge of all the actions. This is the only way you can know who has to do something at any moment. The status has to be owned by someone. This also helps a lot with the design of role-based dashboards since you can easily filter on statuses.
  4. Understand the way the people in different roles work, then start to design meaningful dashboards for each role. Each role should have clear to do lists (whatever this might mean, a different status for each role), and relevant ‘in progress’ and ‘done’ issues to monitor/supervise lists if applicable.
  5. Evolve the dashboards. This is a continuous process, as people come with new and better ideas. Update the dashboards when new needs are discovered and better ideas are presented.
  6. Evolve the process. This also is a continuous process, as you discover new needs and optimizations. Keep the dashboards in line with the process.
  7. Take a user-centric view when setting up the dashboards, as opposed to a project-centric view. Stream issues that require a similar type of treatment in the same dashboard, even if they are for different projects.

How do you get things done?

Share your experience in the comments!

(Guest Post) Implement Role-Based Jira Dashboards ...