In this video, we will continue with the overview of Kanban. We will start by discussing work in progress limits. Limiting work in progress is done by specifying the minimum and/or maximum number of issues allowed in certain Kanban board columns. Limiting work in progress has many benefits. If you limit work in progress, there are less issues being worked on at any one time, which leads to better flow of work getting finished. Because of the work in progress and limits, the team focuses on finishing the work in progress before starting new issues. This focus results in less multitasking, which is good because multitasking decreases productivity. The delivery of issues is faster with less work in progress because issues are not piling up in certain columns waiting for the work to be restarted. Limiting the amount of work in progress means that issues are sure to achieve the 'done' status. This means that the work is really done and can be provided to the customer. Moving issues into the 'done' status is the primary measure of progress of the team. By limiting work in progress, any bottlenecks in the process are quickly identified because there are relatively few issues in progress at any time and problems tend to be easily visible. Identifying and fixing bottlenecks is a way to continuously improve the work of the team. Limiting work in progress also limits the amount of waste in the process. If there is an inventory buildup of issues in a status, there is waste because the work on the issues is delayed. Limiting work in progress also limits the amount of rework that may need to be done if there's a problem caused in an early process step, but identified in a later step. There are simply less issues to fix. Limiting work in progress has the effect of promoting teamwork. Because the number of issues in a status is limited by the work in progress limit, the team tends to work together to clear up the blockage. The link at the bottom is a good article on work in progress limits in case you are interested in more discussion on the topic. To set up work in progress limits for a column, click on the Columns tab of the board settings. The work in progress limits are called Column constraints in Jira. In the column constraint dropdown, you have the option of defining the constraint on the number of issues or the number of issues excluding sub-tasks. Sub-tasks are used to break down the work of an issue into smaller pieces. Underneath the column name, you can see the column constraints. You can see that currently, each of the columns has no minimum or maximum constraints. Here, we change the minimum constraint on the selected for development column to two issues. This means that if there are ever less than two issues in the column, that column will be highlighted in yellow on the board. A minimum like this would probably make sense because the team always needs to be able to pull new issues to work on when they finish other issues. For the In Progress column, we define a work in progress limit of three issues maximum. If more than three issues have the In Progress status, this column will turn red on the board. A team of three people might choose to have a work in progress limit of three, ensuring that existing work is finished before new work is started. After we have configured the work in progress limits, we can test our configuration. You can see that the selected for development column now has a 'Min 2' indication next to the column name. Since we only have one issue in this column, it is highlighted in yellow. This is a signal that notifies the team that issues should be added to the column. You can see that the In Progress column now has a 'Max 3' indication next to the column name. We have four issues with the status of in progress, so the column has turned red. This is a signal to the team to finish the work in progress before starting more issues. Notice that we don't need to put limits on the backlog or done columns because those statuses do not contain the team's work in progress. What should work in progress limits be set to? The short answer is that depends on the specific project and the team. Here are some ideas. You could start with no work in progress limits and see if the issues are flowing nicely. You could add limits as the process starts to show problems. For instance, if sometimes, there are no items in the Selected for Development column, the flow is negatively affected because the team can finish an issue and have no issues to work on. You might want to set a minimum constraint on the Selected for Development column to ensure that this doesn't happen. You could also set work in progress limits to discourage multitasking. For example, if the team has seven members, you might want to set limits so that each member is working on only one issue at a time. You could also set work in progress limits on the steps that the team tends to neglect. For example, this workflow has a Review status after the In Progress status. This step ensures that other team members have looked at the work before it is considered done. If you find that issues are piling up in the Review column, you can set a maximum limit on that column to ensure that the issues flow all the way to the Done step. Next, we will discuss pulling versus pushing work. The performer of a step in the workflow either pulls the work from the previous step or has the work pushed to them. If we go back to our example workflow where a restaurant takes and delivers orders, we can see that sometimes, the work is pushed and sometimes it is pulled. After the wait staff takes the order, they usually push it to a queue for the queue to start when they get a chance. When the cook has the availability to start preparing the order, the cook pulls the order from the queue and places it in the work in progress location. After the food is prepared, the cook pushes the order to the wait staff delivery queue. When the wait staff has availability, they pulled the order from the delivery queue and deliver it to the customer. So, you can see that in this workflow, sometimes the performer of the work pulls the work from the previous step, and other times, the work is pushed to them from the previous step. Overall, this process is a pull process because the cook only prepares the orders after they are received. If no customers come in, the cook never prepares any orders. If this was a push process, the cook would prepare the food ahead of time and wait for customers to come in and take the food. If no customers come in, the food could be wasted. Pushing and pulling of issues can happen on Kanban boards. Typically, an issue is pushed onto the 'selected for development' when it is ready to be worked on. Any issue in this 'selected for the develeopment' column is only pulled into the 'in progress' column when a person is ready to work on the issue. This is the main reason why the overall process is a pull system, the people doing the work pull issues only when they have availability. When the work of the issue is complete, the person that did the work pushes the issue onto the 'done' column. Sometimes you might want to add queue columns to your workflow. For example, in this workflow, we have a 'review' column before the 'done' column. An issue in the 'review' column usually means that the work of reviewing is underway. However, when the 'in progress' column is complete, if you push it into the 'review' column, a reviewer may not be available to work on it. If a reviewer pulls the work from the 'in progress' column, the work of the issue might not be done. This is a good case for inserting a queue before the 'review' column. Here, we have added a queue called 'development done' to the workflow. When the work of an issue in the 'in progress' status is done, the performer can push the issue to the 'development 'done' queue. When a reviewer is available, they can pull the issue into the 'review' column. Adding this queue makes the exact status of the work item easier to see. We have seen that pulling work is common in the Kanban method. We will also see later that most agile methods pull work because the development team decides how many issues can be worked on and pulls an issue to start the work. Pulling work is common on agile teams because it enables team members to select their work. This happens in a self-organizing empowered team, they are not assigned work. Pulling also maintains a sustainable pace. A performer only pulls more work when they are ready instead of work being pushed to them that they may or may not keep up with. Next, we will discuss Kanban reports. Reports are a key tool related to being agile. Like with boards, agile reports help to visualize the work of the team, this promotes transparency of the project allowing anyone with access to see and have a common understanding of the current state of the project, the transparency means that there should be no surprises about the delivery of the project. Reports help with troubleshooting and continuously improving the project. For example, certain reports can clearly show process bottlenecks. Reports also help with planning the work of the team. They are commonly used in planning meetings to help see the historic progress in the team, and provide more accurate planning and estimating. A cumulative flow diagram is a popular report for Kanban projects. This is because maintaining and improving the flow of the team is a higher priority. To access a cumulative flow diagram for a project, click on "Reports" in the contextual sidebar and then click "Cumulative flow diagram". JIRA provides automatic real time reporting. As the team updates issues, the reports are automatically updated, all you have to do is view them. A cumulative flow diagram shows the number of issues per status over time. You can see from this diagram that for the first few days, all of the issues we're in the backlog status indicated by the orange band. The number of issues in the backlog status increased from one to five before the first issue was moved to 'selected for development', which is the second band here. The third third represents issues with the 'in progress' status, so you can see that actual work on an issue started here. The final band indicates issues with the status of 'done'. You can see that the 'done' band increases nicely over time indicating pretty good flow. You can see that the backlog has almost been depleted indicated by the shrinking orange band. You can see many important Kanban related things from a cumulative flow diagram, including bottlenecks in the process, overall flow improvement and how well the team is keeping up with the backlog. You can't really see individually issue problems with this diagram, you can use other reports or views to focus on specific issues. Lead time and cycle time are two terms related to processes. The lead time is the time from tissue creation to completion. In this workflow, the lead time is the time from when an issue is created to the time that it is done. If a customer is waiting for an issue to be complete, they care about the lead time. Cycle time is the time from starting work on an issue to its completion. In this workflow, the cycle time is the time that the issue is in the 'in progress' status. The team mostly is concerned with improving cycle time. The work in progress limits that we discussed earlier help to reduce cycle time. A cycle time control chart is used to show the cycle time for issues over time. A circle is placed on the chart when an issue is moved to the 'done' column, the elapsed time is the time that the issue spent in the 'in progress' status. As mentioned earlier, this is the cycle time for the issue. You can click on an issue to see the issues details. The solid blue line shows the rolling average cycle time. In general, you would like to see the team improve the cycle time as is done here. Trending down means that issues are completed faster as time progresses. The red line indicates the average cycle time for the period of the chart. The shaded band indicates the standard deviation of the cycle time over time. That band becomes more narrow if all of the issues are completed with about the same cycle time. Process improvements can narrow this band increasing the predictability of the team and improving estimates. We have seen just two examples of the reports that JIRA automatically provides for Kanban projects. In the lab, you can feel free to explore more of the reports. Here is a review of what we've discussed in this video. Work in progress limits improve flow and quickly identify bottlenecks. Agile team members often pull work from a previous column rather than have the work pushed to them. A cumulative flow diagram is a common Kanban report and shows the number of issues in each status over time. Now, it's time for you to work with some of the things that we've discussed in this video. Separate hands-on instructions are provided for you.
