Search Results

At 55 Degrees, we think probabilistic forecasting is great. Heck, it is a key feature in our products ActionableAgile Analytics and Portfolio Forecaster. By basing your future outcomes on past outcomes, you can provide high accuracy with minimal effort. Assuming, of course, that current conditions are similar to your past conditions. Recently a customer had a great question stemming from his difficulties getting buy-in for using Monte Carlo simulations at his workplace. What happens if the forecasted likely outcomes from a Monte Carlo simulation fly in the face of the teams experience? How do you prove the model and get buy-in? Here’s our answer… One approach you might try is to talk up the pros of using a tool such as a Monte Carlo Simulation: Uses actual data from what you’ve accomplished before Can quickly run thousands of simulations to see how wide the range of possible outcomes really is Can give you a better understanding of which of those outcomes is really most likely Turns the focus away from whether or not a single outcome is right or wrong to determining how confident you need to be in any given forecast. That may make some headway. But, many hard-core proponents of effort estimates may need a bit more to decide that some simulation could be better at determining possible delivery dates than the experts themselves. What I try to remember is that what we’re really trying to achieve are better outcomes. Our success doesn’t (usually) live or die on which path people take to get the better outcomes. Add a pinch of science So, in this situation, why not let them take a more empirical approach and, potentially, prove it to themselves? Have people make a hypothesis of which they think will be better and why. Capture assumptions. Then, execute the experiment by utilizing both effort estimates and probabilistic forecasts. Finally, reflect and draw conclusions about which approach was better What do I mean by better? That’s a good question you should ask yourself when comparing a new option to your previous way of doing something. If either of the following conditions apply, I consider the new option to be “better:” More accurate (especially when no additional difficulty is added) Same accuracy but easier and/or less time-consuming A true scientist would tell you to repeat the experiment and see if the outcomes continually prove that conclusion. The worst case scenario is that a hypothesis proves to be wrong — yours or theirs. Either way, your forecasts win the contest because you’ve proven what is more accurate. Have you done this experiment? Share your outcomes in the comments below! Want to try out probabilistic forecasting? Try ActionableAgile Analytics for free whenever you’re ready.

Probabilistic forecasting via Monte Carlo Simulations are a key feature of two of our products, ActionableAgile Analytics and Portfolio Forecaster. These simulations can provide amazingly accurate forecasts with a couple of clicks of a button, but there are lots of considerations when it comes to the data you use to generate the forecasts. A customer recently asked us about one of these considerations and we thought it was worth sharing. How many sprints are required to get decent data for a Monte Carlo sim? Our tool warns you that your forecasts might be iffy if you have less than 10 data points (finished work items), regardless of the number of sprints you have. Daniel Vacanti, creator of ActionableAgile and well-known trainer and speaker on metrics, goes into a little more detail. He says “you can forecast once you have approximately 10 data points regardless of the number of sprints. However, the quality of the forecast you will get is rather dependent on how good of flow you have during the sprint. If all items finish on the last day, then you may need several sprints before you can make a good forecast. However, in that case your biggest problem isn’t the data, it is how you are running your process.” The underlying consideration The rule of thumb with Monte Carlo simulations is that the conditions that were present when you generated your past data are roughly similar to the conditions that will exist during the period you are attempting to forecast. The word “conditions” here can refer to many different factors: team capacity, the mix of work, amount of work-in-progress, etc. These will all impact your throughput and throughput is the data used to forecast via our Monte Carlo simulations. So, if you have 10 items and that 10 items roughly represents the mix of work you’ll be doing in the future, those 10 items may be sufficient. However, if you have more cyclical work items or other considerations, you might need a bigger data set that accounts for that variety. Improve forecasts by improving predictability The less predictable you are — meaning the bigger the variation in how long it takes you to deliver work and how many work items you deliver over time — the more data you might need to get a better forecast. If you aren’t happy with your forecasts, usually the answer lies in improving predictability by controlling the age of in progress items. The more you prevent unnecessary ageing, the better your predictability. Want to try out probabilistic forecasting? Try ActionableAgile Analytics for free whenever you’re ready.

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). You can group these metrics into two pairs. Every completed item counts towards Throughput and has a Cycle Time where as every item still in progress counts towards WIP and has a Work Item Age. 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. 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. When you have those points defined, you can identify your WIP. They are the work items between those two points. You measure the age of each work item 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? By adding one, this allows us to include both the start and the finish time unit in the Work Item's age so no time is left out. Work Item Age is the total elapsed time from start to today. This means it includes active working time as well any time that a work item is sitting there idle no matter the cause. So, whether work is waiting on someone, you’re blocked by a technical issue, or being interrupted by evenings and weekends, the time is included in an item’s 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. Once you manage Work Item Age, your Cycle Time data should stabilize and make forecasting easier! 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!

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. 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 in to 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. 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. 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). 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 my past blog posts to see about a study I did with my team at the time regarding the unspoken cost of high WIP levels: Can you afford not to limit work in progress? 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! 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!

Almost all teams occasionally move a card backwards on their Kanban boards for one reason or another. Moving cards backwards isn’t always a bad thing but, backwards movement can have unintended consequences when you’re calculating flow metrics. What happens to the data when cards move backwards? Many people assume that all tools measure the Cycle Time for a workflow stage by adding up all the cumulative time an item spent there. Tools like ActionableAgile that focus on metrics for flow optimization do not! How work moves through the process impacts how we capture Cycle Time for the process and any state within. So, what do we do? Well, the answer is best seen in the Source Data chart. It is the place where you can find all of the dates we’ve captured for an item’s travels through the workflow. ActionableAgile always starts by capturing the date when a work item first moves into a column (or a workflow status mapped to a workflow stage if you’re in Jira and not using a board.) In the image above, we can see that a work item with the ID of FLOW-10 began in To Do in November of 2018, was moved to In Progress in January of 2019, and moved through Release Ready into Deployed on the same day in July 2021. But, those captured dates can get removed when cards move backwards in that process. If FLOW-10 were to move backwards from Deployed into Release Ready for whatever reason, we remove the date stamp for Deployed. If the item were to move from Deployed through Release Ready all the way back to In Progress, we would remove the date stamp for both Deployed and Release Ready. Essentially, when you move a work item backwards, all of the time that it accumulated in the stage you’re moving it out of (and any stages that you’re moving it through) gets added to the time already spent in the destination workflow stage. So, in the image above, the data now shows that it has continuously been in In Progress since January 30, 2019. When it finally moves through those stages again, the date they revisit the stages will be captured in the Source Data chart. What does this mean for me and how I work? First, know that it is always ok to move a card backwards when it was a mistake to move it forward in the first place. Accidentally dragged the wrong work item to done? Just move it back to where it was accidentally moved from. Just make sure that you don’t move it back any farther or you’ll lose valuable data. For example, if you have a card that accidentally moved from In Progress to Deployed, move it back to In Progress. If you move that card all the way back to To Do then dates for all subsequent columns will be removed and it will look like it never left To Do. Once you understand how backwards movement affects your data, the inevitable question then becomes “Well, if I shouldn’t move cards backwards, what should I do instead?” The answer can be contextual but almost always lies in how you design and use your board. How you anticipate and plan for these activities as expected things rather than unexpected things can make a huge difference. We have a few key tips in a companion blog post on designing boards for flow. Take a look then contact us for any questions you might have!

We all want to design our Kanban boards to enable consistent, smooth flow of work all the way from start to finish. Unfortunately, that capability doesn’t come naturally and the way we often visualize our work processes can unknowingly cause dysfunction. In this post, we share some important things to consider (at least from our experience) when you want to design your board to enable great flow. Focus on the work, not the workers Do the column names of your board sound like the titles of the people in your team? Do you, or others in your team, often work in just one column of your board? If so, your board design might be built for resource efficiency instead of flow efficiency. Resource efficiency is making sure that every individual person (in this case) is always busy – often at the cost of completing work. Flow efficiency is a focus on making sure that the path is easy and clear for work moving through a workflow. A team that focuses on flow efficiency encourages collective ownership of work from start to finish. A team that focuses on resource efficiency tosses work over proverbial walls to the next column and moves onto something else without looking back (or forwards, in this case). A desire for flow efficiency doesn’t mean that everyone has to be assigned to everything all the time. Even when there is a primary assignee, a team is collectively responsible for getting work completed and team members may need to work on items in multiple columns at one time. These practices will put a priority on team performance over individual performance. Purposefully handling cyclical activities If your board is built with too much granularity, team members can be confused about what to do when they experience the cyclical portions of your process. Let’s tackle the most talked about scenario – testing! Let’s imagine the team has a column on their board called Executing followed by a Validating column. The team’s policy is that an item moves from Executing to Validating when it is ready for external review. The team recognizes that bugs will be found during validation from time to time. If the team doesn’t talk about how to handle the discovery of bugs when work is in the Validating column, they may think that the best course of action is to move it back to the Executing column (and repeat this process as many times as it takes.) Unfortunately, moving cards backwards causes us to lose visibility and data. (Read about the impact of backwards flow on data.) Instead, the team can take steps to better accommodate this expected cycle. One option is to keep all cards in Validating until all found bugs are fixed. If they want to separate the initial validation from subsequent fixes, they can create a new column to the right of Validating called Fixing. Now when bugs are found, cards move there until are all fixed. The good thing about both of these choices is that data is preserved. We can still measure the original time spent in Executing AND tell how long it takes to complete since it first entered Validating. Separate activity from wait In order to really focus on improving the flow of work through your system, you will want to visualize when work is actively being worked on versus when work is ready and waiting for attention. This allows you to see important things like: bottlenecks in different stages of the workflow as seen by large queues directly to the left unreasonable amounts of work sitting in active column, masking additional wait time whether or not you should focus on reducing wait or speeding up certain activities. As you might have realized from this post so far, column names matter! A good practice is to use verbs for columns representing active work. This way they are not confused as waiting columns. Even better, break down your active columns into Doing and Done sub-columns! Visually separating active work from waiting periods allows you to use the Flow Efficiency chart more effectively. Banish Blocked and On Hold columns Our final tip for this post is to say goodbye to Blocked or On Hold columns – or any other column with the same purpose. While these columns do help us see wait, they do not represent a stage of a lifecycle that happens in a predictable place. Rather, they are fleeting attributes of work residing in a particular stage of its lifecycle. We use columns to display the lifecycle stages of work. So, we need to use other visual queues to denote fleeting attributes like this. If you try to treat these attributes like a workflow stage by using columns, you are artificially picking a place in the workflow for it to reside. That wreaks all kinds of havoc! First, when you move an item into this kind of column, you can no longer see where in the workflow you experienced the wait. Did it get blocked in this stage or that one? Additionally, teams often use these pseudo-stages as a place to stash work so they can get around their WIP limits. This results in cycle times becoming longer and longer. Finally, when you are ready to put the item back into the real workflow, you have all of the data issues caused by backwards movement. A better practice is to visualize this kind of wait in the place where it is incurred. Yes, that may make it more painful but… that’s kind of the point. It can be the forcing function that causes you to face the problems instead of hiding them in forgotten columns. Add columns representing handoffs Handoffs are expected parts of the workflow and, when they come back from the handoff, they can move directly to next column on the board. In this way they are different than blocked or on hold columns and it is a very good practice to represent them using columns. The Key Takeaway In the end, there are no board police to decide what is right and wrong. There is no external governing body to keep you from making certain decisions for your board. Instead, it is up to you to understand the consequences of the decisions that you make and how they impact your ability to meet your goals. Take a moment to consider your board and the points in this blog post and determine if you can better enable flow!

Throughput is the total number of items completed per unit of time. You might have a throughput of 2 per day, 10 per week, or even 17 per sprint. Whatever your preferred time time unit, this flow metric helps you understand how quickly you finish work. That understanding is critical for forecasting how long it will take to complete a collection of work items. How do you calculate Throughput? There are two things you need to define to calculate throughput: Your Finish Line – or the point in your process that items are considered complete Your Time Unit – day, week, month, etc. Defining the Finish Line In order to define a finish line, you have to understand your process. A Kanban board is a great way to do visualize your process and make sure that it is clearly understood by all. Take a look at the board below: Kanban board with clearly marked “Finish Line” This team has defined the Done column as their finish line. So, any items that move into the Done column are counted as Throughput. Choosing a Time Unit You can use any time unit you desire to measure throughput. You can measure per day, per week, per month, per Sprint – you get the idea. If you aren't sure, use day as that is easy to measure and other types of time units are made up of days (unless you need to get smaller than that). 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. How do you use Throughput to forecast? Traditionally, people use their Throughput to determine an 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 simulations 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. 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!

Cycle Time is the total elapsed time it takes a work item to travel from one point of your workflow (a start point) to another point (the finish point). 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. Calculating Cycle Time Cycle Time is often expressed as: (Finish TU – 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? By adding one, this allows us to include both the start and the finish time unit in the Cycle Time so no time is left out. Cycle time is the total elapsed time it took from start to finish. This means it includes active working time as well any time that a work item is sitting there idle. So, whether work is waiting on someone, you’re blocked by a technical issue, or being interrupted by evenings and weekends, the time is included in an item’s Cycle Time. Sometimes teams visualize work time and wait time. It is all included in Cycle Time. Cycle Time cannot be calculated for a work item until it has reached your designated finish point. This means it is a lagging metric – one based on historical data. It is best to speak in the terms of your customer. They think in calendar days and not business days so we calculate cycle time in calendar days and not business days. It reduces misunderstandings. It's not inflating the metric, its reality. Julia Wester, Co-Founder @ 55 Degrees AB Why measure Cycle Time? 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. 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. Quickly looking at a Cycle Time Scatterplot chart above, in which each dot represents the Cycle Time of a given work item, we can easily say that we finish 95% of these work items in 23 days or less. This type of forecasting is reliable and extremely quick, allowing us to spend time on what’s truly valuable – doing the actual work. 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! Interested in tracking flow metrics like Cycle Time? Try out ActionableAgile for free today!

ActionableAgile connects directly to Jira, Trello and Azure DevOps Services so that you can connect to your data with zero hassle. However, if you want to analyze data from other systems or simply don’t want to use the built-in data loaders, you can manually upload your data! The options available to you depend on which version of ActionableAgile you’re using. In the table below, click the links to read detailed specifications about file formats, get tips, and see templates and example files for each available option. No matter how you load data into into ActionableAgile, you can feel secure knowing that we never store your data. All of your important information stays in your browser.

One of the things leaders often say they want most is predictability. Fortunately there are 2 things you can do every day to be more predictable. Predictability is defined as the consistent repetition of a state, course of action, behavior, or the like, making it possible to know in advance what to expect. Dictionary.com If you read that definition carefully, you may notice that the words good or bad are missing. Predictability itself is value-neutral. Being predictable is the attainment of the skills required to allow customers and other interested parties to have the advantage of knowing what to expect. Now, we all can think of an organization that we think of as predictably horrible at customer service (erm… certain cable TV companies come to mind) or a restaurant that has predictably bad food. So, it is fair to say that leaders want value-driving predictability, especially in regards to an organization’s ability to deliver value to its customers on a regular basis. How can we tell how predictable we are? Pretty easily! You can tell how predictable you are just two pieces of data for each work item you finish: the date you started the work item and the date you finished it. Using that data, you can create a Cycle Time Scatterplot and get a very visual view of your predictability. Each dot on a Cycle Time Scatterplot represents a single piece of work that was completed and where the dot is placed tells us how long it took to deliver that piece of work. This duration is referred to as cycle time. If more than one item finishes on the same day with the same Cycle Time, you just make the dot bigger and write the number of items on the dot. In the beginning, when you have little to no predictability, the dots will be widely scattered all over the chart. As you learn how to become more predictable, the range of space the dots inhabit will become vertically narrower. Read our previous blog post “Quick and accurate forecasts with ActionableAgile” to learn how to use this chart to make your forecasts reliable, even when your work and circumstances aren’t varied. Two things you can do daily to be more predictable! Now, that you know how to determine your level of predictability, you probably want to know what to do to improve it! Well, there are two simple, domain-agnostic things that you can do each day to improve your predictability: Thing 1: Stop starting, start finishing One of the biggest culprits of lengthening Cycle Time is multi-tasking. Well, we think we’re multitasking but what we’re actually doing is something called task switching — putting one thing aside to work on another and then coming back to the first thing later. Implementing a limit to the number of things you will work on at a time can help individuals, teams, or even organizations focus on fewer items at a time, allowing them to deliver the items faster and, usually, with better quality. This limit is called a work-in-progress limit, or WIP limit, and is a key component of a Kanban system. These limits can be implemented per person, per team as a whole, or even by activity in a workflow or value stream as seen above. The important thing is that you establish a threshold and adhere to it as often as possible. So, each day, as you make choices about what to work on, finish what you’ve already started before you pick up anything new! Thing 2: Pay attention to the age of work-in-progress Once you have WIP limits in place you can start an effort to make sure no one work item ever sits and ages for too long. To do this, you need to be able to see how old an item is. If you are tracking your cycle time, you already know when you started an item and you probably know the current date. With those two data points, you can get a good picture of how old your work-in-progress is. That information can be used in daily meetings to ensure you prioritize work that’s in danger of getting old. Much like the Cycle Time Scatterplot, the Aging Work In Progress Chart has a dot for each work item but the axes are different. The Y-axis is the age of the item so far. The X-axis represents which stage of your workflow the item is in. The dot is placed at the intersection of these two data points. It is important to remember that all of these dots will (hopefully) end up as a dot on your cycle-time scatterplot. So, we want to make sure they don’t get super old and, even better, that they stay within an expected range. When you take the percentile lines from your Cycle Time Scatterplot and overlay them onto your Aging Work in Progress Chart, you can get a much more detailed understanding of how at risk an item is for finishing in your expected timeframe. The percentile lines tell you how likely your work is to finish by a certain age. So, if you are at the very beginning of your process for an item and it is already older than 60% of your items are when they’re finished, you know that item is at risk of negatively impacting your predictability. And, while one item may be nothing to freak out about, if this happens often enough, you become less predictable and have to provide longer estimates to your stakeholders. So, if you’ve been looking for a leading indicator of predictability, the Aging Work in Progress Chart is just what you asked for! Yes, you can really do it! What’s great about this is that you really don’t need to be a data geek and you don’t need to be using a specific methodology, framework, or toolset to improve your predictability. By focusing on finishing over starting by implementing WIP limits and working on older items first, you can greatly improve your predictability without a huge overhaul of your processes — though it might end up being the start of something quite transformative! If this topic gets you pumped up and wanting to learn more, consider taking a workshop offered by 55 Degrees AB or try out ActionableAgile for free!

When you talk about forecasting with your colleagues you are apt to hear about a wide range of experiences and opinions. There is almost always a difference of opinion on how to actually determine a forecast and there's often disagreement on whether or not you should be forecasting at all. #NoEstimates anyone? I believe that both of these disagreements exist because traditional estimation processes are so time-consuming, and often inaccurate. At 55 Degrees we don't think forecasting should be avoided, but we do need to find a way to create forecasts that can work in uncertainty and doesn't waste time and sanity in the process. What forecasting technique does ActionableAgile use? The strategy we use in our flagship product, ActionableAgile Analytics, uses a technique called probabilistic forecasting. As the name implies it helps you provide a forecast that examines possible outcomes and the likelihood of each. This makes it perfect for situations where there's not a single obvious, inarguable outcome. A probabilistic forecast includes a range of possible outcomes and the probability you'll land on one of the outcomes in that range. Here are some examples: "We have an 85% chance of finishing a work item in 7 days or less." "There's a 95% chance we can finish 6 items or more in a sprint." "There's a 70% chance that we'll finish these 20 items on or before November 1." In ActionableAgile we figure out the range of outcomes and related probabilities by using your data and looking at the Cycle Time and Throughput of your past work. What can I forecast with Cycle Time? Using our Cycle Time Scatterplot you can forecast how long it is likely to take to finish a future work item based on how long it took to complete items in the past. Read more about our Cycle Time Scatterplot! What can I forecast with Throughput? While with Cycle Time you can create forecasts for individual items, Throughput allows you to create forecasts for larger efforts containing multiple work items. This can mean a number of things such as sprints, projects, releases, and more. Using your Throughput, our Monte Carlo simulations take the rate at which you finished work in the past to answer questions like "How many items can I finish by X date?" (Fixed date) and "When will this set of work be finished?" (Fixed Scope). Learn more about how our Monte Carlo Simulations work. What do I need to get started? If you haven't already, start a free trial of ActionableAgile - either in our SaaS version or install our app in your Jira or Azure DevOps instance. Then load in your data and you're off to the races. Our charts and simulations will automatically provide you with forecasts you can use based on your data. You can use the included chart controls to segment or filter your data any way you want to have ultimate control over what you're forecasting. We are always available to help via our support portal located at https://55degrees.se. We hope to hear from you soon!

Our customer, Redox, tells their story This is part one of Redox’s four-part “Contingency Planning During a Pandemic” series. It was authored by Morgen Donovan and is republished here with permission. Check out part two / part three / part four on the Redox blog. I had the good fortune of already working from home for a distributed company when COVID-19 struck. As the virus began to impact life as we knew it, I looked around and saw how other companies struggled to transition to a remote workforce. While all Redoxers felt the abrupt effects of COVID-19 social changes, because we were already working from home we had a leg up in responding to the impending crisis. We quickly began shifting our priorities to adjust to what may very well become a new normal. As we did this, we also realized we wanted to share our experiences, as other companies surely are or will be attempting some similar efforts. My hope is that this series, from a remote-first perspective, will help some of you who are facing the same challenges. The focus will be to expose our process and results clearly, and whenever possible, my co-writers and I will offer suggestions for alternative tools or methods to replace some of our own. Planning for the unexpected As cities and states began going into lockdown and the world had to start thinking about what to do when schools close or loved ones became sick, we realized we didn’t have a solid system in place for contingency planning around individual workload. Who would take over for me if I was out unexpectedly for two weeks, and would they know what to do? we wondered. And how could we tap into the capacity demands of each team and watch as it shifted throughout this crisis, so we would know where to focus our attention and provide help? There was a lot to do; we would need an army. So in a joint effort between the People Operations and Operations teams, Dietke Fowler, our director of Business Operations, and I enlisted the help of every HR recruiter plus our Knowledge Manager to get the ball rolling. We packaged all of the projected work into a single project, which we launched on March 26 and concluded on April 15. We kicked the project off with some goals already identified. We needed to: Implement a method for maintaining a current understanding of our capacity 2. Address potential capacity imbalances by: Identifying who has capacity and can help out in other areas Identifying who does not have capacity and needs help Shifting help to where it’s needed 3. Build resilience into teams through: Ensuring backups are in place for all work functions Documenting and storing our knowledge and processes in an easily accessible place From these goals, we built out some key deliverables we thought would get us to our desired end state. The deliverables evolved as we worked through our project, some becoming absorbed by others or outscoped, with some new needs arising. Here’s where we landed: Launch weekly capacity pulse checks that can be reported out by team and role. Create a virtual Help Desk that allows Redoxers to post their needs, help-wanted style, and lets other Redoxers offer up their help. Implement individual contingency plans that identify who is working on what, backups for that work, and whether the work does or does not have process documentation already in place. In this post, I’ll talk about our first deliverable, the work we did to achieve it, and its outcome. Each following post will dive into the remaining deliverables. Deliverable №1: Implement regular capacity pulse checks The work We wanted to send out surveys every Monday, and because they had a three-day turnaround they had to be short, with a low barrier to entry. We needed to be able to filter our results down by team and generate data on capacity, when considering factors both internal and external to work, as well as cognitive load. We used a Google form* and kept it simple. The first component of the survey checks stress levels on a 5-point agree/disagree scale: My own stress, worry, or general cognitive load is negatively affecting my ability to complete my work. Situations external to Redox, such as caring for children or other family needs, are negatively affecting my work capacity. Situations internal to Redox, such as disruptions to my team/other Redoxer outages are negatively affecting my work capacity. The second component asked Redoxers to compare their current work capacity (availability and presence) to their capacity prior to the COVID-19 pandemic using a scale of 0 to 10 (where 0 represents “no capacity,” and 10 represents “still at 100% capacity”). Finally, we asked Redoxers to compare the current demand for their time against the demand prior to the COVID-19 pandemic using a scale of 1 to 5 (where 1 represents strongly decreased and 5 represents strongly increased). We launched our first survey on March 30th via email to every Redoxer with a follow-up post in our “important-only” slack channel. That same evening, our CEO, Luke Bonney, asked all of us in his video address to complete the survey. This crucial component of our messaging effectively told all that this high priority effort required everyone’s participation. As the results came in, we fed the data into Chartio, linking the email addresses of respondents from the Google form with demographic data from our human resources information system (department, subteam, coach, location). The resulting dataset served up various charts on a dashboard that displayed the survey results graphically as well as in plain language. The dashboard could be filtered down by team, coach (manager), and status of response (responded or not responded). While we used SQL in Chartio to join the survey data with our team directory, you could also use visual dataset builders or SQL in other data visualization tools, or even VLOOKUPS in MS Excel or Google sheets. The result By Thursday of that first survey week, we had achieved 89% participation companywide, and we were pleasantly surprised by this level of engagement. The results were surprising as well — they told us that the average impact of COVID-19 on our capacity wasn’t as drastic as we had originally estimated. Redoxers were reporting that situations internal and external to Redox were having a moderate impact on their work capacity, and their general cognitive load was adding an additional moderate level of impact. On the upside, there was only a little more work to do on average. For the first week, these results were reassuring and provided us with a good baseline to track against in the upcoming weeks and months as the pandemic’s effects continue to evolve. In addition to company-wide metrics, we also created visualizations that compared departments across the company. This allowed us to pay special attention to departments that were feeling the most impact. The plan was to survey our team weekly, but Redoxers reported that they were already experiencing some survey fatigue (there’d been a few other surveys launched in the previous two weeks). After some consideration, we decided that biweekly would get the job done just as well, and our CEO again communicated this new plan to the company. We are incredibly fortunate to have our Knowledge manager, Jessica, working tirelessly to get each of us documenting our knowledge and work processes. Going forward, she will review the biweekly results and reach out to teams most in need to determine if she or others can help them reach knowledge management goals. For teams needing help beyond that scope, we created a brand-new resource to make it easy to ask for and receive assistance — the Help Desk, which Becky will talk about in our next post for this series, so stay tuned! As we all continue to work through a challenge most of us have never experienced in our lifetimes, let’s keep up this culture of educating each other, and continue to lean on one another for support. Note from Morgen @ Redox: We chose this over our regular survey platform Culture Amp, as we didn’t want to overuse and diminish the future effectiveness of this powerful tool. Your organization might prefer a different way to manage surveying.