- Created by Julia Wester, last modified by Eloise Vinson on Aug 23, 2023
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 15 Next »
About ActionableAgile Analytics
Our Analytics tool works by taking your own date-driven process data to turn it into meaningful Analytics. Your data can come in the form of a specially formatted CSV, MS Excel (see an what an example data file looks like here), or JSON file, or can be automatically imported from Jira using our wizard. Please visit our Quick Start page for more information on getting started.
Absolutely not. Your data is yours and it should stay that way. You never transmit your data to us, so we never get a chance to store it. The whole application runs completely within your browser on your local machine.
You can sign up for a 14-day free trial of the full version of ActionableAgile Analytics (no credit card required) by visiting https://analytics.actionableagile.com. To learn how to get started with your own data, visit our Quick Start page. When you’re ready to buy, you can find our Purchasing Options here.
We integrate with Jira Cloud and Trello using upload wizards. You can also load your data directly via a CSV or XLSX (MS Excel) file (see how: Uploading CSV Data). Bottom line is, if you have access to your data, then you can use our tool. For more information about importing data, and to try the full version of ActionableAgile Analytics with your own data, visit our Quick Start page. If you use a tool that we don't support yet, Contact Us for information about custom integration.
Basic Usage/Workflow
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, then (see above), 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).
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.
We really recommend the book “ Actionable Agile Metrics for Predictability” by Daniel Vacanti. There is a whole section on this!
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.
There is currently no way to track blocked time in Trello.
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.
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.
Publications: The Resources You Need to Get Started
Both books are available at Leanpub (in e-format), and Actionable Agile Metrics for Predictability is also available on Amazon (e-book and paperback).
- No labels