How Jira Align Supports Flow Metrics

[#1]

I keep getting asked, does Jira Align support Flow Metrics, as defined in the Flow Framework and SAFe? The short answer is yes. If you believe these metrics will help unlock the potential of your teams, use this community post to see working examples of Tableau reports I have created using Jira Align and Enterprise Insights.  

Flow Metrics

The Flow Framework provides five metrics that can be used to measure different aspects of flow. As SAFe is a flow-based system, each of these metrics is directly applicable. In addition, SAFe defines Flow Predictability to measure how Teams, ARTs, and Solution Trains are delivering against their planned objectives.

Metric	Description
Flow Velocity	Number of items completed in a given time
Flow Time	Time elapsed from when an item enters the workflow until it is released
Flow Efficiency	The portion of backlog items actively being work on, relative to total time elapsed
Flow Load	Total backlog work in process (across the entire workflow)
Flow Distribution	The proportion of backlog item types in the flow
Flow Predictability	Overall planned vs actual business value delivered in a given time

In the Tableau report examples below, I used common elements when applicable. The main area of each report is displaying moment in time information, usually defined by a PI or quarter and grouped by value stream. If in Tableau or viewing these reports within Jira Align, if you clicked on an element (square or circle) you’d have the option to navigate back to Jira Align to view all of the details relative to the work item. In the upper right of the detailed reports, you’ll see the moment in time information displayed as an average or aggregation. Last, if appropriate, I’ve added a historical trend. This allows the viewer to know where they have been and the direction they are headed.

Flow Velocity  

gauges whether value delivery is accelerating. Flow Velocity is the number of Flow Items completed over a particular period of time. Everyone else in the industry calls this Throughput. Each square on the report denotes a feature (flow item) completed within the timeframe. Selecting a square will provide a link back to Jira Align, where the user can view all of the details.

Flow Time

measures the time elapsed from ‘work start’ to ‘work complete’ on a given Flow Item, including both active and wait times. Everyone else in the industry calls this Lead Time or Time to Market. Each circle on the report denotes a feature (flow item) in a value stream. Selecting a circle will provide a link back to Jira Align, where the user can view all of the details.

Flow Efficiency

identifies waste in a value stream. Flow Efficiency is the ratio of active time out of the total Flow Time. In the example, each row is a feature completed in the last PI. The green numbers are the number of days in active states. Red numbers denote days in inactive states. Everyone else in the industry calls this Process Cycle Efficiency or Cycle Time Efficiency.

Flow Load

monitors over and under-utilization of value streams, which can lead to reduced productivity. Flow Load measures the number of Flow Items currently in progress (active or waiting) within a particular value stream. Each square on the report denotes a feature (flow item) in a value stream. Selecting a square will provide a link back to Jira Align, where the user can view all of the details. Everyone else in the industry calls this Work in Progress (or Process) or WIP.

Flow Distribution

illustrates the tradeoffs between Flow Items in a reporting period. Flow Distribution measures the distribution of four Flow Items — Features, Defects, Risks and Dependencies — in your value stream’s delivery. (if you have other item types that take up delivery capacity, include them)

Flow Predictability

illustrates how well teams, ARTs and Solution Trains are able to plan and meet their PI objectives. How is it measured? It's the ratio of planned and actual items over time. Low or erratic predictability makes delivery commitments unrealistic and often highlights underlying problems in technology, planning, or organization performance that need addressing. Reliable trains should operate in the 80 – 100 percent range; this allows the business and its stakeholders to plan effectively.

Conclusion

Ask any Kanban practitioner and they will say there isn’t anything new about these metrics. They’ve been around for years. But now that they’ve been repackaged and referenced in SAFe, there is newfound interest. If you or someone you know is interested in Flow Metrics and using Jira Align, Enterprise Insights, and Tableau (or other reporting platforms), leave your comments and let me know what you think.

[Aline Chapman]

Thanks for sharing this information. Are any of these flow metrics available natively in Jira Align?

[Jesse Pearlman]

@Derek Huether Excellent breakdown on Flow and how it's all driven from Kanban metrics. This single differentiator I find is the call out of the Flow Distribution explicitly.

@Aline Chapman Jira Align has elements of those reports under different terms: Work In Process, Process Flow, Lean metrics to name a few. 

However, for more robust reporting against these specific measures, review @Derek Huetherother community posts on using Enterprise Insights and other Business Intelligence tools.

[lou_rodriguez]

Hello @Derek Huether 

This article is great!  Thanks for all the work you put into this. 

I have a question for you.  Do you know how to pull these flow metrics through the Align REST API?

[Derek Huether]

@lou_rodriguez due to rate limiting and complexity of the data model, I don't think using the REST API would be a viable solution.  I would recommend using Enterprise Insights. It's a seperate DW that will structure the data properly to allow you to build those reports or you could use it to pull the data into your own data lake. 

[lou_rodriguez]

Thanks for responding @Derek Huether Your answer is extremely helpful. 

My company is building an app that pulls flow metrics from Jira Align.  We would like to connect our app to our customers instance of Jira Align and pull these metrics for our own in app reporting. 

How would we connect Enterprise Insights to our data lake?  Is their an API we could connect to or is there a wizard within Enterprise Insights that points towards our data lake?

Thank you

[Derek Huether]

@lou_rodriguez You can ingest data into your data lake from Enterprise Insights by making a connection to the database and reading the data. Easily half our Enterprise Insights customers use it as a source for loading a data lake.  An export_dw schema exists to serve that use case (maintaining row timestamps on all tables and soft deletes). You'll either build your ETLs to make db connections or we spin up the Enterprise Insights API and you can call the same tables via the API to load them.

Hope this helps!

[lou_rodriguez]

Hi @Derek Huether . Thanks again for responding so quick.

Are you implying the Enterprise Insights API is not on?

How would I put in a request to turn it on?

[Derek Huether]

@lou_rodriguez your customer would just need to purchase Enterprise Insights. Have them reach out to their sales person. If they purchased Jira Align, they have a designated contact. Then they (you) choose how you want to access the data.  If API is your preference, just let them know and they'll spin up the EI API for you.

[lou_rodriguez]

Hi @Derek Huether 

I recently came across the Swagger Jira Align API endpoint 

Can't we use the /rest/align/api/docs/2/swagger.json. endpoint to pull the data necessary to create flow metrics?

Keep in mind we are creating an application that will connect with our customers instances of Jira Align and we don't want to make a subscription to EI a requirement to pull flow metrics.  

Our goal is for our application to be able to pull:

• Flow distribution
• Flow velocity
• Flow time
• Flow load
• Flow efficiency
• Flow Predictability

Another question is what combination of endpoints in the swagger API would we need to use to pull these metrics?

[Derek Huether]

@lou_rodriguez I do not see using the API as a practical solution for creating these metrics. To ensure our platform remains stable, all Jira Align APIs are rate-limited. Currently, if calls from the same IP address exceed 600 requests per 60 seconds, calls are blocked for 60 seconds. We ask developers to use industry-standard techniques for limiting calls, caching results, and re-trying requests responsibly. 

Without Enterprise Insights, you'll have to locate the endpoints and do all of the custom calculations, while running the risk of having calls blocked. I can't offer you a combination of endpoints because I did not use the API. I used Enterprise Insights to create the Flow Metrics.

[Brian M_ Smith]

Is there a similar article for JIRA cloud?  Which of these metrics can be measured out of the box with JIRA cloud?   Which ones require you to purchase JIRA Align?

[Peter Jetter]

Similar: when will we get the DORA key metrics out of the box? 

• Deployment Frequency—How often an organization successfully releases to production

• Lead Time for Changes—The amount of time it takes a commit to get into production

• Change Failure Rate—The percentage of deployments causing a failure in production

• Time to Restore Service—How long it takes an organization to recover from a failure in production

Or at least a playbook how wrangle them out of Jira+CI/CD tools.

[Derek Huether]

@Peter Jetter insights like DORA metrics should be available with the rollout of Atlassian Data Lake.

[Derek Huether]

@Brian M_ Smith actually, all of the data in these reports originated from Jira Instances.  Large customers are asking for these metrics. Jira Align plus Enterprise Insights structures the data so it was easier for me to use Tableau to create these reports. Nothing precludes you from connecting to Jira to generate these reports. You just need to know how to properly structure the data elements, do the calculations, and have a reporting platform that gives you the visuals you want. As with my comment to @Peter Jetter Atlassian Data Lake will start making what you want to do much easier. 

[Dhruv Doshi]

@Derek Huether What calculation did you do to calculate the Active Time and Wait time? Can you please provide some details on that? What fields are you using to calculate those?

[Derek Huether]

@Dhruv Doshi active time was summed days in what we defined as "active" workflow states, like In Dev. Wait time was summed days in queues, like Backlog, Ready for Dev, Ready for Test.

I created calculated fields for DATEDIFF of each flow state. I then identified which were Active vs Waiting.

[Dhruv Doshi]

@Derek Huether Atlassian suggested we use Split Feature option on the features whenever we have a feature which is being carried over to the next PI. As mentioned below:
 https://community.atlassian.com/t5/Jira-Align-questions/How-to-handle-feature-carryover-across-PIs/qaq-p/1699092

Do you know how is this reflected in Enterprise Insights database. I know that there is a Split flag. So I am concerned as to how this affects Flow Time. Since now the original feature as been split into Part 1 and Part 2 where Part 1 is marked Done while Part 2 is not so how do we account for flow time for such carry over features.  

[Derek Huether]

@Dhruv Doshi I can't say I agree with the practice of splitting. It's my own personal bias. As you know, it will hide bad behavior through the shorter Flow Time of Part 1. But I understand why it's being proposed. Given the objects are related, you'll have to add additional logic WHEN IF there is a split flag, add part 1 to part 2 to get a true(r) flow time. You might even consider creating a "split feature" report to see just how pervasive splitting is with your teams.

[Dhruv Doshi]

@Derek Huether The reason for splitting is because I can only assign 1 PI to a feature and changing the PI on a feature that's already in progress can break the relationship with accepted stories. Hence if we use the Split feature option it breaks the flow time metrics. I was planning to use the split flag logic you explained above but wanted to see if you had any better suggestions or recommendations. 

[Derek Huether]

@Dhruv Doshi start looking for the root cause of the feature needing to be split. Do you need smaller Portfolio commitments? Do you need a better definition of ready? Maybe it's team dependencies that are delaying the completion of work? Use this as a catalyst to find out why you need to split these in the first place. You could come out the hero in this, if you are able to find the root cause.