Use the menus within the Analytics plugin (upper right) to load a Jira Board, Filter, or Project. Boards are easiest because they pre-define your workflow, but you can still load a Filter or Project; you’ll just have to use the dialog box to map statuses onto workflow stages the first time you load the data. Once the data is loaded in Analytics, you can use all of the charts, filter work items, and control your workflow. We recommend opening Analytics in a new tab and leaving it open indefinitely so you don’t have to navigate within Jira, which will slow you down.
Please see our other FAQ questions about workflow for the assumptions on which Analytics relies.
Our plugin is located under Jira Reports. A simple way to access it is to choose the Projects option on the left navigation bar and choose any of your projects (regardless of what project you want to use in the plugin; you can load any project in Analytics once you open it). Then, choose Reports and All Reports. ActionableAgile Analytics should be an option in the list.
After loading your Jira data into Analytics, there is a section in the right menu titled "Workflow Stages" that lists all of the workflow stages imported from Jira. There, you can check and uncheck workflow stages to include them or exclude them from Analytics' calculations. The first selected workflow stage is when Cycle Time begins and the last selected workflow stage is when Cycle Time ends, and all unchecked stages in between are ignored. Throughput is calculated using the difference between the dates when an item enters and exits the checked workflow stages.
Analytics was intentionally built without any knowledge of the ways that systems like Jira store data because they vary so much. Our simplifying assumption is that workflow is sequential; an item starts being worked on in the first workflow stage and is complete when it enters the last workflow stage. Analytics therefore calculates when an item is Done based solely on the date that it enters the last column of your workflow, no matter what the column is called and no matter its state or resolution in Jira.
That being said, Analytics does provide you control over which workflow stages you want to consider part of your process. As you may have noticed, there is a control called Workflow Stages in our sidebar which you can use to disable (or enable) workflow stages based on whether you want Analytics to use them for calculations. Effectively, by changing which workflow stage is the last one selected, you can control which items are counted as done. Jira doesn't require an explicit workflow, so our challenge is to map statuses to workflow stages. Once you have done that, you can use all the tools within Analytics to decide what constitutes your workflow (and what constitutes an item being done).
You can see the workflow data that is being imported into Analytics via our Source Data "chart," which can be found in the dropdown menu at the top center of the plugin. The first line shows the column names, and every line after that is an issue/work item and the dates it enters each workflow stage. When you enable workflow stages with the Workflow Stages control, you can use this page to see how your data changes.
If you have a well-defined workflow, Analytics can help you regardless of your methodology. The most important thing is deciding when work starts and when it finishes--that’s all we need to determine the key metrics of Cycle Time, Throughput, and Age. We’ll load other information from Jira about your work and workflow, but starting and finishing work is by far the most important thing.
After your Jira data is loaded into Analytics, you can use the Workflow Stages control to select the parts of your workflow you want to use. Work is considered to be started when it enters the first enabled workflow stage, and it’s done when it enters the last selected stage, so checking and unchecking boxes will change all your metrics. Since the data is already loaded, it’s fast, so feel free to play around with it.
Please note that Jira statuses do not contribute to whether a work item is done or not.
It can work well with Scrum, but it really matters when you start and finish your work items. Many Scrum processes push all their work items into the first workflow stage at the beginning of the sprint, and then push them out of the last workflow stage at the end of the sprint, which makes for irregular predictions. The main thing to remember with the Monte Carlo is that its only input is historical daily throughputs, so you can imagine how the previously described Scrum process would make for an inaccurate Monte Carlo. As long as you understand how the Monte Carlo works and try to only make predictions that make sense with your sprint pattern, it should work for you. Many Scrum teams who use our tool use sprints only for retrospective and planning purposes, not for actual start and stop dates of work items. In our opinion, this is the best of both worlds!
That being said, we have plans for a Scrum version of the tool that supports using whole sprints as time units, but we're not sure of its priority yet.
For every issue (or work item), Analytics extracts “flagged” dates from Jira and uses them to determine how many days the item was blocked. You can see the values that are extracted by opening the Source Data chart in Analytics and looking at the Blocked Days column.
In short, no. In our Agile method, workflow should be linear/one-way sequential. Is blocking something really part of getting it done? :) We recommend leaving the issue in the column where it became blocked and marking it as flagged in Jira, not putting it in a different workflow stage. This allows you to measure total time blocked without disrupting your workflow. Additionally, the Flow Efficiency Chart uses this information and can tell you how much time items spend waiting versus actually being worked on.
The short answer is that you cannot. We have considered this extensively, and there's not much benefit except in the very shortest time frames (sub-week), and those situations are best analyzed differently. There are many complicating factors, including allowing for exceptions, handling holidays, and dealing with work that was completed on excluded days, and in our consulting experience we have found that for most clients it causes more problems than it solves, without improving the accuracy of the results.
Our co-founder and CEO, Daniel Vacanti, writes about this extensively in his books, which we highly recommend. You can learn more about them here.
No, you don’t! When you select a project from the Recent Projects(/Boards/Filters) subheading, the data associated with that project is not reloaded from your Jira instance but is instead retrieved from your browser cache. This is done to reduce server load and decrease wait time. So if you've made structural changes to the board or think your data is getting out of sync, it's best to do a fresh reload by choosing your project from the "All Projects" section of the dialog box. For these same reasons, Analytics does not look for new projects, boards, and filters every time you open this dialog box, so if you’ve added a new project, board, or filter, you will need to hit the “Reload” button at the top right to re-retrieve your data from Jira.
We do allow trial extensions under some circumstances. However, we do not have direct control over extensions, so you must first submit a request to Atlassian by following these instructions:
1. Go to https://www.atlassian.com/company/
2. Under the "Pricing, billing & licensing" option, click "Contact Us"
3. Select the "I'm a Customer" radial button
4. Choose the "Extend product trial" option under the dropdown menu.
While you are waiting for Atlassian's response, please contact us using the form at the bottom of this page to let us know that you have requested a trial extension through Atlassian and we will guide you through the remainder of the process if we approve.
Unfortunately, Atlassian's pricing model forces users to purchase the plugin for every Jira user. For this reason we have drastically discounted our per-user pricing when you purchase the plugin through the Marketplace. We are hoping to eventually develop an alternative to this, but the plugin also has a free 30-day trial that everyone on your team can use.
Another potential solution is the open-source Jira-to-Analytics on GitHub. It is a standalone extract tool (without a user interface) that can be set up to automatically produce an extract file that you can then load into our site version of Analytics yourself after purchasing a license. Since it's open-source, you can customize it to your needs. We are not involved in the support of this tool, but we have lots of users who use it and are happy with it.
One of the ways to access Jira data in Analytics is to use our standalone tool at analytics.actionableagile.com and use the dropdown menu to choose "Load a Jira Board." You will be prompted to enter your Atlassian login and will then be able to import a Jira Board into the tool. Our standalone tool has a 14-day free trial, after which you can purchase single-user licenses for $19/month or $200/year. However, Jira access through the standalone tool is limited to boards, and issue attributes are more limited than in our plugin version.
We are planning to provide a Data Center Approved version of ActionableAgile Analytics in Q2 2019, but until then, Analytics is not compatible with Jira Data Center.
You may have loaded a cached version of your data. When you select a project from the Recent Projects(/Boards/Filters) subheading, the data associated with that project is not reloaded from your Jira instance but is instead retrieved from your browser cache. This is done to reduce server load and decrease wait time. To reload your data, choose it from the All Projects(/Boards/Filters) heading or choose the Reload option in the top right of the loading dialog box (see red arrow below).
Alternatively, most of our Jira users have colossal amounts of work items and Jira’s API is rather inefficient, so we automatically check the box labelled “Load only issues created after [date]” when you load your Jira data (see blue arrow below). This reduces server load, prevents crashes, and improves response time. You are welcome to uncheck this box or adjust the “created after” date.
Please try disabling your adblocker for atlassian.net and reloading. For some reason, adblockers do not appreciate the URL through which we filter our request.