Search Results

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!

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!

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!

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!

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.

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.

A presentation at the Øredev developer conference in Malmö When I was a manager, I wanted to make a difference. A positive one. As a consultant, I work with managers who have the same goals. I’ve not yet come across anyone who wants to ruin everything (fortunately). When I started hearing the rhetoric about getting rid of the managers years ago, I was startled. Was I part of a huge problem that I didn’t even know existed? This question led me on a journey that had me studying the history of management and what people really thought of my past performance. I shared part of that learning in a talk at Øredev in Malmö, Sweden a couple of weeks ago. There is so much more to talk about on this subject that couldn’t fit in the talk. Please watch and let’s chat about your thoughts and experiences!

Sometimes you need to change your approach When I watch the news, read social media, or listen to arguments about how to do something, I am struck by how far we’ve gone into the land of right vs. wrong. Unfortunately, it doesn’t feel like we’re just passing through. Instead, it seems we’ve built permanent structures and are settling in for the long haul. An example: U.S. Politics To understand what I mean, you need to look no farther than the US political scene. In a two-party system, there is meant to be a constructive conflict between adversaries that results in largely beneficial outcomes for the citizens the two parties serve. Working through the merits of different viewpoints allows people to come to better solutions for tricky questions like “How much should the government spend on social services?” or “When should the federal government make laws vs deferring to state government?” Unfortunately for U.S. citizens, the adversaries have transformed into enemies. Instead of constructive conflict with productive results, we now have regular battles to see which party can come out on top. The topic seems to matter less and less as time goes on… the language is usually about winning instead of serving the citizens. Policy making in America is approaching all-out war, where victory is paramount, “compromise” is a dirty word, and virtually any issue or development can become a weapon for bludgeoning the other side. David A. Moss, Harvard business review, march 2012 issue Ironically, when you lose sight of the goal you are trying to achieve and focus on the act of winning at all costs, everyone ends up losing in the long run. The citizens lose first, then the politicians lose when the citizens are tired of losing. Battlefields exist at work too Unfortunately, this problem isn’t limited to politics. We see this behavior in organizations as well. It is common to see departments focus on their needs and desires at the cost of overall business outcomes. Consider the time you’ve spent in discussions about prioritization at work. When is the last time you came out feeling as if everyone could accurately and selflessly compare their request amongst all the rest? I am guessing the answer is “Not often” or “Never.” We see methodological ideologists bash ideas without any recognition of the struggle that led to its creation, what it might be trying to achieve. If you have no idea what I’m talking about, just search for posts about SAFe on any social media outlet. Most of the detractors have valid points at the core of their arguments, but I’d wager a bet there is a correlation between the level of vehemence in their arguments and their blindness to anything that might be good in SAFe. Methods aren’t alone in being a target. We do this with tools as well. Everyone has tools they love to hate so much that they can no longer recognize any value that it might actually provide. Jira seems to be the most popular target these days. Let’s face it, we do need to know the downsides of the things we love. Knowing the limitations of a thing helps us use that thing properly. But the inverse is true also. If you are going to be a detractor of something, understanding the value it might bring to specific contexts is important to recognize. If you are going to be a detractor, its best to be specific about the context you are speaking from. Is it just one specific context you have a problem with or are you convinced that this thing is bad in all contexts? In the long run, we don’t serve the public with tweetable, snarky quips. We serve them with a reasoned, minimally-biased look at whatever we are commenting on. What we need is a balance We can’t wait for someone else to act to begin to restore sanity. We all have a part to play. It starts with realizing that “not everything is a problem to be solved, some things are situations to be managed,” as Barry Johnson says in his book Polarity Management: Identifying and Managing Unsolvable Problems. This means that there is not always a right or wrong. Sometimes there is only a balance to be found between two opposing, yet valuable, forces. In Sweden, we call this balance Lagom and it is something that we have to discover in each specific context. When I first started thinking about this I began creating a Spectrum Thinking Worksheet to help people identify what balance looks like. It includes writing down the following info: The opposing forces (extremes) at play Why it is important to balance them The value that each brings The negative consequences of over-focusing on one extreme What it looks like when you get it just right One of the things I want to help people realize is that balance doesn’t mean settling for average, or splitting the difference. Finding lagom means finding the place of contentment or equilibrium. This balance should be sustainable. And, like with a fulcrum, where you find this balance is highly dependent on the makeup of the forces at the poles. It may be heavily weighted towards one side or another, depending on your context. If you explore the same spectrum in two different contexts you will likely find that lagom looks different in each. Keeping your balance Once you have explored the spectrum between, and including, two extremes, a Polarity Map helps us visualize how these forces are really interdependent pairs. How, if you over-focus on one area, hoping to achieve the positive effects, you can tumble out of balance into the negative consequences you were working really hard to avoid. I was really excited to find this concept of polarity mapping as it overlaps quite a lot with my work on finding Lagom. Like with our Spectrum Thinking Worksheet, polarity mapping asks you to identify: early warning signs that you are getting out of balance. action items that you can and will take if the early warning signs you anticipated start to appear. But, thinking through where Lagom is on a spectrum gives you some particular insights about balance that you might not get using polarity maps alone. Using one or both of these tools will help you switch your default from binary thinking to spectrum thinking and understand how to find a balance between two valid, yet opposing viewpoints. Getting Started Don’t wait for someone to make the first move. It is up to us to bring sanity back to our lives. Perhaps your move will inspire others or show them how to make a difference. Identify a situation in which you’re being too dogmatic or ideological, to the detriment of your well-being or that of those around you. Then, use the Spectrum Thinking Worksheet alongside a Polarity Map to a) articulate the value of the opposing perspective, b) explore the spectrum between and determine what balance looks like, and c) anticipate early warning signals of falling out of balance and action items you’d take to get back to lagom. I would love to hear from you if you are using the Spectrum Thinking Worksheet and/or Polarity Maps. How have you struggled? How have you benefitted? Please share with us via our contact form.

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!