Over the years of supporting teams with their agility and tooling use (and hopefully both combined where possible!) it’s been a constant source of distress to hear of the hours wasted exporting data from tools like Jira, importing it into Excel, and jazzing things up a bit into some slides, usually for management to glance at. Even worse, by the time this data made its way through, it was often:
Subject to errors from processing
Already out of date
…at the same time, even for development team members, lots of the reporting built in to tools like Jira just isn’t visually compelling or consumable. Luckily for us, this has created a handy market for exciting innovators like Screenful!
Screenful integrates with one or more delivery tools including (for now – their roadmap is quite frighteningly rapid) Jira, Trello, GitHub, Pivotal Tracker, Asana, and GitLab… and in many cases fills gaps that can bump up functionality in these tools significantly (need Epics or Sprints in Trello? Screenful can fix that for you 😊 ).
I’ve often been asked by clients and colleagues for a core set of recommended agile metrics as a starter for new teams (mostly Scrum), and whilst the answer is of course the perennial ‘it depends’, Screenful comes pretty close to offering an exceedingly good basic set to get started with. My two particular favourites to highlight hit 2 key areas – timing and forecasting.
The Time Machine (Reporting Retros)
Possibly the most revealing, and often most uncomfortable, of lenses to help a team understand their agility is by looking at their cycle time. In many tools, creating a meaningful view of this takes a good deal of data munging and you end up with something that takes quite a lot of narrative – in Screenful you get it within about 30 seconds of install. The answer might not be comforting, but it is important:
Up, up, and away!
My second favourite capability to empower teams with is a data-fed view of where they’re going. A versatile and configurable burnup chart is incredibly useful, particularly when making tough decisions about priorities, but can be a pain to maintain and tweak (“What happens if we focussed purely on X?”). Here again, Screenful provides a compelling and easy to understand format which can save hours of slideware production:
Yer a Wizard… admin
Powerful tools can often feel intimidating to setup. Screenful wins here also. Thanks to a slick UI setup wizard, the core capabilities are a breeze to setup. I often recall after one demo where a team had managed to setup their trial before my colleague had returned to his desk. As always there’s more tweaking to get things perfect, but getting a reassuringly rich initial setup is almost instant, which really helps alleviate initial fear of ‘another new tool’.
Tip: As with lots of tools, (if you’re using Screenful via API rather than as a plugin) it’s worth setting up a service account to use for accessing your instance. This is better for various security reasons (not least that you can give it least-privileged and read-only access) but also more convenient to cope with staff transitions.
Screenful is easy to check out with a free trial, and configuration of a quick proof of concept takes single digital minutes – vastly quicker than most other tools. I’ve encouraged huge numbers of teams to give it a go, and even if it’s not right for them in the end, thinking about the core metrics and views it provides helps them consider how and what data they visualise about their work in future.
The Jira Sprint Report is a Scrum team’s best friend and one of several key reports in Jira that help teams gain valuable insights on a daily basis. First and foremost, it lets you know how you’re sprint is doing in terms of progress, priorities and burndown. It also encourages conversations between team members about any progress interruptions, effects of scope changes, and improvements that can be made on the next sprint.
Importantly, it helps you achieve whole team ownership, a concept that many organizations struggle with.
This article explores the benefits of Jira Sprint Reports and how they foster shared responsibility and accountability across development teams.
Whole Team Ownership
What is whole team ownership? Let’s look first at the opposite model. A team focused on individual ownership has people who have a specific role and don’t typically act outside of their remit. They own the tasks they’re assigned and other team members should go through them if they have something to contribute. This is all well and good when everything’s running like clockwork. But it can be a challenge when that particular process owner is unavailable or there’s a breakdown in communication.
Whole team ownership is about pulling down the walls between team members. These teams share responsibility, holding themselves—and each other—accountable for the team’s overall success. With whole team ownership, handing over work to a team member is more than sending an email or assigning an issue or ticket to them. It involves a conversation to confirm that all the relevant information is included and the next steps are clear. Every member of the team has the ability to impact each step, and everyone speaks up with concerns and questions to help make sure there is a collective understanding of the topic at hand.
Jira Sprint Reports help shift responsibility from the individual to the team as a whole, by facilitating conversations that bring team members together in pursuit of a common goal.
What is the Jira Sprint Report?
The Jira Sprint Report gives Scrum teams visibility of their sprint progress and sprint dynamics. It shows the burndown of work, so you can visualize how you’re doing relative to where you are in the sprint. It allows you to identify what might be stopping you from finishing everything you’ve committed to the sprint.
Burndown charts commonly use Story Points (1), but can also use hours as a metric. The grey line (3), based on the total estimate of the issues at the start of the sprint, is your guideline. The red line (2) is the actual work done. It shows the current total estimate for unresolved issues during the sprint and reflects issues that may have been added to or removed from the sprint.
The Jira Sprint Report also gives Scrum teams a great view of their sprint dynamics by listing completed and not-completed issues. A little asterisk appears next to any issues that are added to the sprint, giving you valuable insight each day on whether the scope of the sprint is changing. These are things that are hard to see on your sprint board or in the backlog view.
Jira Sprint Reports also list your priorities. You’re able to see if there’s a load of high-priority incomplete issues, encouraging conversations between team members about whether you’re working on the right things in the right order.
The data displayed in a Jira Sprint Report can be used for mid-sprint progress checks and discussed during the daily stand-up. Equally it is useful for retrospective conversations. You can talk about what incomplete issues have been rolled over to the next sprint and why, and evaluate the reasons for any straight horizontal or vertical lines partway through the sprint.
In short, the Jira Sprint Report lets you visualise the progress of your sprints and measure team success, both in the short term (are we on track to complete our sprint goal?) and the long term (are we delivering what and when we say we will?).
Note that the Jira Sprint Report is board-specific and will only consume the data that matches your board’s saved filters.
What’s Great about Jira Sprint Reports?
The Jira Sprint Report supports and facilitates the micro-planning that should be happening in your daily stand-ups, enabling you to stay on track with achieving your sprint goal. It also triggers useful discussions in retrospect, improving the quality of future sprints. Teams can ask the following questions:
What were the scope changes? Were any good or bad?
Were any stories added to the sprint that were unestimated?
Did we complete all the high-priority stories?
Did any high-priority stories get rolled over?
Was there a steadily descending line on the burndown chart with a sudden drop-off at the end? This normally means that you’re handing everything over to Quality Assurance (QA) at the end of the sprint, triggering a further question…
How are we going to start handing over work more incrementally to QA in the future?
What’s particularly useful about the Jira Sprint Report is that it breaks down functional silos and fosters whole team ownership of the progress and quality of a sprint, and the processes therein. It encourages team members to talk to each other about how they’re going to move the team forwards, and to share responsibility for the team’s successes and failures. The sorts of questions listed above can only really be answered by the whole team coming together.
The end result? More effective sprints, and more effective teams.
Now you’ve got the hang of Jira sprint reporting, it’s time to go faster! Check out this blog on Jira Velocity Charts
In a conversation my wife overheard yesterday she heard me mention ‘swimlanes’ which led her to excitedly expect that we were going to the leisure centre this weekend. Of course as each year passes we have a tendency as a species to reuse and reapportion the meaning of words into new and fancy things. Apparently back in the annals of time the word ‘Nice’ meant ‘Silly , foolish , simple’ and the word ‘Silly’ originally meant ‘to be worthy or blessed’. Luckily for us and our Jira musings the concept of swimlanes is very similar in use to that most of us grew up with albeit in a slightly different context.
To put it simply, ‘Swimlanes’ are normally used to separate your project ‘to-do’ lists into ordered, actionable and easily identifiable ‘faster /more important’ sections often by individual users or project areas. They are a clever and query driven way of producing dynamic lists with a logical workflow and, significantly, are a visual way of seeing the health of a project and any outstanding blockages that need rapidly addressing. Hitherto in most definitions this is a ‘view’ of a Kanban board and is not dissimilar to physical board forms used throughout many Agile organisations in the world. There are advantages and disadvantages of using virtual boards using swimlanes over physical boards but that is for another time.
If you choose to have such a project or set of tasks with a Kanban and swimlane approach then Jira has most bases covered. Once you have a project in mind then there are a number of key decisions that the project needs to make before creating the swimlanes on a board. (blog for further info on Visualizing Work with Jira Kanban Boards).
Get your Jira Workflow Right
It may sound obvious, but without an appropriate workflow, swimlanes are not very powerful and possibly very unusable. When you set up a project there are a number of basic workflows out of the box which you could choose but it is often better to start with fundamentals and draw your own workflow on a piece of paper before mapping it into Jira . The number of times I’ve scribbled down and modified what I was trying to do in a meeting has saved me time in the long run – the measure twice and cut once still applies at a rudimentary ‘tech’ level! Most workflows have similar concepts such as a starting state, an end state, and one or multiple loops in the middle, but it is key for you to choose what is right for you based on what statuses you plan on reporting on, or are wanting to see.
… that includes State Transformations
So many times I have been called to look at a Jira Kanban board that cards cannot be moved on screen as they are not ‘in the right state’.
TIP: Before you start to create your swimlanes ensure that each item can be dragged freely from one status to another within your on screen/project modelling.
Which Workflow Statuses to Report on the Jira Dashboard?
A workflow in simplest terms might have a simple three-part model with a beginning, middle, and end but this would be rare. It is more common to have many more statuses that you could group on a singular board. Jira provides the opportunity to merge multiple workflow statuses into the same columns and relabel columns in any way that suits you so you are able to have a useful board setup quickly, e.g. when presenting ‘test’ and ‘retest’ in the same column on the board to reduce space under some mapping, which is very useful when creating a board with swimlanes on it.
What Type of Jira Swimlanes Should I Use?
Jira comes with six distinct options for swimlanes each with differing purposes and uses…
Story (or Jira Epic) Swimlanes
As you would envisage selecting to create Story or Epic related swimlanes will simply present the stories or epics in the project and in what current status they are in. There will be other information on the cards but it is a standard view of seeing the state of a project and very much looks like a traditional Kanban board.
Jira Issue Assignee Swimlanes
Selecting this option simply shows a person by person view of what work is assigned to them which might be useful for a quick view on workload at scrum master level or to see what reliance a project has on an individual e.g. if they were ill/unable to work for a period of time.
“For smaller teams, we actually prefer to do quick filters for each assignee. On the kanban for our waterfall teams who are executing a project plan, I see a lot of value in using swimlane by query to dedicate a swimlane to critical path and another to behind target.”
Patty Land, Project Management Consultant, PwC
Jira Project Swimlanes
If reporting on multiple projects (or sub-sections of projects) then this option will allow you to see the status of each in a way so you can see what is happening from a very global perspective …. perfect for the Big-Picture megalomaniac amongst us all!
Here’s the thing… I use query-driven swimlanes almost all the time. You have full control, can add new queries at any time and can adjust what is seen on the screen to help present the information you are trying to show. With the query-based approach you can create swimlanes for each of the other types described by simply writing appropriate JQL. I tend to write query-based swimlanes for each member, or team, in the project(s) and also like to have a priority-driven view i.e. highest at the top. This can be defined in the appropriate JQL and then dragging the ‘Name’ column into a relevant order on screen.
TIP: Swimlanes can use any valid JQL so different lanes shown on the same report don’t even need to relate to each other but simply show a grid view of how a query models against a workflow
The configuration options and uses are endless here. When you suddenly have one of those meetings with ‘The Boss’ who suddenly determines that an issue you deemed insignificant has to be fixed for a big demo coming up… but don’t want to change the priority.
By utilizing a label and adding a new swimlane at the top of your settings then this and other tagged issues will suddenly be the prime focus of the next catchup meeting and can be dealt with accordingly.
TIP: Jira will allow as many boards as you want so you don’t ever have to stick with one view. Why not have a swimlane board dedicated to priorities and one dedicated to individual workload? The options are endless….
Jira Swimlanes are a fantastic way of presenting information for individuals and teams. With minimal JQL knowledge, you can create Agile Project boards within Jira containing items that you want showing and in the order you wish them to be displayed. You can hide items you don’t want displaying and use such organized boards to drive an agenda for any meeting that updates dynamically in real-time as the meeting progresses. Jira swimlanes can also be used in conjunction with quick-filters, card layout and details, and other board features to present a perfect view of your project for your audience.
How consistent is your delivery for each sprint? Is your team overcommitting or under committing? Are your estimates accurate?
And if not, why not?
Jira Sprint Reports (and specifically the Jira Velocity Chart) are ultra-handy reports that can answer these questions, letting you visualize what you deliver versus what you plan. It lets you predict the amount of work your team can get done in future sprints, and see and understand the problems that could be making your delivery less consistent than you’d like.
This article looks at why it’s one of the most popular Jira reports among Scrum teams.
What is the Jira Velocity Chart?
The Jira Velocity Chart displays grey and green bars. The grey bar is the story points you have planned for the sprint, while the green bar is how many story points you’ve actually finished. Ideally, the two bars for each sprint should be the same height.
What’s great is that this neat and simple little chart got an upgrade in the Jira Software 8.9 release a few months ago. Previously only displaying the last 7 sprints completed by the team, it now shows up to 120 sprints, letting you choose a pre-defined timeframe or custom date range.
Another new feature with Jira 8.9 is the horizontal grey line. This is the average velocity of your team, i.e. the average of the total completed work—the grey bars—over the last however-many sprints. In the old version of the Velocity Chart, you had to calculate the average yourself. And the fact that the chart can now show dozens of sprints instead of 7 means you get a much more insightful average, particularly if there’s high variability in your sprints.
The Jira Velocity Chart is a valuable tool when sprint planning. You’re able to get a sense of the volume of work you’re likely to be able to accomplish in the upcoming sprint, so you can decide how much you could feasibly commit to. Importantly, the chart lets you analyze the consistency of your delivery and assess whether process improvements can be made or requirements should be honed.
Calculating your Story Point Completion Percentage in Jira (A Useful Tip)
While the Jira Velocity Chart gives you a figure for the average velocity of what you’re completing, it doesn’t give you a figure for the ratio of completed to planned work. A figure like that lets you compare the velocity of different teams and assess which teams ‘seem’ more reliable. In other words, if Team A says they’re going to complete a body of work in the next 3 weeks and Team B says the same, which team is more likely to succeed?
Enter the Story Point Completion Percentage. This is calculated by dividing the number of story points delivered by the number of story points planned.
See the screenshot above, for an example.
Story Points Completed / Story Points Planned x 100 = Story Point Completion Percentage
[Figure] / [Figure] x 100 = [Figure]
Calculating the percentage for each sprint in a given timeframe provides an instant view of what’s happening all the way upstream, thereby giving you a better understanding of your velocity and what’s driving it. For example, there may be an issue with your sprint planning, or your estimates could be off. This in turn triggers conversations about why this might be.
Note that the Story Point Completion Percentage is not a feature that’s currently available in Jira. You have to copy the figures and do the sum manually to get the percentage.
The Benefits of the Jira Velocity Chart.
The Jira Velocity Chart has the following benefits for Scrum teams:
It increases stability, reliability and confidence in sprint planning. If your team keeps planning for 70 story points but never finishes more than 30, the Jira Velocity Chart lets you visualise this and see more easily if you’re overcommitting and should plan for 30 instead. Equally, you may be completing more story points than you’re planning and so could feasibly commit to more in future sprints.
It allows you to explore whether the issue is to do with the quality of your estimates rather than your commitment. It might be that there are things affecting your flow that you’re not taking into account. External factors, such as waiting for a technical partner to do something, might be slowing you down. Internal factors, such as workplace interruptions and context switching, might also be putting the brakes on. At the same time, new efficiencies might be speeding you up. Work in progress (WIP) needs to be strictly controlled to ensure realistic results.
It lets you identify whether you need better stories or perhaps even better requirements. If your estimates aren’t accurate, it could be because you don’t have great user stories. And if you don’t have great user stories, it could be that you don’t have great requirements to begin with. The Jira Velocity Chart enables you to find out the root cause of what’s going on.
It leads to more consistent delivery. By identifying the root causes of why your planning and completion aren’t matching up—whether it’s challenges to your flow or process, a lack of control of WIP, new efficiencies or substandard requirements—the Jira Velocity Chart boosts the team’s ability to assess their progress, identify areas of improvement, and make better and more realistic decisions on expectations. This in turn leads to more solid sprint planning and more consistent delivery on sprint goals, reducing any uncertainty or risk around forthcoming releases.
The Jira Velocity Report is a terrific reality check for Scrum teams. By better understanding your velocity and what’s driving it, you’re able to create a foundation of trust and legitimacy when setting expectations for future sprints.
Getting the onboarding process correct is essential when you’re introducing a new team member. It’s the first real impression they have of the inner workings of your organization; a smooth onboarding process not only sets them up for success, but it’s good for the whole team. And yet, for many organizations, this is still considered somewhat of a separate process, one that sits outside of the usual task management, tracking, and reporting work.
By bringing onboarding into a project management tool like Jira (where you’re already tracking your day-to-day projects) you not only make the process simpler — you can gain meaningful insights from customizable reporting, to optimize the onboarding process going forward.
Create Onboarding Tasks in Jira
When it comes to onboarding new team members using Jira, there are some tasks that are likely to be the same for each new joiner. To save time, you can automate the creation of these tasks by using Jira templates or copy tasks and sub-tasks from previous new team members to save time.
One option available on the Atlassian Marketplace for Cloud, Server, and Data Center is Deviniti’s Issue Templates for Jira, check out that link for great tips and tricks on how to set up templates for onboarding new team members.
To get your new team members fully on board and embedded in the team though, you can expand ‘onboarding’ beyond the usual housekeeping requirements. Whether you’ve had a growing wishlist of tasks for a new role throughout the hiring process, or you have handover tasks from a previous employee, including these can make onboarding more meaningful for your new team member, and make it feel more than just a box-ticking exercise.
Plus your your Jira reports will provide more useful insights — more on this below.
Checking In With Jira’s Reporting Dashboards
Communication is key when it comes to making sure a new team member is engaged and onboard. This should be the main focus of your catch-up meetings — how are they getting on? Are they settling in? As your team gets busy and deadlines near, you want to make the most of that time.
This is where Jira’s reporting dashboards come in. Since reporting dashboards for Jira are highly customizable, you should create a dashboard dedicated to your new joiners.
Use filters to see at a quick glance which tasks are in progress right now; use this to make the “what I’m working on” part of your catch-ups more efficient and give yourself more time to get to know how your new team member works, and how you’ll be working together going forward. This is more important than ever if (like many businesses today) you have more team members working remotely, and may still be adjusting to not being in an office environment.
Customise JiraReports to
See the Metrics that Matter to You
We mentioned earlier that an effective onboarding process should combine your HR and housekeeping tasks, as well as the first day-to-day tasks you need your new team member to start getting on with. This is where you can really make the most of your ability to customize Jira, and create custom charts for Jira reporting to visualize the metrics that are relevant to you.
Create charts dedicated to displaying different issue types, or filter quickly using Simple Search to see how HR, training or daily tasks are progressing. If you have a more complex onboarding process, you could even create individual dashboards for different issue types — you can make your reports as custom and in-depth as needed!
It’s not just management who will benefit from this visualization, your new team member can see their progress as well, and rest assured that they’re on the right path.
Improve Your Processes
Once your new team member is fully onboarded and settled into the team, it’s tempting to move on from the onboarding process and not consider it again until the next time you have a new joiner.
Don’t fall into this trap! You’ve already done the hard work — you’ve created your tasks and templates, and with your Jira reporting dashboards, you have all the data you need to evaluate their effectiveness.
You should approach your onboarding process the same way you approach the rest of your work, as something you can continue to improve. Are you seeing consistent blocking points? Perhaps part of your process needs reevaluating, or breaking into smaller stages.
Are there steps that are running smoothly for all new joiners? What do they have in common, and how can you replicate that success across the rest of the onboarding process?
The smoother the onboarding, the more successful, and the more settled your new team member will be — they’ll feel part of the team in no time. The information is all there within Jira; unlock valuable insights in one step, without needing to export data, with the right Jira dashboards and reporting.
The key to the success of any project is knowing which tasks to prioritize first and which can be held back until later. When Jira issues come in that need fixing urgently, do you drop what you’re doing or do you attempt to speed up and quickly finish what you’re on? And how do you ensure everyone is on the same page, in terms of how to track and maintain progress? Well, if you know how to correctly prioritize work in Jira, you can easily maximize the efficiency of your teams, making workloads manageable and reducing wasted time.
Prioritize Jira Issues Consistently
By default, issues in Jira can have one of five priority levels: Lowest, Low, Medium, High, and Highest. You can easily set this by opening up a particular issue and then selecting it under ‘Priority’. Just click on the current priority level to open up a dropdown menu of the available priorities.
But how do you actually define the different priority levels? And if more than one person is responsible for prioritizing work in Jira, how do we know everyone is using the same definitions? For all you know, your Medium issue might be your colleague’s High priority issue.
If you’re working to a defined SLA, then you’ll likely have clear definitions to ensure consistency, and you’ll prioritise work in Jira according to the criteria of that document. If, however, you don’t have any formal method to determine the urgency of incoming tasks, then you can quickly find issues being categorised inconsistently, which is confusing and inefficient. It is recommended, therefore, to agree and adopt some kind of system for identifying and categorising issues, so they’re prioritised consistently and tasks are completed in a meaningful and efficient order. This should be clearly documented so your entire team can refer back to it as needed.
If it is practical to do so, assign priorities to issues as soon as they come in. This will ensure that new but urgent tasks can be attended to as quickly as possible, and it will give you more time to reschedule less pressing issues.
Customize Jira Priorities
Jira’s built-in priorities no doubt cover a wide range of scenarios, but you may find that your team would benefit from using customised priority fields instead. Assuming you have the relevant permissions within Jira, you can create your own priorities using the following steps:
Head to Administration > Issues and select ‘Priorities’.
Now choose ‘Add priority’.
Enter a name for your new priority, as well as a description.
Select an icon to represent the priority.
You can now pick a colour for the priority, either from the colour chart or by entering the appropriate HTML.
Now select Add, and your priority will be ready to use.
To associate priorities with particular projects, add them to a priority scheme and then link that scheme to your project.
If you do set up your own priorities, be wary of adding too many and/or making them too vague. It is generally advisable to reduce unnecessary complexity, as this helps to avoid redundancies in your workflow and ensures that you prioritise work in Jira in a way that is most effective.
Use Flags To Highlight Blocked Jira Issues
If something is preventing a task from being completed, it is beneficial to highlight it as soon as possible, so all team members are aware of blockers that may potentially impact their own work or which they may be able to assist with.
A simple way to draw attention to blocked issues in Jira is to add a flag, which highlights the issue in yellow in locations such as the backlog and the Jira Kanban board. It also replaces the priority icon with a flag icon.
To flag an issue, open it and then click the cog to open a dropdown menu. Select ‘Add flag’, (‘Remove flag’ to take it off again). Alternatively, you can right-click an issue and then choose ‘Add flag’ from the context menu. If you want to leave a comment on the issue as well, you can select ‘Add flag and comment’.
As well as being a quick, visual way to spot blockers, flagged issues can also be searched for with a simple bit of JQL: Flagged = Impediment.
Use Reporting to Prioritize Work in Jira
The sheer amount of data that Jira can spit out can, quite frankly, be overwhelming. It’s a hugely powerful tool, and if you’re not careful, you can find yourself wading through a seemingly never-ending tide of epics, stories and a growing backlog. If you want to see the bigger picture, to get a clearer understanding of your team’s work processes and so you can better prioritize work in Jira, you’d be better served by collating data into relevant graphs and tables. That’s where reporting comes in.
Out of the box, Jira has some basic reporting functionality, with the ability to make various graphs and charts. Unfortunately, they are severely lacking when it comes to customized Jira reporting, so users often find they can’t quite create the charts they want or access the data in them in a user-friendly manner.
The good news is that thanks to the extensibility of Jira, there are many ways of adding extra functionality to Jira data visualization reporting features, including high-end business intelligence solutions. However, many of them are hugely expensive or so complex that they alienate and exclude all but the most technically minded people, typically leaving only one or two experts within a company to operate them.
For many organisations, the ideal solution is one that balances features with accessibility. That’s why Old Street Solutions built Custom Charts for Jira. Its interface is designed to be easy to operate, so even novices can quickly bring up informative charts and start customising them. With just a few clicks, they can set up colours, filters and chart types exactly how they wish. At the same time, Custom Chart for Jira has enough underlying power that more experienced users can further define their charts and tables, using custom JQL or saved filters.
With the help of Custom Charts, users and project managers can see, at a glance, everything from the number and severity of outstanding issues to how much time has been spent dealing with blockers. They can access pie charts, bar graphs and more, with the ability to quickly drill down from the macro level into the details using the Custom Charts – Simple Search gadget.
By presenting information about your workflows through these charts, you and any other stakeholders can begin to better understand the data held within them. This will enable you to make more informed decisions about how you prioritize work in Jira.
Try The Atlassian Playbook
Finally, if you’re looking for more advice about how to prioritize work in Jira, you could certainly do worse than checking out the Atlassian Team Playbook. This extensive library of self-guided workshops is a valuable resource for any teams that are struggling to find the best working methodologies for their business. You might, for example, try the Allthethings Prioritization Matrix play, an hour-long workshop designed to help you team visualise the priority of their projects compared to work requested by other teams.
However you choose to address the challenge of prioritisation, it’s important to understand that any time you spend on it is an investment: what you put in now can potentially save your teams significantly more time and effort later. As stated at the start of this post, you should aim for consistency, above all else, but you can greatly enhance the effectiveness of your work methodology by using reporting solutions like Custom Charts for Jira.
For more information about Custom Charts for Jira or any other Atlassian add-ons from Old Street Solutions, check them out on the Atlassian Marketplace.