Updated: Nov 20, 2022
For the PMP exam, On-demand is a critical topic. We can expect many tricky agile questions based on this scheduling approach.
This article will take your understanding of this On-demand to the next level and enable you to take many agile-related questions confidently.
In this article, we will cover many vital topics like Velocity, Throughput, Cycle Time, Lead Time, Work In Progress (WIP) Limit, Theory of Constraint, Pull and Push Systems, Little’s law, Single Piece flow, and batch processing, Process Bottleneck, and few others.
So, let’s dive in.
We will start with knowing what is meant by Scheduling.
According to PM’s Practice Standard for Scheduling
The schedule details who, where, and when the assigned project resources will deliver the products, services, and results defined in the project scope.
With the Project schedule, we can say when all the planned work will be completed, and the project will end.
Scheduling is one of the basic elements of project planning and analysis. The project manager and project team use the project schedule as a primary tool for planning, executing, and controlling all project activities.
In simple, if someone asks you when your project will end? To answer this question, you will need the project schedule.
Projects are done to produce and deliver value to the project stakeholders, especially, Customers and users.
In the Predictive approach, the project value shall be delivered as a single delivery toward the end of the project. With Project Schedule, you can approximate when the final delivery can be handed over to the customer.
In predictive projects, we can’t deliver the project values in parts (increments) to speed up the value delivery process. Moreover, we choose predictive because the product or service we intend to deliver shall not support project work delivered in parts. E.g., the Construction of a House or Aeroplan.
However, in agile projects, we don't have this issue. In agile projects, we make increments, demonstrate to the customer, get feedback and deliver the increment. This will help us to realize quicker value delivery.
If you're talking about delivering in increments, then the scheduling approach needed is different in agile projects. In predictive projects, we complete upfront planning and execute and deliver the work. Since we practice incremental delivery in agile, we primarily have two scheduling approaches.
1. On-demand scheduling
2. Iterative scheduling.
On-demand scheduling is used where the work package sizes are even, and single-piece flow is expected.
Whereas iterative scheduling is more suitable for projects where the work package sizes are not even, batch processing of work packages is more appropriate.
The metrics used in on-demand and iterative scheduling are very different.
On-demand scheduling uses cycle time, lead time, and throughput. In contrast, Iterative scheduling uses velocity as its primary metric.
Cycle time is from Venus, and Velocity is from Mars
Both on-demand scheduling and Iterative scheduling are used in agile Projects. However, both cannot be used in a selected agile methodology.
Agile frameworks and methodologies like scrum and XP use iterative scheduling, whereas Kanban uses on-demand scheduling.
We need a Project Schedule to predict when the project will complete. We need cycle time or velocity metrics in Agile projects to develop the Schedule.
Remember, we don't have to use both cycle time and velocity to produce a schedule. If you think your project is more suitable for on-demand scheduling, then develop the schedule using cycle time. Otherwise, use Velocity and apply Iterative scheduling.
Iterative Scheduling shall be covered in a separate blog. In this blog, we will discuss On-demand scheduling in detail.
On-demand approaches are based on pull-based scheduling concepts from Lean manufacturing. It is a concept from lean manufacturing and is primarily used in Production environments. Later the software industry adopted on-demand scheduling for software development.
On-demand scheduling is a pull system where the work from To-Do List is pulled and performed. This To-do List is called Queue.
The primary metric in on-demand scheduling is cycle time.
In a manufacturing process, there will be many process steps. The time required to perform each process step is called cycle time, and the process will be made of many process steps. A process is about how the input is converted to the intended output.
For example, if you want to develop a software feature, you must follow many process steps like Design, Development, Integration, and Testing.
A feature must go through all these process steps to get finished.
The time required to perform process steps is called cycle time.
And if we add up all the cycle times of the processes, we get the total time needed to build a feature from start to finish. This time is called the Lead time. To define the lead time of a process, we need to add up the cycle time of all the individual process steps in that process.
Software development Lead time =
Design cycle time + Development cycle time + Integration cycle time + Testing cycle time step
On-demand scheduling is based on the theory of constraints. Theory of constraints is a management theory that states that the system's throughput is based on its bottleneck.
Throughput is the rate at which the work can be completed.
In projects, the process we follow is this system, and to understand the bottleneck of the system, we must study the cycle time of all the individual process steps. The process step with maximum cycle time is the system’s bottleneck, which decides the process’s throughput.
For example, in our software development process, let's assume the cycle time for each process step as below.
Design cycle time = 4 hours
Development cycle time = 8 hours
Integration cycle time = 2 hours
Testing cycle time = 1.5 hours
In this case, the development process step has the maximum cycle time compared to other process steps. And therefore, it is the bottleneck of the process.
Once we know the bottleneck process step, it is easy to calculate the process throughput.
Throughput is the same as speed. If someone asks you how much distance you can cover in one hour. You may say 80 miles per hour. The same applies to throughput.
Throughput = Given Time Window / Cycle time of the bottleneck process step
In our case, the cycle time of the development process step is equal to 8 hours, and let's assume we want to know how many features we can develop in a week (considering a person works five days a week and 8 hours per day). A week has 40 hours of work capacity.
Throughput = 40 hours / 8 hours = 5 features.
So based on the cycle time of the bottleneck process step, we can complete 5 features in a week.
Let's say you have a To-do list with 40 features and assume all these features are of even size. You're in the project’s initiation phase and want to determine when you will complete all these 40 features.
Don't you think that after knowing the throughput of the process, you can estimate this easily? The answer is yes. Knowing that you can complete 5 features in a week with one resource, it will take 8 weeks to complete all 40 features with one resource.
A project schedule is all about finding out when we will be able to complete the project.
Now, is it not easy for us to find the answer to the question of when we will be able to complete the project after knowing the throughput of a process? Yes, we can.
In on-demand scheduling, after knowing the cycle time of the bottleneck process step, we can calculate the process throughput, and with process throughput, we can develop the project schedule.
And because the process steps with maximum cycle time act as the bottleneck, otherwise the constraint, on-demand scheduling is also called a constraint-driven scheduling approach.
The To-Do List of the project is called the Queue.
Now let's learn why on-demand scheduling is referred to as the Pull system
The work can only be fed into this process once the bottleneck process step becomes free. The previous process steps can perform the work, and they will complete it earlier than the bottleneck process step; however, they have to wait for the bottleneck process step to complete its current work to pull the next work from the predecessor process step. The predecessor process cannot push the work to the bottleneck process step (its successor) until the bottleneck process step has been done with its current work. That's why this is called the pull system.
In a pull system, the direction of workflow is right to left. In contrast, a push system's workflow direction is left to right.
But what's the benefit of a Pull system?
The pull system will help us to keep the work in progress (WIP) under control.
First, let's understand what WIP is and why we need to keep it under control.
Work in progress is a form of waste in Lean manufacturing. On-demand scheduling approach is native to Kanban methodology and part of Lean. Though Kanban is one of the agile methodologies used in software development projects, it is originally from the manufacturing domain.
Taiichi Ohno developed Kanban and applied it at the main Toyota manufacturing facility in 1953. He was inspired by the Just-in-time inventory replenishment system used in grocery stores to restock shelves based on gaps in the shelves and not on supplier inventory. The literal translation of the Japanese word Kanban is “visual sign” or “card”. These visual boards are made of columns representing the status of the work that needs to flow through to complete them. The most straightforward Kanban board comprises three columns; To-do, In-progress, and Done.
Items in the In-progress column are called work in progress (WIP). And according to lean manufacturing, WIP is a form of waste. Taiichi Ohno used Kanban and other lean manufacturing methods to eliminate waste in the production line. Kanban helped to improve production throughput by keeping lesser WIP limits in production stages. (Note: we will discuss the relationship between WIP limits and throughput later). Later the IT industry adapted Kanban for software development.
The number of work items waiting for a process step is called Queue. The process steps with a longer cycle time shall have long queues in front of them. This is because the predecessor process is supposed to have less cycle time to complete many work items before the successor process step can complete a work item. The queues in front of bottleneck process steps can be kept growing based on the cycle time of the bottleneck process and the cycle time of its predecessor process step. The more significant the difference between the bottleneck process’s steps cycle time and the predecessor process’s cycle time, the lengthier the queue will be.
The lengthier the queue, the more the WIP will be. The more the WIP, the more the waste!
Now let's see how the Pull system will help us to keep the WIPs under control.
First, the Pull system has built-in resilience to work against WIP. In the push system, we can’t plan X amount of work, dump it inside the execution, and try to complete all of them. In a Pull system, the process steps will finish the current work based on their cycle time, and once they are done with the present work, they can pull a new work from the queue to work on it. This will keep the process lean. The Pull system is based on single-piece flow and will not support batch processing. This will help us to keep WIP under control.
In addition, we will also set a WIP limit for each process step. WIP limit decides the size of the queue of each process step—the smaller the WIP limit, the lesser the waste and the greater the throughput.
How to set the right WIP limit for optimal throughput will be discussed later.
Now, you have a fair understanding of WIP and how Kanban was developed.
Let's understand why more WIP is not suitable for the project.
According to lean manufacturing WIP is a cause of many forms of waste.
Items in work-in-progress are incomplete work and cannot be delivered to customers. Hence they won't generate revenue. Also, they cease financial capital and make it unavailable for value-added work.
In the software development process, there are seven types of waste. Partially done work, extra features, relearning - not learning from the mistakes, hands off - extra work done during task handovers, Delays, Task switching –Time and focus lost during context switching because of multitasking, and Defects.
WIP has business to do with many of these wastes.
More items in work in progress results in multitasking. The process step owner has to work on many items simultaneously. This leads to time and focuses loss due to context switching. Studies have proven that at least 10% of project time is lost to context switching. WIPs also hide defects. Defects in the work can be identified late in testing or feedback due to prolonged feedback loops. Discovering defects late is a big risk, increasing the cost of quality.
We want to create an artificial constraint on how many items can be in each process step queue. These are called WIP limits.
WIP limits will help us to eliminate waste and increase process throughput.
The minimal WIP limits are better for the project. Fewer work items in the queue result in lesser loss due to context switching, reduce project risk by lowering the cost of quality and increase productivity.
Also, limiting WIP will surface process improvement opportunities. Acting on these opportunities may lead to better throughput.
So, it is clear that too much WIP is not good. At the same time, we cannot keep the WIP limit to 0 and 1.
While selecting the WIP limit, we should be in the Goldilocks zone.
Too high WIP leaves work idle - many items will be waiting in the queue, affecting project throughput.
Too low WIP leaves people idle - people in most of the process step will be doing nothing as they will be waiting for incoming work.
The rule of thumb is “lower the WIP is better”. Striving for a low WIP limit is desirable because it gives you better flow or throughput.
WIP limits must be set to improve throughput rather than focusing on resource utilization.
Throughput is inversely proportional to the number of work items in the WIP.
So, can we set the WIP limit to 1 for optimal throughput? No.
Because this will probably disrupt the workflow, it is always to have a few items in WIP to mitigate events like work package hands-off, materials shortage, equipment downtime, people out of the office, etc. if we don't have adequate work items in WIP this will result in a work stoppage.
There are no complex rules here, but to find a suitable WIP limit, we must consider the context and what we want to achieve. WIP limit is decided based on various factors, including the cycle time of the current process step, cycle times of the previous and next process steps, the number of resources assigned in the current process step, the Organization’s hunger for continuous improvement, etc.
Relationship between cycle time, throughput, and WIP limit
We're going to learn about something called Little's law.
So far, we have understood two things.
First, Cycle time is inversely proportional to throughput.
The lesser the bottleneck process step cycle time, the greater the process throughput will be.
Second, Throughput is inversely proportional to the number of work items in WIP.
The lesser the WIP we have in the bottleneck process step, the greater the process throughput.
If we combine these two facts, we get
Cycle time = Number of items in WIP / Throughput
This equation is called Little's law. John D.C. Little came up with the mathematical proof that the more things you have going at the same time, the longer each thing will take and provided the above equation.
The more the item in WIP results in multitasking, creating losses due to Context switching. And due to a delayed feedback loop, we tend to do many reworks. These are some of the reasons why we should deal with only a few work items simultaneously. Keeping the WIP limit minimal will help us focus on a few items at a time, resulting in decreased cycle time and improved throughput.
Project schedule development exercise using on-demand scheduling
Let’s apply what we have learned and develop a Project schedule using on-demand scheduling.
First, we shall assume we have the process below with the process steps mentioned and their cycle times.
From the given process, we can see that the development process step has the maximum cycle time and it is the bottleneck process step.
The bottleneck process’s cycle time = 5 hours (Development process step)
Next, we need to know all the work that needs to be performed. It’s assumed that we get this in a format of a product backlog. The product backlog is an extensive list of features that must be delivered to complete the project successfully.
Assume that our project has a product backlog with 150 features in it. And we need to find out when all these 150 features can be delivered if the bottleneck process’s cycle time is 5 hours.
Technically speaking, cycle time is the amount of time required for a process step to complete a standard unit of work. The process step’s cycle time is a function of the size of the work it processes. If the size of the work varies every time, then it's not possible to realize a stable cycle time.
And this is one of the main reasons why on-demand scheduling works well in projects where the sizes of the work packages are even.
In our example, let's assume we have decomposed the total project work into 150 features of even size in terms of complexity and lines of code. (Note: However, this isn’t easy to achieve in many projects, so applying on-demand scheduling in many software projects is a challenge)
Other inputs needed are the number of resources, working hours per day, and working days per week. Below are the numbers we have to create our schedule.
Number of resources = 1 Designer + 1 Developer + 1 Integrator + 1 Tester.
Number of working hours per day = 8 hours
Working days per week = 5 Days
Now that we have all the input to develop this schedule let's find out when we can deliver all the 150 features with 5 hours as our bottleneck process cycle time.
The bottleneck process step will take 5 hours to develop one feature (one unit of work). For 150 features, the time required is equal to 150 x 5 hours = 750 hrs.
Since we have only one resource to work on the development process, step 750 hours remains intact.
750 hours / 1 Headcount = 750 Hours.
Let’s convert 750 hours into a number of working days considering each day has 8 hours.
750 hours / 8 hours = 94 days (approx.)
So, we have a schedule of 94 working days. Now let's apply calendar days and consider weekends to find the project’s start and end dates. 94/5 will give us the number of weeks we need. 19 Weeks approximately required.
Let's assume we are starting the project on 1st January 2022 (calendar week 1), and with 94 days schedule, we'll end on calendar week 19, which will be 13th May 2022.
The rate at which the features can be delivered can be found by calculating throughput.
Throughput = Given Time Window/cycle time of the bottleneck process step
Suppose your sponsor asks how many features can be delivered in a week.
You can calculate throughput using the above formula and find the answer to that question.
One week = 40 Hours (5 days x 8 hours)
Throughput = 40 Hours / 5 hours = 8 Features per week.
So, it is clear that you can complete 8 features per week with the given bottleneck cycle time.
Suppose you want to complete the project earlier; what steps will you take?
If you want to optimize the schedule, we must work on the bottleneck process step. We can optimize the cycle by splitting the work, doing it in two separate process steps, steps or by increasing the number of resources working on it. We can use these techniques to improve project throughput.
Assume that instead of one developer, we are assigning 2 developers and increasing the WIP limit of the development process step to 2. This way, we can work on 2 features simultaneously, reduce the cycle time by half (5 hours / 2 = 2.5 hours), and double the throughput rate. This means we can deliver 16 features per week and complete the project in 47 Days.
The project schedule should help us to find the answer for when we will complete the project and when each project item or increment can be delivered. Could we answer these questions with the above calculations? Indeed yes.
This exercise taught us how to create the project schedule using the bottleneck process’s step cycle time and the rate at which we can deliver the features based on throughput.
Kanban board and Kanban methodology are different.
Kanban is an agile methodology based on a flow-based scheduling approach focusing on single-piece flow and keeping the WIP less. It also helps us to identify process bottlenecks and work on improving those bottlenecks.
Whereas the Kanban board is one of the tools used in Kanban methodology to visualize the workflow. Just because you are following Kanban in your project doesn't mean that you are doing the project using Kanban methodology.
Many Iteration-based agile approaches like Scrum or XP use Kanban board to visualize the workflow, but that doesn’t mean Kanban methodology has been applied.
The Kanban board is a low-tech, high-touch tool. Simple to use but effective.
The simplest form of Kanban board shall have a minimum of three columns. They are To-do, In progress, and Done. The In progress column is very critical because this is where we will set the WIP limit. Keeping lesser WIP is a way to optimize throughput and reduce waste.
Suppose you have many process steps, and If you want to keep the WIP limits separately for each process step and monitor their WIPs, then you can create In-progress and done columns for each process step individually.
Benefits of Kanban board
1. Visualization of workflow brings transparency and helps us in information sharing. It shall be part of the information radiator.
2. Help us to identify process bottlenecks and address them.
3. Help us to measure work progress. More items in the Done column are good news.
4. Help us to optimize WIP limits based on learnings and project needs.
5. Task assignment and Task accountability.
Note: Kanban board and task board are not the same. Both are used for workflow visualization; however, the task board does not have any focus on controlling WIP. We don’t set WIP limits in a Task board. The Task board does not work based on a pull system. Instead, it works based on a push system. Once the predecessor process step performs the work, it will be pushed to the successor process step even if it is busy, leading to uncontrolled growth of WIP queues. In the exam, if you see the term Task board and Kanban board, you better pay attention to the scenario and select the right option.
Benefits of on-demand scheduling (KANBAN Methodology)
1. Flexibility. The teams are typically not bound by time boxes.
2. Focus on continuous delivery. The focus is on completing the in-progress work and then starting new work. This will enhance the workflow through the system.
3. Increased productivity and quality: greater throughput, fewer quality issues, reduced risk, and quicker feedback loops.
4. Reduction of waste. The transparency of the WIP makes waste visible, so the team can work on keeping the WIP minimal.
Demerits of on-demand scheduling (KANBAN Methodology)
1. On-demand scheduling is more suitable for projects where work packages are of even size. To have a stable cycle time, the process steps need to work on even-size work packages all the time. This is one of the demerits of on-demand scheduling. It is difficult to decompose work packages of the same size and complexity in software projects. Remember, on-demand scheduling originated from manufacturing, where the work package sizes are always even.
2. Focus is on throughput rather than on resource utilization. Resources being idle in Non-bottleneck process steps are pretty normal.
3. An Experienced team is required to identify the optimal WIP limit for each process step.
4. Near to zero slack or float. Due to this, the team members cannot engage in recreational activities like learning, retrospectives, team building, product demo, and other good practices. With the lean and Kanban, the slacks are gone. A long list of work lined up with no end in sight: just work, work, work.
5. A strong drive for continuous improvement is required.
1. On-demand scheduling is a flow-based scheduling technique. Not iteration-based.
2. Kanban agile methodology uses on-demand scheduling.
3. Cycle time of the bottleneck process step is needed to develop the schedule.
4. Cycle time is the time required by a process step to complete a unit of work.
5. Throughput is about how much work can be done for a given time window. Rate.
6. Throughput = Time window / Bottleneck process’s Cycle time
7. Cycle time is inversely proportional to throughput. The smaller the cycle time, the greater the throughput.
8. The number of in-progress items permitted in a given process step is called the WIP limit.
9. WIP limit and the throughput are inversely proportional. The smaller the WIP limit, the greater the throughput.
10. Little’s Law states that the more things you have going at the same time, the longer each thing will take.
11. Little’ Law equation: Cycle time = Number of items in WIP / Throughput.
12. Metric velocity is not used in on-demand scheduling but in iterative scheduling.
13. On-demand scheduling works well if the work packages or of even size. Otherwise maintaining stable cycle times is not possible.
14. Kanban board and Kanban methodology are not the same.
15. Kanban is an agile methodology based on workflow. Whereas the Kanban board is a tool used to visualize the workflow.
16. Kanban board and task board are not the same. Kanban board shall have WIP limits and work based on the pull mechanism. Task boards don't have WIP limits and work based on a push mechanism.
17. Setting the WIP limit to 1 is not a good idea. This will lead to production stoppage and affects resource utilization.
18. Having more items in WIP is also a bad idea. It affects throughput.
19. Setting the WIP limit to 0 is not an option.
20. With the lean and Kanban, the slacks are gone.
© 2022 by EZBRAIN EDUTECH PRIVATE LIMITED. All rights reserved.
Copyright and License to use
This blog is the intellectual property of Ezbrain Edutech Private Limited. Readers can use it for their individual learning needs and share it with others for personal use. It is prohibited for other companies and legal entities who intend to use this blog for training purposes or to benefit themselves, their clients, and customers in any possible way. To republish or reproduce our content, you must obtain our written permission.
The views, facts, and opinions expressed in this blog are based on the author's professional experience, beliefs, and facts collected from reference materials mentioned under References and citations. We did our best to ensure the content's correctness to make it reliable. Learnings from this blog help the learners, in general; however, we neither guarantee this blog will make the learners clear any project management certification exam nor its correctness. We are not liable for any consequence of applying this blog's learnings and advise readers to do things at their discretion.