Frequently Asked Questions (FAQ)

You can find the ActionableAgile Analytics extension in the Visual Studio Marketplace. Click the green Get button and follow the prompts to install it in your organization. We provide 30-day free trials, after which you can purchase single-user licenses for as many users as you would like.

After installing the extension, navigate to your Azure DevOps homepage, which is usually found at dev.azure.com/yourorganization. From there, choose any project, select the Boards option from the left sidebar, and choose “ActionableAgile Analytics”. Please note that you can load any project within the extension, no matter which project you chose when you navigated to it.

The free trial is 30 days.

Yes, the trial is fully-functional. All features are available during the trial that you will have during your subscription.

No, it depends on the access level in Azure. Users with Stakeholder access in Azure DevOps do not have permissions to view and edit Analytics views, for this reason they will not be able to use ActionableAgile.

Although we normally adhere to our 30-day trial period, we do occasionally grant extensions under certain circumstances. Contact us if you’d like to request an extension.

Yes. Beginning in Sept, 2020, the licenses are specific to a particular user/organization combination. If you belong to two Azure DevOps organizations and you want to use ActionableAgile for each, you’d need two licenses.

If you would like to buy bulk licenses for your organization and would like to discuss discount pricing, contact us.

No, your license is specific to the platform you purchased it for.

ActionableAgile Analytics is available either on a Per-Seat or Domain-wide license.
Domain-wide licensing:

It is possible to purchase a domain-wide license so that anyone within an email domain can create an account and be automatically authorized for the tool. This means you won’t have to manage users for a specific number of seats. The cost of the license is highly dependent on the number of folks in your domain. So, if you’re interested in this model, please reach out to us via a support request to get a quote.

The license would be annual and paid via invoice.

Per-Seat Licensing:

The user manager (person who started the subscription) can decide the number of users to invite to the subscription. The user manager will then manage who has access and remove users if necessary. How does this work?

The license can either be paid monthly or annually.

Monthly subscriptions (per-seat only)

The only option is credit card payment via our billing portal. Read more.

Annual subscriptions

The payment can be made by credit card via our billing portal, for subscriptions with at least 5 users (min $1000/year), it is possible to pay via invoice. If you wish to pay via invoice, please reach out to our support team to set up the process.

We first require that in your process you have a well-defined workflow stage that you consider an item to have started and you have a well-defined workflow stage that you consider an item to have finished. From the workflow data that you upload, we take the last workflow stage's date and subtract the first workflow stage's date and add 1 (the 1 makes the calculation inclusive and prevents Cycle Times of 0).

ActionableAgile Analytics, however, provides you with more granular control over which workflow stages you want to count as started and finished. As you may have noticed, there is a control called Workflow Stages on our right sidebar which you can use to disable (or enable) workflow stages. We will always calculate Cycle Time from first workflow stage selected on the sidebar to the last workflow stage selected on the sidebar.

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 a 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.

After loading your data into Analytics, there is a section on the right sidebar titled "Workflow Stages" that lists all of the imported workflow stages. There, you can check and uncheck workflow stages to change which workflow stage counts as started and which workflow stage counts as finished. The first selected workflow stage is when Cycle Time begins and the last selected workflow stage is when Cycle Time ends.

In short, not really. We recommend leaving the work item in the column where it is blocked and then adding a “Blocked” attribute or tag to the item. 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.

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 for Azure DevOps looks for a tag called “blocked” on a work item. The case doesn’t matter. ActionableAgile tracks how long it had the tag (in days) and if it currently has the tag. We count partial days except in the case in which it is blocked and unblocked in the same day.

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 WIP, Cycle Time, Throughput, and Age. We’ll load other information about your work and workflow from the data you give us, but starting and finishing work is by far the most important thing.

After your 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 different settings and filters.

It can work well with Scrum, but it really matters when you start and finish your work items. If your Scrum Team pulls all Sprint Backlog PBIs into progress at the beginning of the Sprint, and then closes all of those PBIs at the end of the Sprint (Scrum does not necessarily recommend doing this, by the way), then you may not get the results you are looking for. For more on how to use flow metrics in your Scrum-based process, please see Scrum.org's Professional Scrum with Kanban (PSK) class.

To sign up for PSK classes run by 55 Degrees, click here.

The goal is to track the flow of PBIs through your workflow. Tracking items that are sub-value (tasks) isn’t helpful in optimizing for a smooth flow of value. So, in order to utilize ActionableAgile to help analyze and improve that flow of PBIs between committed and done, you need to visualize it on your board. You can look at Microsoft’s documentation for adding columns to your board for instructions on how to do that: https://docs.microsoft.com/en-us/azure/devops/boards/boards/add-columns?view=azure-devops

Right now you can only load team boards, but we expect to deliver additional loading options in the future for our Azure users.

No. There are many complicating factors at work here, including allowing for exceptions, handling holidays, and dealing with work that was completed on excluded day. In most cases it causes more problems than it solves, without improving the accuracy of the results.

The creator of ActionableAgile Analytics, Daniel Vacanti, writes about this extensively in his books, which we highly recommend. You can read about this topic and more in those books, which you can find here.

The new data loader features two ways to load data, By Board and By Work Item History. So it’s the same way you loaded data before, but better.

We’ve added the workflow mapping stage to give better control on how time is allocated. We are now able to catch historical changes ie. a deleted board column or state and allow the user to map them so that ActionableAgile can provide more accurate analytics. In the previous loader this data was lost.

Loading by Board will give you the data of one specific board that you chose with all the data linked to that board.

Loading by Work Item History is great for when you’re looking at data from a higher perspective or you have to take multiple teams into account.

The grey circled number next to your state indicates the number of times an item has gone through that state or column (based on what you selected in step 1). It’s important to map this to the most relevant ActionableAgile workflow stage as you’ll lose visibility of this data if it isn’t mapped. Unmapped states/columns contain time spent in them, when unmapped it does not disappear, ActionableAgile assigns it to the previous known state or column. Leaving unmapped states/columns can inflate the results and will provide less accurate data.