In this lesson, we are going to compare Kanban with Scrum. In a previous lesson I had given an overview of Kanban. In this lesson now that we know more about Scrum we're going to be comparing the two methodologies. In the scrum methodology. We have although it's pretty similar between Scrum and Kanban are pretty similar concepts. But the main difference comes in in the way the workflow works in both systems.

Both systems want to get the work done optimally as quickly as possible with high quality. But this is how Scrum works. As you may have seen in one of the previous lessons also you have a product backlog from the product backlog. You get A sprint backlog and you create you have sprints in and then from the sprint backlog, you pick the the stories that you're going to be working, you start working on the sprint stories. And as you work on the sprint stories, it kind of moves both through the workflow. And then finally you have your sprint deliverable.

So that's that's how Scrum workflow is you start with a product backlog you have multiple sprints for in a release. And for each sprint you you pulled some of the stories from the product backlog and make them as the sprint backlog and then the team starts working on the stories that are in sprint backlog for that particular sprint. As they get done. They move this release towards the done status. And then you typically have a two to four week sprint. And once the sprint is done, you move on Then basically continue the process of getting more stories from the product backlog to make sprint backlog.

So that's that's workflow, let's look at how it is different how combine workflows, different forms come backlog. In combine also you have a product backlog from the product backlog. You don't have a you don't have a sprint backlog because there are no sprints in Kanban basically, you have a continuous workflow in in Kanban. So, you take you basically get as as you have the product backlog stories directly into your workflow, and you start build QA done are, you know, maybe code review, what have you as as the as part of your workflow steps if you will. Now, the important difference. One is there's no sprint, so there's no sprint backlog.

So it's it's a continuous process the other important differences konban basically sets a limit of how many stories can be done in a particular workflow. So in this case, basically, in this example, this again, this is just an example this, you can have different limits. But in this particular example, the build status can only have two stories, the QA status can only have one story, and so on. So what happens is, initially, you pay two stories in the build workflow. They're not going to move to the end, you're not going to move more stories in the belt sense that maximum limit is set to true. We're only going to pull a story into the belt workflow.

He only if this this quantity of stories in the bell workflow gets less than two. Then the next one is QA. You're not going to complain Moving a story in QA if there is already a story, because the limit is one. So if, if the if that particular swim lane, or if that particular workflow status has the maximum number of stories already in there, you're not going to pull in other story. As the stories get completed as the story number two is QA, it moves to done status, and then it automatically pulls one of the stories from the bills, build workflow status, and start the QA starts working on that. And also now, since a QA has moved one of the stories from the base and workflow status, their workflow status has has now only one story so it pulls another story from product backlog.

So this is a continuous process. And this is how the deliverables of that so one important question is where typically, you employ a con bond workflow as compared to Scrum workflow, typically Kanban can be used in projects or processes like, you know, support tickets, for example. So this may be kind of your support ticket backlog, and you have your your team set, if you will, for building QA, if you will. And then basically, you're constantly pulling from the support backlog or the support product backlog. So that's one example of where you can use this type of workflow. So hopefully this makes it very clear.

You know, the difference between Scrum and Kanban and where these workflows or these methodologies are typically employed. Kanban is also used quite a bit on assembly lines as that is also a continuous process, if you will. So that's that's another place where you use combine. For example, Condor actually started from Toyota matured as assembly lines, if you will. And, you know hence and Kanban is is a Japanese word. If, from one of the previous lessons you need a member, that it's stands for the board in Japanese so it's something that basically is visual and providing you some visual cards etc.

To give you a visual sense of where things are