Search Results

When I first became a manager (more years ago than I care to admit), I inherited a team full of smart, dedicated people. Everyone was working hard. Meetings were full of good ideas. But we still weren’t delivering. Deadlines slipped. Priorities shifted. Work dragged on far longer than expected. We weren’t lazy. We weren’t disorganized. But we also couldn’t explain why things weren’t getting finished. And that made it really hard to improve. Then someone introduced me to flow metrics. We started measuring how work moved through our process — how much we got done, how long things were taking, and how much work we had in flight. That visibility changed everything. We could see bottlenecks. We could spot aging work before it became a problem. And slowly but surely, our delivery became more predictable and less stressful. What Are Flow Metrics? Flow metrics help you understand how work moves through your system. They’re simple, practical measurements that reveal where work is flowing smoothly and where it’s getting stuck. No crystal balls required. The four core flow metrics are: Throughput : How many work items you complete in a given time period WIP (Work in Progress) : How many items you’re actively working on Work Item Age : How long your current work items have been in progress Cycle Time : How long it takes to complete work from start to finish Each metric tells you something different, and together they give you a clearer, more actionable view of how your team works. Who Can Use Flow Metrics (and Why)? Flow metrics aren’t just for specialists or process geeks. If your work depends on delivering value - and most work does - these metrics can help. Here are just a few roles that can benefit: Team Leads & Scrum Masters: Spot bottlenecks, balance workloads, and support a healthier, more sustainable pace of delivery. Product Managers: Improve forecasting, prioritize realistically, and align delivery expectations with stakeholders. Engineers & Designers: Get insight into how often you’re being interrupted or asked to multitask, and how that affects delivery. Executives & Stakeholders: Understand delivery trends and risks without needing daily status updates. Agile Coaches & Change Agents: Use data to drive conversations, measure improvements, and support teams more effectively. This list isn’t exhaustive. If your role touches delivery in any way, from strategy to implementation and onwards to support, flow metrics can give you valuable insight into how to work smarter, not just harder. Ready to Learn More? If you want to dig deeper into each of the four core metrics, we’ve got you covered: What is Throughput? What is WIP? What is Work Item Age? What is Cycle Time? Understanding your team’s flow is one of the most effective ways to reduce chaos, increase predictability, and create a better experience for everyone involved in delivering value. Want to Go From Insight to Action? Understanding your flow is the first step. Taking action on it is where the real magic happens. ActionableAgile® Analytics  helps you visualize, analyze, and improve your flow using the very same metrics you’ve just read about. Whether you're looking to increase predictability, reduce lead times, or simply make your process more transparent, our tool can help. Try it for yourself or get in touch  to learn how we can support your team.

Adopting flow metrics can feel like trying to convince your team to give up coffee......difficult and a little dangerous. But it doesn't have to be. In our recent webinar with ProKanban.org , we tackled the big questions: How do we overcome resistance? How do we make flow metrics meaningful to teams? And how do we introduce them without causing mass panic? Here are the key takeaways to help you build buy-in without breaking trust. Missed the webinar? Watch it on Youtube. Bringing Flow Metrics to Your Team What’s the best way to introduce flow metrics to a team that’s never used them? You might worry that if you suddenly start talking about cycle times and throughput, you’ll get blank stares – and you’re probably right. Rita suggests a gradual, data-informed approach to get buy-in: “If you come straight into a stand-up and say, ‘ from now on we’re going to use flow metrics ,’ you’ll get probably blank stares… People will wonder what’s happening.”   Instead, begin collecting some data in parallel to your current process. Start measuring how long your work is actually taking and how much you’re delivering. “I started to look at the metrics… I thought, oh, what’s happening here? We have a lot of variation,”  Rita says, describing her own journey. She brought these findings into a retrospective, using real data from the last few weeks to reflect on how work was flowing. Poll results from our live webinar The key is to introduce flow metrics gradually as helpful information, not as a sudden mandate. You might start by examining recent cycle times and throughput in retrospectives or sprint reviews (looking at historical data is a lagging  measure). As the team becomes more comfortable, you can begin using leading  indicators like work item age during daily stand-ups. For example, some teams add an aging marker on cards in their Jira or Kanban board to highlight items that have been in progress longer than a few days. How to deal with the Story Points discussion Many Scrum teams are used to estimating in story points (with tools like planning poker or Fibonacci sequences) and using velocity for planning. A common question is how flow metrics relate to or replace these practices. The experience shared by our experts is that you don’t need to estimate in points to have useful predictions, in fact, your real historical data is usually more accurate than a guess. That said, do not  abandon the valuable discussions that happen during refinement and planning. The goal is to shift those conversations toward understanding the work and risks, rather than debating estimates. Rita went into some detail about this - “ Absolutely do not drop conversations about risks and alignment and what needs to be done. But to sit there and spend time on ‘how long do you think this will take?’ – that’s where we dropped it .”  In her team, they stopped arbitrary story point estimates, but they still collaboratively discuss each upcoming story to make sure they understand it and that it’s small enough. Once the team is clear on the what and why of a story, they start the work. How long it actually takes (the cycle time) is then fed back into their metrics. Over time, teams often find that story point estimates don’t add much value beyond what their throughput  and cycle time  data already tell them. Colleen recommends doing refinement as close as possible to when the work will start, to incorporate the latest information. Planning far in advance with estimates that might change can be wasteful. Instead, teams can forecast using flow metrics: for example, using throughput to project how many stories they can likely complete in the next iteration, or using historical cycle time percentiles to answer “ when might this single item be done ?” (often via Service Level Expectations, like “ 85% of our stories get done in ≤8 days ”). These forecasts are based on reality which is the actual variability of past performance, rather than the optimistic assumptions that often creep into estimates. Smaller Batches, Faster Flow Another aspect of improving flow is tackling the batch size of work. Intuitively, one small item will move through the system faster than a large batch of work. Colleen emphasizes this when addressing how to explain the benefit of moving one item faster versus a group of items: “One item is always going to be faster, obviously, than a group of items… The bigger [the batch], the slower it tends to move.”  Large projects or epics that comprise many pieces will inevitably take longer and face more complexity than a single, well-defined story. The takeaway: whenever possible, break work into smaller independent chunks. Each chunk (perhaps a user story) should ideally deliver some value on its own. By keeping batch size small, you can deliver pieces incrementally and get feedback sooner. If you have an 8–12 week epic, try to slice it into smaller features or stories that can be completed and released continuously, rather than waiting 3 months for a big bang. Smaller batches moving through the system quickly will improve overall throughput and help maintain that consistency we discussed above. Poll results from our live webinar Common Challenges and Misconceptions “Our data is messy or not good enough.” Many teams worry that their tracking data (e.g. in Jira) is incomplete or inconsistent, and thus hesitate to use it. In reality, your data is what it is  – and that’s okay. “The data you have is reflective of the system you have,”  Colleen notes, meaning it captures all the variability of your current process. That variability is precisely why forecasts often feel hard! Don’t wait for perfect data; instead, start using what you have to set a baseline. Include all those outliers and long cycle times in your analysis – they’re telling you something important about your process. Over time, as your team improves (maybe by slicing work smaller or reducing dependencies), your data will naturally get “cleaner” (more consistent). But even if you have a wide range of outcomes, techniques like Monte Carlo simulations can ingest that and give a probability-based forecast. In short, “If you have data, it’s good data.”  Use it to start the conversation and drive change. “Won’t management use these metrics against us?” Perhaps the biggest fear is that making all this data transparent will turn into a surveillance mechanism or a blame game. This concern is real – it’s crucial to establish psychological safety and an improvement-oriented culture when introducing flow metrics. Colleen emphasizes that metrics should be a tool for the team first and foremost, not a stick for leaders to poke at individuals. The goal of visualizing flow metrics is to help the team make better decisions in real time (like swarming aging work or adjusting WIP), and to experiment with changes for improvement. It’s not to compare Team A vs Team B, or Developer X vs Developer Y. Make sure leadership understands this too. Ideally, managers should look at metrics like cycle time and throughput as indicators of process health, not employee effort. If a number is outside the expected range, the question to ask is “ What’s affecting our workflow here? ” rather than “ Who is to blame? ” Want to Learn More? If you're ready to keep going, check out: E-Book - Getting started with flow metrics ProKanban.org Training & Certifications The Kanban Pocket Guide (a free resource worth bookmarking)

Work Item Age is the elapsed time since the work item started. Work Item Age is one of four key flow metrics along with Cycle Time , Throughput , and WIP (aka work in progress ). Work Item Age is, arguably, the most important flow metric because controlling age can result in significantly higher levels of predictability. In short, if you can only measure and manage one thing, make it Work Item Age. In simpler terms, Work Item Age is the elapsed time an open ticket has been waiting or working since it began. Every active item has an age, which grows day by day until the item is finished. Once the work is done, that item’s age stops accumulating (and essentially becomes its Cycle Time). How do you calculate Work Item Age? To begin calculating Work Item Age, you need to have a defined process with two specific points identified: Your Start Line – or the point in your process in which items are considered started Your Finish Line – or the point in your process in which items are considered complete When you have those points defined, you can identify your WIP as they will be the work items between those two points. Identifying WIP in your process You measure the age of each work item in your WIP using the following calculation: (Now – Start TU) + 1 TU stands for Time Unit. You can use any granularity you'd like: seconds, minutes, hours, days or more. Why do we add 1? The “+1” ensures that if something started this morning and it’s still in progress now, we count today as one day of age. Every new day an item remains unfinished, its age increases by 1. Importantly, Work Item Age includes all the waiting time, just like Cycle Time does. It doesn’t matter if a task has been sitting idle over the weekend or blocked by a dependency – that time still counts in its age. Work Item Age is the total elapsed time since the work item started If a story was started 5 days ago, its age is 5 days (assuming we measure in calendar days and add the inclusive day count). We calculate it similarly to Cycle Time, using today as the “end” since the work isn’t finished yet. For example, if a task moved to “In Progress” on October 1 and today is October 10, its Work Item Age would be (Oct 10 – Oct 1) + 1 = 10 days. Why Work Item Age Matters Work Item Age is arguably the most important flow metric for teams focused on improving their delivery . Why? Because it deals with the here and now  – it highlights work that is currently in progress and potentially at risk of taking too long. Cycle Time and Throughput are lagging indicators (they look at completed work), but Work Item Age is a leading indicator . It gives you an early warning when something is languishing. Age is by far the most crucial metric to track, since controlling age can dramatically improve your predictability. If you manage only one thing, manage the age of your work items. Aging Work In Progress Chart from ActionableAgile Analytics. Used for visualizing  Work Item Age. Each dot represents a work item in progress. Consequences of Aging Work Think of Work Item Age as a “staleness” gauge. The longer a task lingers unfinished, generally the harder it becomes to finish. Team members lose context, assumptions go stale, and inertia sets in. By tracking age, you can prevent tasks from quietly rotting on your board. It brings visibility to items that might otherwise be forgotten until it’s too late. Studies have shown that keeping Work Item Age low tends to result in lower overall Cycle Times and more reliable delivery forecasts. In other words, managing aging work directly improves your team’s speed and predictability. You’ll finish work faster and with fewer surprises at the end. There’s also a psychological aspect: a ticket that has been “In Progress” for 15 days when most finish in 5 is a big red flag. It prompts the team to ask, “Why is this taking so long? What’s blocking it?”  Those conversations are exactly what you need to unblock issues or decide if you should pull the plug or get help. Watch this quick expert take on Work Item Age. Getting Started Work Item Age is important to track for any team who wants to become more predictable. At its core, Work Item Age is a process improvement metric. When you see items aging more than expected, you can experiment with tactics to see if they help. There is no single fix but common tactics include limiting WIP, controlling work item size, reducing dependencies, and more. Tracking Work Item Age helps you spot stalled or slow-moving work before it becomes a problem. Use it during these key events to keep your flow healthy and your delivery on track: During daily scrums / stand-ups to highlight items that are aging or stalled - transition to ask “what’s not moving?” instead of just “what are you working on?” In retrospectives, review items that aged unusually long and why During SAFe team syncs or ART syncs to flag aging work at risk of breaching SLAs or SLEs When preparing for release readiness to identify aging features or stories still incomplete In incident response workflows, to monitor if critical bug fixes or support tickets are aging During risk reviews or dependency checks in cross-team planning Whenever an item sits in one status longer than your team’s typical Cycle Time Once you manage Work Item Age, your Cycle Time data should stabilize and make forecasting easier! Ready to get started with flow metrics? This guide walks you through what to measure, how to get your team aligned, and how to build a case for change that your stakeholders will actually care about. It’s time to shift from intuition-driven to insight-driven delivery. If you’re looking for a tool to help you track your flow metrics and improve your process, try out ActionableAgile for free. Don’t forget to reach out if you’re interested in joining our customer success program!

Throughput is the count of work items your team completes per unit of time. In other words, it measures how much work gets done over a period. You might have a Throughput of 2 per day, 10 per week, or even 17 per sprint. Whatever your preferred time unit, this flow metric helps you understand how quickly you finish work . It’s a simple metric, but very powerful for understanding your team’s delivery capacity and for planning. Throughput is one of the four essential Kanban flow metrics (with Cycle Time , WIP, and Work Item Age) and gives insight into how quickly value is flowing out of your process How do you calculate Throughput? Calculating Throughput is straightforward. There are two things you need to decide on: The time unit  – e.g. per week, per month, per iteration. Choose a timeframe that makes sense for your context. Teams often use weekly or biweekly Throughput, especially if they’re doing Scrum (per sprint) or just want a steady pulse measure. The finish line  – define what counts as “completed” (usually items that reach the “Done” column or have a status like Resolved/Closed). In the image below, work is considered started when it enters the In Progress  column on the board. It is considered finished when it enters the Done  column on the board. This team has defined the Done column as their finish line. So, any items that move into the Done column are counted as Throughput. Why should I care about Throughput? Looking at your Throughput allows us to analyze how consistently you deliver value. Consistency of throughput, and how it compares to the rate at which you start work, is one indicator of how stable your process is. Perhaps the most common use for the Throughput metric is providing forecasts for completing multiple work items. You can use Cycle Time to forecast for single items, but you need a rate metric like Throughput to provide forecasts for groups of work items. Throughput Run Chart chart from ActionableAgile Analytics within Jira How do you use Throughput to forecast? Traditionally, people use their Throughput to determine the average rate at which work is finished and then divide the total work by that average. However, forecasting based on averages will produce average results. Obviously, we don't suggest you do that. Fortunately, you can use a Monte Carlo simulation that can use your Throughput data to simulate probable outcomes based on the variation found there. It’s a much more accurate, not to mention risk-aware, way to deliver forecasts. Read more about Monte Carlo simulations and forecasting. Getting started Teams often start looking at Throughput around the same time they begin looking at Cycle Time , WIP , and WIP Age . Focusing on building stability in these key flow metrics is a good start. The more stable your basic metrics are, the fewer outliers your forecasts have to account for and the more your forecasts are perceived as acceptable and, most importantly, accurate. Watch this quick expert take on Throughput Ready to get started with flow metrics? This guide walks you through what to measure, how to get your team aligned, and how to build a case for change that your stakeholders will actually care about. It’s time to shift from intuition-driven to insight-driven delivery. Interested in tracking flow metrics like this one? Try out ActionableAgile for free and reach out if you’re interested in joining our customer success program!

Does your team have a lot of tasks going on at the same time?   WIP is an acronym for work in progress.  So, the WIP flow metric measures the total number of work items that have been started – but not yet finished – at any given point in time. WIP is one of four key flow metrics, along with Cycle Time , Throughput , and Work Item Age . In practical terms, it’s how many cards are “in progress” on your board right now. If you’ve pulled five user stories into development and none are done yet, your current WIP is 5. These flow metrics are interconnected – meaning, when one of these flow metrics changes significantly, you’ll see an impact on one or more of the others. Most of us have experienced this reality: the more you have in progress, the longer it takes to get each thing done. It makes sense. If we put all of our effort into one thing, that one thing will be finished faster than it would if we spread our time across multiple items. For more on this relationship, read about Little’s Law . The amazing news is that this makes WIP a leading indicator of future Cycle Time, and it means that controlling your WIP can be a tool in your journey to help you deliver quickly and predictably. Watch this quick expert take on Work in Progress (WIP) How do you calculate WIP? To begin calculating WIP, you need to have a defined process with two specific points identified: Your Start Line – or the point in your process in which items are considered started Your Finish Line – or the point in your process in which items are considered complete In the image below, work is considered started when it enters the In Progress column on the board. It is considered finished when it enters the Done column on the board. A defined process with clear start and finish points When you have those points defined, WIP is calculated as a simple count of work items between those two points. In the example above, we show a current WIP level of five (5). A count of cards between the two points tells us that current WIP is 5 Why should I care about WIP? People can only do one ACTIVE thing at a time. You might be able to listen to music while working or something like that but you can't actually type or say two different things at one time. We are like single processors that way. So, when we have more things "in progress" at one time, we are switching back and forth between them. This makes each one take a bit longer to do than if you focused on just one thing at a time, not starting another until the first is finished. While you may not be able to have only one thing in progress, you should understand the impact of higher WIP - in other words more task switching. Take a look at one of our past blog posts to see about a study we did with my team at the time regarding the unspoken cost of high WIP levels: Can you afford not to limit work in progress? Higher WIP = Higher Delivery Costs When too much work is in progress, each item takes longer to finish. Teams spend more time (and salary) per feature delivered. A recent BCG study   found over a third of software projects were delayed, and every delay postpones ROI. High WIP means you’re paying for people and resources longer before you get any value back. Slow Delivery = Lost Opportunity Piling up WIP slows your time to market. Customers get value late, which defers revenue and can miss market windows. This AWS blog  shares a great example on how a multitasking team delivered a mobile app 10 weeks later than necessary – missing a peak shopping season and delaying partner onboarding. Pushing too many things at once also increases the cost of delay. This is the economic cost of delivering value later rather than sooner. In short, the more items in progress, the longer customers wait (and the longer your company waits to earn back its investment). Getting started Teams often start looking at WIP around the same time they begin looking at Cycle Time , Throughput , and WIP Age . Looking at the impact of your WIP on the other key flow metrics will provide insight into the WIP limits you might want to experiment with for your process. As your experiment goes on, see what impact the WIP limit change had on your Cycle Time and Throughput. Repeat this process until you get a result that you’re pleased with! When using WIP in everyday work some examples can be seen below. Before starting a new sprint or pulling in more work to avoid overloading the team. In daily stand-ups if the team has many tasks in progress at once (flag high WIP). When throughput drops or cycle time climbs – signs that WIP might be too high. During retrospectives to see if too much work-in-progress caused delays. When an urgent item arrives, to decide if something else should pause before adding it. WIP Run Chart from ActionableAgile Analytics within Jira Ready to get started with flow metrics? This guide walks you through what to measure, how to get your team aligned, and how to build a case for change that your stakeholders will actually care about. It’s time to shift from intuition-driven to insight-driven delivery. Interested in tracking flow metrics like this one? Try out ActionableAgile for free and reach out if you’re interested in joining our customer success program!

Do you know how long it actually takes for your team to finish a task from start to finish?  Cycle Time measures the total elapsed time from when a work item begins to when it completes. This means that, depending on how you define start and finish for your context, you can measure the Cycle Time for a whole process or just a portion of it. How to Calculate Cycle Time Calculating Cycle Time is straightforward. First, define what “Start” and “Finish” mean for your process. For example, work might start when a ticket moves into an “In Progress” column and finish when it reaches “Done.” Once those points are clear, you can compute Cycle Time with a simple formula: Cycle Time = (Finsh Date - Start Date) +1 You might be asking, " But why do you add + 1? " - Fair enough. The +1 accounts for work that starts and finishes within the Cycle Time so no time is left out. For instance, if a task started on January 1 and finished on January 5, its Cycle Time would be 5 days (inclusive). We add that extra day so that an item started and finished the same day isn’t recorded as 0 days . You never have a zero-length Cycle Time; even a task completed within hours counts as a 1-day Cycle Time Remember, Cycle Time doesn’t stop when work pauses. If a task gets blocked or sits idle over a weekend, that idle time still counts in the Cycle Time. This makes conversations with stakeholders simpler, as calendar days are relatable to both internal and external audiences. Why Cycle Time Matters Cycle Time is one of the four basic flow metrics, along with Throughput , WIP , and Work Item Age . These four flow metrics are baselines metrics that give you some insight into the underlying flow health of a process. Cycle Time is a critical flow metric for understanding and improving your delivery speed. It directly answers the question: “How long does it take us to complete a work item?”  This is hugely important when stakeholders ask, “When will it be done?”   Tracking Cycle Time allows you to answer with data rather than guesse s. Lower (and consistent) Cycle Times mean you’re delivering value faster and more predictably to your customers. Measuring Your Predictability Looking at Cycle Times helps us understand how predictably we deliver individual work items. If your process generates a wider range of Cycle Time data now than it did in the past then, objectively, you could say that your process has become less predictable than it used to be. By looking at how long it took you to finish a given percentage of items historically, you can get an idea of how long it may take you to deliver an item in the future - assuming your process hasn't significantly changed. This is best seen on a Cycle Time Scatterplot. Each dot represents the Cycle Time of a given work item. Cycle Time Scatterplot chart from ActionableAgile Analytics within Jira Using Cycle Time for Forecasting One powerful use of Cycle Time data is forecasting single work items. Instead of relying on gut feel or arbitrary story point estimates, you can look at your past Cycle Times to predict how long similar work might take. A common technique is to determine a percentile from your historical data. For example, by looking at the above Cycle Time Scatterplot we can easy see that 95% of the completed stories had a Cycle Time of 23 days or less. You can then communicate something like, “ Based on our data, there’s a 95% chance we’ll finish an item like this within 23 days. ” This probabilistic forecast sets realistic expectations using evidence from your actual performance. Be careful not to just take a simple average of past Cycle Times, averages can be misleading if you ha ve outliers. One huge delay can skew an average upward, and it doesn’t reflect the variability or risk. It’s better to use percentile ranges (as mentioned above) or to employ simulation methods. Some teams use Monte Carlo simulations on their Cycle Time data to forecast completion dates. Monte Carlo simulation leverages the distribution of your Cycle Times to run many “what if” scenarios, providing a more reliable and risk-aware forecast than a single average. A great metric to start with Cycle Time is often the first flow metric that teams attempt and it is very easy to track — even by hand! All you need is to write down the start date and the end date of a work item and you can calculate cycle time. You can even make your own charts! Ready to get started with flow metrics? This guide walks you through what to measure, how to get your team aligned, and how to build a case for change that your stakeholders will actually care about. It’s time to shift from intuition-driven to insight-driven delivery.

Agile and DevOps teams rely on data to make decisions. Yet if you’re a Jira user, you’ve probably felt some pain points with Jira’s built-in reports. The charts and gadgets Jira provides are okay  for basic tracking, but are they enough to truly improve your team’s flow and predictability? Maybe not. That’s where ActionableAgile® Analytics comes in – it’s designed to give you deeper, actionable insights right inside Jira. In this post, we’ll compare Jira’s native reporting  features with ActionableAgile Analytics  side by side. We’ll see how each handles common needs like Cycle Time analysis, work-in-progress tracking, forecasting, and more.  The goal is to understand which tool actually helps you solve the problems slowing your team down, instead of just reporting them. Let’s dive in. The Basics: Jira Reports vs. ActionableAgile® Analytics Jira’s Built-In Reports:   Jira comes with a variety of out-of-the-box reports and dashboard gadgets (e.g. Control Chart, Cumulative Flow Diagram, Burndown Chart, etc.). These are convenient because they’re right there in Jira, showing live data with minimal setup.  If you need a quick view of sprint progress or how many issues were resolved vs. created, Jira’s default reports can do that. They’re also straightforward, you don’t need to be a data expert to use them. However, teams often hit limitations with Jira’s built-in reporting. The insights can be superficial . You might get an average Cycle Time, but you won’t know the spread or if you have outliers causing delays. There’s little customization  – you can’t add new types of charts or easily change what’s shown.  Cross-project reporting is limited too; most Jira gadgets focus on one project or board at a time. The bottom line is Jira’s native reports give you basic awareness, but often leave you with more questions than answers about your process. ActionableAgile® Analytics:   An Atlassian Marketplace app that lives inside Jira and was built specifically to analyze flow metrics  and improve predictability. It’s like giving Jira a supercharged analytics brain. With ActionableAgile Analytics, you get a suite of advanced charts Cycle Time Scatterplots, Aging Work-in-Progress charts, Histograms, Throughput trends, and more. These aren’t just for show; they let you see the reality of your workflow, including variation and outliers, which Jira’s reports often mask. ActionableAgile Analytics emphasizes statistical context .  For example, it can overlay percentile lines on your Cycle Time chart, so instead of just saying “average Cycle Time is 5 days,” you can see “85% of our items get done in 8 days or less.” That kind of insight helps you set realistic expectations (like SLA targets) and manage risks. Another big plus: ActionableAgile Analytics has built-in forecasting (Monte Carlo simulations) . You can literally forecast project completion dates or how many tasks you’ll get done by a certain date with a click – all based on your historical data.  Finally, ActionableAgile Analytics integrates smoothly, meaning you don’t have to export Jira data to use it. It pulls from Jira in real-time and updates the charts as your Jira issues update. The chart and the configuration you're looking at can also be saved and shared with colleagues to help everyone being on the same page (while respecting viewing permissions). It basically turns Jira from a tracking tool into a learning tool for your organization. Instead of just seeing what happened, you start to understand why  things happen and how to improve. Feature-by-Feature Comparison To make this concrete, let’s compare Jira vs. ActionableAgile Analytics on a few key reporting features that agile teams often care about: 1. Cycle Time Analysis (How long does work take?) Jira’s Control Chart:  Jira offers a Control Chart to visualize Cycle Time (the time it takes to complete an issue). It shows each completed issue as a dot and an average line. It’s useful for seeing overall trends. But it is quite limited for those seeking more.  The chart uses the average, which can be skewed by one or two really slow items. If one issue took 60 days but most take 5 days, that lone outlier will drag the average way up and paint an overly grim picture. Jira’s chart doesn’t easily let you filter those out or show percentile lines.  In short, Jira’s Control Chart gives you a hint at your Cycle Times but not the full story. You might still wonder, are we generally consistent or do we have a few huge outliers?  Jira won’t answer that well. Jira's out of the box Control Chart ActionableAgile Analytics’s Cycle Time Scatterplot:  The ActionableAgile Analytics scatterplot looks similar at first (dots over time), but it packs a lot more insight. It plots each item’s Cycle Time and can display percentile lines (50th, 85th, 95th percentiles, etc.). So instead of just one average, you can see, for example, “half our tasks finish in under 4 days, 85% finish in under 8 days, but a few went way up to 20+ days.” This immediately tells you about variability and risk.  If you have a big gap between your 85th and 95th percentile lines, that means occasional items take much longer – maybe those are special cases worth investigating.  ActionableAgile Analytics also lets you filter by issue type or tag. Want to see Cycle Time just for user stories vs. bugs? Click a filter and you can. You can even toggle which phases of your workflow to measure (maybe you only care about coding+review time, excluding backlog wait).  All of that is point-and-click in ActionableAgile Analytics. The result is you truly understand your delivery times. Teams can then have conversations like, “ Hey, 85% of our work gets done in under 8 days – that’s pretty good, but what’s up with these few that took 20+ days? Are they exceptions or a pattern we need to address? ”. Jira’s control chart alone rarely sparks that level of discussion because it doesn’t make the patterns obvious. 2. Managing Work in Progress (WIP) and Aging Work Jira (no native aging chart):  Jira doesn’t have a report to show how long each in-progress item has been open. You might use a dashboard filter to list issues “in progress > 10 days” or similar, but there’s no visual aging work-in-progress chart built into Jira Software.  This is a gap, especially for Kanban or flow-based teams. It means teams often miss early warnings that something is stagnating. Let’s say a ticket has been in the “Doing” column for 15 days, if your Cycle Time is usually 5 days, that’s a red flag. Jira itself won’t flash a warning; someone has to notice it manually. ActionableAgile Analytics’s Aging WIP Chart:  ActionableAgile provides an Aging Work in Progress  chart that looks like a Kanban board view. Each column of the chart is one of your workflow states, and the tickets currently in that state appear as dots or bars. The catch?  The higher up the dot, the older that item is (how many days it’s been active). This is super intuitive – at a glance, you see which work items are “aging” and might need attention. If a dot is creeping near the top of a column (say approaching your 85th percentile line for Cycle Time), it’s a visual signal that this item might blow past your usual timeline if you don’t do something. It basically answers the question “ What’s about to become a problem? ” every single day. Teams using this chart often make it part of daily stand-ups: “ Let’s check the aging WIP – oh, task XYZ has been in review for 9 days, which is unusually long for us. Should we escalate that? ”. Without ActionableAgile Analytics, you might not see that until day 20 when someone finally asks “ Whatever happened to XYZ? ” In fast-moving environments and even more in regulated ones where delays can mean missed compliance dates, catching aging work quickly is crucial. ActionableAgile Analytics gives you that visibility; Jira doesn’t out-of-the-box. 3. Forecasting and answering “When will it be done?” Jira’s approach:  Jira Software doesn’t provide a built-in way to forecast how long a set of issues will take to complete. Velocity and Throughput averages make a big assumption: that your team’s pace and variability will stay the same in the future as it was in the past. But that’s rarely true. Scrum teams often use Velocity charts or Sprint Burn-downs to guess at completion (e.g., “ we do ~50 story points a sprint, so maybe 3 sprints to finish ”). This does not account for: Changing team size Scope creep or scope reduction Story point inflation Blockers or unplanned work Kanban teams might try to use Control Charts or Throughput averages to project forward. These averages offer a single-point prediction with no understanding of variance or confidence. In the real world, variance matters more than the average. Throughput-based averages (e.g., “ we complete ~5 items/week ”) ignore: Fluctuations in ticket size/complexity Seasonality (e.g., holidays, big releases) External dependencies Many teams are forced to export data to Excel or use add-ons from the marketplace if they want probabilistic forecasts. Jira's Build in Velocity Report - Designed to help you estimate the work you will do in future sprints ActionableAgile Analytics’s Monte Carlo Forecasting:  ActionableAgile has forecasting baked in. You can choose between two modes: “ When will all these issues be done? ” or “ How many issues can we complete by date X? ”. It then runs a Monte Carlo simulation (literally thousands of randomized trials based on your historical Throughput or Cycle Time data). The output is a range of outcomes with probabilities. For example, ActionableAgile Analytics might tell you “50% chance to finish by May 15, 85% chance by May 22, 95% by June 1” for a given backlog. This is golden information for planning – it lets you communicate to stakeholders in terms of risk: “We’re pretty confident we’ll be done by the end of May, but there’s a small chance it could slip into early June.”   With Jira alone, teams often would either give a single date (which is usually wrong) or pad a lot “to be safe.” ActionableAgile Analytics’s forecast is data-driven and updates as your pace changes. It’s also great for answering scope questions: “ If we cut scope by 5 stories, what’s the impact? ” or “ If we pull in these 2 extra tasks, how might it affect the timeline? ” You can simulate those scenarios quickly. Real Screenshot of how BNP Paribas Bank uses Monte Carlo for forecasting to leadership during strategic events. This image shows how the team asses release plans based on Monte Carlo Simulations. Read their full story here In a sense, ActionableAgile Analytics brings an analytics-driven negotiating tool  to product and project management. You can say, “ Sure, we can add that extra feature, but our 85% confident date then moves out a week – is that trade-off worth it? ” This level of clarity just isn’t available in Jira’s standard toolkit. And because ActionableAgile Analytics keeps this inside Jira, you don’t have to manually update spreadsheets for every change, It’s always using the latest data from your actual workflow. Summing things up When your data’s off, so is your direction. And eventually, your customers and stakeholders will be the ones to suffer. Here are the big reasons why teams choose ActionableAgile Analytics over sticking with Jira’s native dashboards: Find Bottlenecks and Outliers Easily:  ActionableAgile Analytics highlights where your process is hurting. Jira might tell you the average, but ActionableAgile Analytics will show you “these 5 tasks took 3x longer than the rest – and they all happened in the Design phase, maybe that’s a bottleneck.” It brings the exceptions to the forefront so you can do something about them. With Jira alone, you often only catch these in hindsight (or not at all). Data-Driven Forecasting:  If you need predictability (who doesn’t?), ActionableAgile Analytics’s Monte Carlo simulations are a game changer. You stop making wild guesses about timelines. Instead, you get probabilities that help set realistic expectations. Teams that use it often find that stakeholders trust them more because they’re transparent about uncertainty (“ We’re 90% confident in this range ”) rather than overconfident in a single date that slips. It’s a more professional way to forecast work, and it’s automated – so you can run a new forecast anytime as things change. This is especially important for project managers or product owners who have to report upwards; you can defend your projections with data. Improve Team Conversations:  This might sound soft, but one of the coolest things about having richer metrics is how it changes the team’s behavior. Instead of opinions like “ I feel like we’re always stuck waiting on QA ” you can look at a chart and say “ Actually, our QA stage has 3 days of wait on average, which is 30% of our Cycle Time – that is significant, let’s fix it. ” It focuses discussions on facts. "A big takeaway is being able to support meaningful conversation with our business partners [Stakeholders], that align to the value stream(s). Having an elevated level of trust in the data of how we operate to support outcomes is a must have." Comprehensive Solution in One Tool:  With ActionableAgile Analytics, you don’t need five different add-ons or exports. It covers Cycle Times, Throughput, WIP limits, Work Item Age, flow efficiency, and forecasting all together. Some teams try to patch together multiple tools: Jira for basic charts, plus Excel for deeper analysis, plus maybe a custom script or two. That’s a lot of maintenance and the context-switching can be painful. ActionableAgile Analytics consolidates a lot of that. And because it’s designed to work with Jira data structure, it’s less fiddly than a generic BI tool. You don’t have to be a data scientist to use it – it was made for practitioners (product managers, Scrum Masters, team leads) who just want answers from Jira without hours of wrangling. In terms of cost-benefit, many consider it worth it because reclaiming the time spent on manual reporting and avoiding project delays pays for itself. Thinking of leveling up your agile metrics in Jira?  Consider giving ActionableAgile® Analytics a try. Many teams, from startups to large enterprises, have made that jump and never looked back. You can start by exploring some resources on the 55 Degrees blog or checking out customer stories . When you’re ready, start a free trial and begin your journey to better data.

We’ve got big news! Personal Views for Data Sets  is now available in beta for ActionableAgile® Analytics for Jira Cloud! 🎉 This new capability is designed to make your data exploration faster, smarter, and more collaborative than ever before. Why Personal Views Matter If you’ve ever found yourself reapplying the same filters and chart settings every time you analyze a dataset, this update is for you. With Personal views, you can now: ✅ Save your favorite chart configurations and filter settings as named views ✅ Quickly switch between different views to explore data from multiple angles ✅ Share views across teams This means less time setting things up and more time understanding your flow, uncovering bottlenecks, and improving delivery, all with greater consistency and collaboration. A More Streamlined Analysis Experience Whether you're collaborating across teams or diving into team metrics, personal views help you skip the repetitive setup and focus on what matters: the insights. By giving you the ability to define reusable, named perspectives, this feature empowers teams to standardize reporting and make discussions around data more aligned and actionable. Rolling Out in Phases We’re releasing Shared Views in stages to make sure the experience is smooth and scalable: 🔹 Phase 1 (Available Now):   Data Set Admins  can create and share views across teams 🔒 (Coming Soon):   Private Views  will allow every user to save and manage their own personal configurations for deeper customization. 🔒 (Coming Soon):  Display your saved views and Data Sets directly on your Jira Dashboards, giving teams instant visibility into the latest, most relevant insights. (Coming Soon) This phased rollout ensures that teams can start aligning right away while giving individuals the power to tailor their own workflows soon after. Try It Out and Tell Us What You Think Personal views is available now, and we can’t wait for you to try it! Jump into ActionableAgile® Analytics for Jira Cloud, save your favorite chart setups, and make your Jira Dashboards more insightful than ever. Have questions? Visit our Support Page Ready to dive deeper? Check out the documentation here Want to chat about the feature or hear how others are using it? Join us in our Community As always, we’d love to hear how you’re using personal views and what you think!

Still guessing when work will be done?   You’re not alone—and you’re not without help. Figuring out where to start with flow metrics can feel overwhelming, especially when you’re buried in Jira dashboards or worse...... spreadsheets. That’s exactly why alongside our partner ProKanban.Org we created An Introduction to Flow Metrics —a no-fluff, practical guide designed to help you stop estimating and start predicting. What You'll Learn The 4 core flow metrics that matter most How to build team buy-in (without buzzwords) Ways to turn metrics into business value your execs will love How to overcome common challenges from your team "We knew that if we wanted to build predictability, we had to take care of flow metrics." BNP Paribas Bank Polska Ready to get started with flow metrics? This guide walks you through what to measure, how to get your team aligned, and how to build a case for change that your stakeholders will actually care about. It’s time to shift from intuition-driven to insight-driven delivery.

Source: Camms License: CC By 4.0 At 55 Degrees, we work with financial institutions across Europe and beyond, providing non-critical ICT services that support collaboration, forecasting, and agile decision-making. While we are not a financial entity ourselves, and therefore not directly regulated under the EU's Digital Operational Resilience Act (DORA), we recognize the increasing responsibilities our customers face when managing digital risks — especially when relying on third-party providers like us. What is DORA? The Digital Operational Resilience Act (DORA)  is a European Union regulation designed to strengthen the financial sector’s ability to withstand and recover from ICT-related disruptions. It applies to a wide range of regulated entities — including banks, insurers, asset managers, and fintechs — and requires them to assess, manage, and monitor the ICT risks posed by their vendors. This includes ensuring that third-party service providers meet high standards for cybersecurity, incident handling, business continuity, and operational resilience. Even if a vendor isn’t classified as “critical,” regulated firms must demonstrate appropriate oversight and assurance — and that’s where we come in. The 5 Pillars of DORA Strategic Commitment to DORA Compliance To further differentiate ourselves in the data security space and demonstrate our long-term commitment to our financial-sector customers, we are actively working toward full alignment with DORA as a third-party ICT service provider. While we are not currently classified as a “critical ICT provider,” our goal is to meet or exceed the standards expected of one. We believe this commitment reflects both our values and our customers' expectations for transparency, resilience, and regulatory awareness. Optional DORA Addendum for Customers To make things easier for customers navigating DORA compliance, we offer an optional DORA-focused addendum to our standard customer agreement. This document outlines additional commitments that reflect the regulation’s expectations for third-party providers, including: Incident reporting protocols Testing and continuity support Subcontractor transparency Risk oversight collaboration The addendum is available on request and can be executed during procurement, onboarding, or renewal. DORA Alignment in Practice Here are just some of the practices we’ve adopted to help customers meet their DORA-related obligations: We maintain compliance with SOC 2 Type II, ISO/IEC 27001, and GDPR frameworks. Our leadership team receives regular cybersecurity training and is engaged in risk oversight. We use Vanta  and InfosecIQ  to deliver continuous security education to our team. We maintain documented and tested incident response and business continuity plans. We support customer-led audits, risk assessments, and data security reviews. We can align to DORA-like incident reporting expectations under customer-specific terms. We are actively assessing our internal practices against the DORA framework and plan to implement enhancements that strengthen governance, risk management, testing, and monitoring. Commitment to Operational Resilience Ultimately, our DORA alignment is part of a larger vision: to offer trustworthy and resilient product services that evolve alongside our customers’ regulatory landscapes. By tracking new developments like DORA — and proactively aligning with its principles — we help ensure that our products, policies, and people support your operational resilience. Confidence in tools starts with confidence in vendors. If you're evaluating tools for DORA-aligned teams, we’re ready to support your journey. 👉 Talk to us  about how we help regulated organizations work smarter.

At 55 Degrees, we're always looking for ways to improve the security, performance, and experience of our products. That's why we're excited to announce that ActionableAgile Analytics for Jira Cloud  is moving from the Atlassian Connect framework to Atlassian Forge . This shift is more than just a technical update — it unlocks new opportunities for our customers and future-proofs the product for years to come. Stronger Security with Scoped, Temporary Access Security has always been a top priority for us. We maintain rigorous security standards, including ISO 27001  and SOC 2  certifications, and we are committed to transparency through our Trust Center . With Forge, ActionableAgile now uses short-lived, scoped OAuth 2.0 tokens  to access Jira data. Unlike Connect apps, which could maintain persistent access to your Jira environment, Forge limits access to only what’s needed  and only when it's needed . This tighter control significantly reduces risk and improves transparency around what the app can do with your data. Even though we continue to host some parts of the app externally (using Forge Remote), all Jira data access remains strictly secured through Atlassian's infrastructure. We take your trust seriously and are continually challenging ourselves to meet and exceed security expectations. We would not be moving ActionableAgile to Forge unless we were confident that the platform is fully ready to meet our high standards. Future-Proofing with Atlassian's Newest Capabilities Atlassian has made it clear that Forge is the future  of app development in their ecosystem. By moving to Forge, ActionableAgile gains access to new APIs, events, and extensibility options  that aren't available to Connect apps. This allows us to deliver deeper, more seamless integrations and ensures that as Atlassian evolves, ActionableAgile will stay right at the cutting edge. It also means faster adoption of platform innovations, so you can take advantage of new features as soon as they become available. Unlocking Exciting New Features Moving to Forge opens the door to a range of new functionality. We're already working on features like native Jira dashboard gadgets  and Confluence macros , making it easier than ever to bring your analytics into the spaces where your teams collaborate every day. With Forge's event-driven architecture, we can also build smarter, more responsive features that proactively support your workflows. Upgrading to Forge isn't just a behind-the-scenes change — it's an investment in providing you with stronger security, richer functionality, and a better overall experience . We're committed to ensuring that ActionableAgile continues to be the best analytics tool for Jira users, today and into the future. We’re excited about what’s ahead — and we can’t wait for you to experience it with us! Don't Miss Out—Upgrade Today! If you're an existing customer, we really encourage you to upgrade to the latest Forge-based version of ActionableAgile Analytics for Jira Cloud today  to start benefiting from improved security, deeper integrations, and upcoming new features. Check your add-on manager to upgrade - it's a simple as button click.

May 2025  – 55 Degrees , a leader in flow analytics and agile solutions, is proud to announce a new strategic partnership with ProKanban.org , the global community dedicated to practical Kanban education and accreditation.  This collaboration is designed to make agile education, expert guidance, and practical tools more accessible for teams, partners, and organizations worldwide. Bringing Greater Education and Community Impact Through this partnership, we’ll be rolling out: A series of live and on-demand webinars. We're excited to get things started on Tuesday, June 10 with our “ Getting Started with Flow Metrics ” webinar. Registration information will be released soon. Downloadable playbooks and case studies, including real-life stories from teams who have implemented Kanban and flow analytics successfully. Guidance on finding the right certification or training path, helping teams and individuals navigate their learning journey with confidence. “We see firsthand just how much demand there is for education and organizational understanding around flow metrics from partners, customers, and teams who are starting to transition to this new way of working and trying to bring their organizations along with them. This partnership with ProKanban.org gives us a way to change that. Together, we’ll be making it easier for people to learn, get support from experts, and connect with others who have faced the same challenges. It’s about making the learning curve less steep and helping teams take the next step.” Brodie Chivers, Partnerships Manager, 55 Degrees “Too often tools overwhelm users instead of enabling them to take action. Our partnership with 55 Degrees is about changing that by giving teams the education and insights they need to make better decisions with their data. It’s a natural extension of our mission at ProKanban.org , to make practical, evidence-based improvement accessible for anyone who wants to deliver value with more confidence.”   Colleen Johnson, CEO, ProKanban.org Supporting ProKanban Trainers and Practitioners Both 55 Degrees and ProKanban.org share a commitment to practical, evidence-based improvement, and believe that learning should be open, inclusive, and supportive.  Through this partnership, ProKanban trainers will have access to additional support from 55 Degrees around licensing and course material—making it easier to demonstrate flow metrics and provide hands-on, real-world learning experiences. Looking ahead, we are committed to exploring new ways to support ProKanban trainers and practitioners as the community continues to grow. About 55 Degrees 55 Degrees helps organizations improve delivery performance with analytics and forecasting tools backed by flow metrics and probabilistic forecasting. Whether teams work in Atlassian, Microsoft Azure, or use our standalone solution, we help organizations improve how work flows, reduce delays, and deliver outcomes with greater confidence and predictability. About ProKanban.org ProKanban.org is a global community focused on helping teams deliver the right work at the right time. Through practical training, tools, and certification, we teach data-driven practices that improve flow, reduce waste, and increase delivery confidence. Our mission is to make work more efficient, predictable, and sustainable without adding complexity. Whether you're a developer, team lead, or executive, our resources are designed to support sustainable ways of working that adapt to change and deliver measurable results.