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 are providing organization-wide free trials until the end of June 2019, 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.
After loading your data into Analytics, there is a section in the right menu titled "Workflow Stages" that lists all of the imported workflow stages. 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.
Our simplifying assumption is that your workflow should be sequential and linear: an item starts being worked on in the first workflow stage, is complete when it enters the last workflow stage, and never moves backwards into previous stages.
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. Many process tracking tools don’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 work item/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.
In short, no. In our Agile method, workflow should be linear and sequential. Is blocking something really part of getting it done? We recommend leaving the work item in the column where it became blocked and adding a “Blocked” attribute or tag, 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.
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 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 it.
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.
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.
If you’ve already purchased a subscription to our standalone/SaaS version but want to migrate to our Azure DevOps extension now that it’s available, please Contact us and we’ll be happy to help.
Our ActionableAgile Analytics Azure DevOps extension is available for a 30-day, fully-functional, company-wide free trial. After that, the extension is licensed on a single-user basis--that means you only pay for the number of users you want to have access, regardless of your organization's collections or projects. Pricing for a single-user license is available in two durations: monthly, at $19/month and yearly, at $200/year.
Licenses are purchased directly from ActionableAgile as per Microsoft's policy. We use Stripe to process all payments, so we never see your sensitive financial information.
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.