Frequently Asked Questions (FAQ)

Based on your Jira instance, there could be different ways to access ActionableAgile. Read this document to learn more: Finding ActionableAgile in Jira.

After loading your Jira data into ActionableAgile, there is a section in the chart controls area on the right titled "Workflow Stages." This shows the stages of the work's lifecycle that you defined and mapped Jira statuses during data loading.

You can check and uncheck workflow stages to include or exclude them from the chart calculations. The first selected workflow stage is when Cycle Time begins, and the last selected workflow stage is when Cycle Time ends.

Read more about configuring and mapping the workflow and using the workflow stages control on the Cycle Time Scatterplot Chart.

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, ActionableAgile 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 ActionableAgile, 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!

Check out our webinar on this topic

If an item has been in a workflow stage only once, the date associated with that stage is the date the item entered that workflow stage. If an item has been in a workflow stage more than once, the date associated with that stage is the last date the item entered the workflow stage.

Detailed Information

If an item is moved backwards in the flow, say from step C to step B, it is considered never to have been in step C at all. All of the time in step C will be added to the time in step B. It will get a new timestamp for step C when it reenters that workflow stage.

Ex.) Say you got in the checkout line at the grocery store but then forgot something. Until you enter the line for the final time, the checkout line clock doesn’t start. Until then you were shopping, with a slight detour.

For those expecting to see a cumulative total of all days spent for an item in any given stage in the Cycle Time charts, you might be very confused as to why we do it this way. This is intentional as the app is designed for helping facilitate the flow of work through the process as smoothly as possible.

The Logic Behind It

In flow-based systems, we attempt to optimize the journey of the work through your system. Visibility into what happens in each stage is very important to this goal. In a board, when you move a card backward, say from Testing back to In Progress, you lose all visibility that a card was in the Testing state before. It is a statement that it was a false start, it wasn’t ready for that stage so it went backwards.

If that isn’t the intent of the backwards motion, there are other approaches to workflow building and board visualization that could be considered that don’t have the negative effect of blocking visibility as discussed above. One is often is to re-think the definitions of the workflow stages.

A lot of times we think of an In Progress stage as the domain or inbox of a particular role, say a software developer, and Test as the domain or inbox for someone else, like a QA analyst. Instead, you can consider the “Test” workflow stage to contain both the Test work and all resulting changes. Obviously you’d like for there to be minimal or non-existent work after testing. Keeping an item in Test for the duration of all of this activity really highlights how long it has been since Testing first began and can cause discussions about how to decrease time since Test started (which obviously can vary wildly). It may also make people more cautious about moving forward, which can be a good thing.

Did you know?

The way we treat backwards movement is actually what allows a Cumulative Flow Diagram to display properly. Lines on a cumulative flow diagram should never go down.

ActionableAgile support the most commons custom field types, here is the full list:

jsw-story-points
float
labels
multicheckboxes
textfield
multiselect
radiobuttons
userpicker
multiuserpicker
gh-sprint
gh-epic-label
gh-epic-link
select
multiversion
rm-teams-custom-field-team
sd-customer-organizations

If you have a field which does not show in the drop down in step 3 of the data loading process, it could be because this field type is not currently supported. In this case, please reach out to our support and confirm which custom field type you are missing. This information can only be accessed by your Jira admin in the Custom Field Configuration.

ActionableAgile for Jira looks for any items that have been “flagged” with Jira’s native flagging functionality.

For every issue (or work item), it extracts “flagged” dates from Jira and uses them to determine how many days the item was blocked. We count partial days as blocked days unless it was blocked and unblocked in the same day. In those cases, that day is not counted as a blocked day. You can see the values that are extracted by opening the Source Data chart in AA and looking at the Blocked Days column.

In short, no. In our Agile method, the 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 and our charts will properly recognize blocked time.

For more, please read about how we handle backwards flow in ActionableAgile and why.

Finally, if you have a blocked column at the very right of your board, this will also cause issues with our app not considering work finished when you first load the data. Until you remove your blocked column, you’ll need to uncheck that workflow stage in the Workflow Stages control for all charts so that your analytics will function properly.

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.

The ActionableAgile 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 the 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.

On the Atlassian Marketplace, Cloud users get a 30-day free trial and Data Center users get a 30-day trial renewable up to 5 times (for a total of 6 months for free).

Please review the Trial section of the Atlassian Marketplace FAQ here https://www.atlassian.com/licensing/purchase-licensing

Need a longer trial due to your procurement cycle?

If you need a longer trial to support a longer procurement cycle, please contact us at 55 Degrees. We will then be able to raise a ticket to Atlassian to provide the extension.

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 ActionableAgile for Jira as opposed to purchasing licenses to ActionableAgile as a standalone web application where Jira access is limited to boards and issue attributes are more limited than in the plugin version available through the Atlassian marketplace.

Yes, it is! You can purchase ActionableAgile for Jira whether you use Jira cloud, or Jira Data Center. Try it now via the marketplace!

We cannot provide quotes or invoices for subscription purchases sold through the Atlassian Marketplace. When purchasing ActionableAgile for your Jira instance, you can request a quote from Atlassian through the Quote & Order Form.

Whether you pay monthly or yearly will match how you pay for your Jira instance.

Please contact us at 55 Degrees with your SEN and Entitlement Number to request a discount coupon.

Here is Atlassian’s FAQ and support document for Atlassian’s new cloud billing engine.

It could be because of an adblocker. For some reason, they do not appreciate the URL through which we filter our request. Please try disabling your adblocker for atlassian.net and reloading.