Scrum vs Kanban - What's the Difference?

Scrum and Kanban have much in common - and some striking differences. Watch the video... and grab your FREE CHEAT SHEET.
= = = = = = = = = = = =
New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"
→ www.developmentthatpays.com/w...
= = = = = = = = = = = =
Download your FREE CHEAT SHEET: www.developmentthatpays.com/c...
If you've been wondering about the differences between Scrum and Kanban, you've come to the right place.
Scum and Kanban are perhaps the best known of a number of Agile software development. They have much in common - and some striking differences.
And don't forget to grab your copy of the Scrum vs Kanban Cheat Sheet.
Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186
-------------------
68. Scrum vs Kanban - What's the Difference?
#ScrumVsKanban #AgileScrum #Kanban #DevelopmentThatPays
Scrum and Kanban are perhaps the best known of a number of Agile software development frameworks. Let's break that down: Software Development, in very broad terms, looks like this: The Product Owner decides what to build, The Development Team builds it, and Customers use it, experience it, benefit from it in some way. What makes software development Agile is that value is delivered to the customer in small increments. And - importantly - feedback is gathered from customers and fed back into the process. It's the Product Owner's job to take input from customers - and from various Stakeholders - and organise it into a prioritised list of features and User Stories. The list is known as the Product Backlog. What happens between the Product Backlog and the Customer is what distinguishes Scrum from Kanban. As we'll see, each has its own routines and rituals. It's this person's job (see below) to help the Product Owner and Development Team to adopt and maintain good habits. In Scrum, the role is known as the Scrum Master. In Kanban, the role is known as the Agile Coach. Something that Scrum and Kanban have in common is that both are PULL systems. Without getting into two much detail, a pull system ensures that work gets from Product Backlog to Customer in the shortest possible time. A pull system also helps to uncover bottlenecks in the process, which helps to ensure that work gets from Product Backlog to Customer in the shortest possible time! As you'll see in a moment, Scrum and Kanban implement the pull system in two strikingly different ways. Scrum ---- Scrum teams work in a series of Sprints, most commonly two weeks in length. Each Sprint it proceeded by a Sprint Planning Meeting, run by the Scrum Master and attended by the Product Owner and the Development Team. Together they select high priority items from the Product Backlog that the Development Team believe it can commit to delivering in a single Sprint. This is the "pull" I was talking about earlier. The selected items are known as the SPRINT BACKLOG. For the next two weeks, the Development Team focuses on working through the items in the Sprint backlog - and ONLY those items in the Sprint backlog: in all but the most exceptional circumstances, any new requirements that arise have to wait for the following Sprint. It's common practice for Scum teams to use a board to track the progress of the work. It's called a Scrum Board... or an Agile Board... or even (slightly confusingly) a Kanban Board. Each day during the Sprint there is a Scrum Meeting: it's a stand up meeting where the team takes a maximum of 15 minutes to discuss progress and identify any "blockers". At the end of the Sprint, the work completed during the Sprint is packaged for release, and any incomplete items are returned to the Product Backlog. The Sprint ends with two rituals: The Sprint Review, which is a demonstration of new functionality to Stakeholders. The Sprint Retrospective, which is an examination of what went well, what went badly and what could be improved. The aim of the Retrospective is to ensure that the next sprint is more efficient and effective than the last. And that's Scrum! Kanban ----- Kanban does a few things differently. There's no two-week sprint: Kanban is a continuous process. And there's no Sprint Backlog; the "pull" system in Kanban happens in a different way, via Work In Progress (WIP) limits. If an Agile Board is useful for Scrum, it's a necessity for Kanban. Each column on the Kanban Board has a Work in Progress limit related to the team's capacity. For example, a team with two developers might set a limit between two a
• Scrum vs Kanban - What...
www.youtube.com/watch?v=https...

[@Kajerman]

After watching this and the "Scrum Vs. Kanban" videos I've probably learned more in these past 20-25min than I did an entire semester. Amazing what a good teacher can do with the help of some great animations. Thank you, sir.

[@Developmentthatpays]

What a lovely comment. Thank you - very much appreciated.

[@ireshrie]

It is indeed. Much better than the extensive reading materials. Well done! It has higher retainability. :)

[@Developmentthatpays]

+Iresh Rie Dacian - 👍

[@SoniaSharma1107]

I totally agree. Thanks for posting such a wonderful video.

[@Zabalero]

All this stuff is turning simple things into intrancate and complicated stuff through the use of buzzwords.

[@nickfifield1]

who on earth is giving this video a thumbs down? As an agile coach and scrum master, i can say it's short, sweet and very clear. great work!

[@Developmentthatpays]

Thanks, Nick. You just made my day! 👍👍👍

[@blinkymon]

I'm guessing they're from the designers who are always left out of any explanation of agile methodologies and who have to put up with clueless delivery managers, scrum masters, product owners, etc. who've never worked with designers before and don't know where they fit into these methodologies. :) I'm just speculating, tho.

[@chrisweaver7989]

Probably devs and the people who implement the work. I have recently been looking into these systems and been talking to various people seems like the scrum master is a bit of a voodooo subject in itself :O.

[@changnoiboi]

Effing idiots are.

[@randomgrinn]

Did not answer my questions on why my pee goes in 12 different directions, so I was forced to give it a thumbs down.

[@Developmentthatpays]

This video (thanks to some unexpected file corruption issues) took some late nights and some early mornings to put together. I hope you like it, and I look forward to reading your comments.

[@theivam123]

You really deserved it !!!

[@cameronhay7040]

It's excellent! Really clear! Thank you for making the effort!

[@beenmicrophone5817]

absolutely fantastic video! subscribed 👍👍

[@NomanKhan-pj3qx]

Awesome video. thank you very much its really helping me in my work. again thank you.❤️❤️

[@arslanbadr6865]

Have a retrospective meeting with yourself then :D great stuff!

[@pickledparsleyparty]

This was really, really good. Not a second wasted, extremely easy to follow, and feels like it's pretty much a complete "talk the talk" lesson. Perfect.

[@Developmentthatpays]

Very nice of you to say so! Much appreciated.

[@OgniiDev]

Incredible tutorial. I used to love SCRUM and the name Kanban was interesting to me. However the process of Kaban seems more interesting.

[@konatsume2351]

I work as a Product Analyst and I can confirm this video outlines everything you need to know when differing between Scrum and Kanban I watched this video with my mother and explained along the way how it all works, your examples and visuals were very helpful!

[@Developmentthatpays]

Awesome comment. Thank you!

[@omarfessi2761]

I have worked with both approaches, after coup, watching this tutorial enforces perfectly what I've learned from both of them and gives me more confidence explaining to people why it was better to use what it was decided to be used. Thanks bro

[@nicholasbrown6394]

Awesome content, between this and the mini series kudos to you! All of my colleagues just received training on Agile + Scrum so it was up to me to educate myself. (since interns don't go to those cool workshops!)You definitely smoothed out the bumps in the road with the flawless story telling.

[@Developmentthatpays]

Thank you!

[@alichi7896]

I love how you are clear and explained everything simply

[@arijitmahalanabis8001]

This is by far the best, most clear identification of Scrum & Kanban & their resulting difference, & I admire so much is because of the little span of time within which the video encapsulates all this... Beautiful work @DevelopmentThatPays team & the narrator

[@Developmentthatpays]

Thank you so much. I'm delighted you liked it!

[@adityanambyar7]

Thank you for such a brief and near-perfect explanation! I can't believe you covered all the essentials of scrum in less than 4 minutes. Great work!

[@Developmentthatpays]

Glad you enjoyed it!

[@pk61435]

Your videos on Scrum and Kanban are a top quality explanation. Great content and a great job fitting all the information in a short video, thanks!

[@Developmentthatpays]

Petro, that's very nice of you to say. Thanks you so much.

[@dejountaewashington3874]

By far the best description I've come across thus far. I had never even studied Kanban prior to this and got it almost immediately! Great job with this one.

[@Developmentthatpays]

That’s awesome. Really glad you like it!

[@stuwmcclure]

This was an exceptional video (and I watch hundreds each week)! You were clear, fast, and precise. You have an excellent delivery demeanor. Thanks so much, I will share this with the many Teams I work with...

[@Developmentthatpays]

Wow, thank you! Very nice of you to say so.

[@natashaelliott8764]

Finally I understand the key differences between these 2 Agile methodologies! This is the best video ever on this topic! Keep up this great work! Thank you!

[@Developmentthatpays]

Natasha Elliott - Thank you so much!

[@tlingit]

That's the clearest explanation of both Kanban and Scrum that I've yet seen. Thank you. Liked and subscribed.

[@Developmentthatpays]

Awesome, thank you!

[@georgetirim5282]

2020 and this still is one of the best videos to learn agile development. Thanks for your contribution!

[@Developmentthatpays]

Wow, thanks! You made my day!

[@MioYTonline]

@@Developmentthatpays Still amazing in 2023, thx for the vid

[@Developmentthatpays]

@@MioYTonline - Thanks for making my day!

[@alex_chugaev]

Literally the most clear explanation! Thank you ❤️

[@petardjordjevic7714]

This video is great, all I needed was a rough idea, now I can start learning more about this.

[@dukeiweh9232]

This is the best explanation of differences I have seen! Clear and simple. Thank you

[@Developmentthatpays]

Glad it was helpful!

[@ezekielfrranks1314]

I can definitely agree on that last point. Over time your Kanban/Scrum process(es) will naturally evolve and may even borrow from both Scrum and Kanban. Excellent video!

[@Developmentthatpays]

Agreed: each has something to learn from the other.

[@johnhealey5805]

Great job and teacher. I appreciate this gift you have.

[@r.walid2323]

Thanks for the explanation, as well as the attached sheet.

[@deeptisachan6559]

I bet this is the easiest demonstration of Scrum vs Kanban on YT, which was short and crisp with covering every point. Thanks a ton for the amazing video and CHEAT SHEET.

[@Developmentthatpays]

I'm delighted that you found it to be useful 👍

[@runybrydges3953]

Thanks for breaking it down am new to project management and this is so helpful! Already shared to my course mates 👏🏽

[@Developmentthatpays]

Excellent! Glad it was helpful 👍

[@bris.e]

What an amazing explanation. Easy and concise. Thank you for putting this info together!

[@Developmentthatpays]

You are most welcome. Glad you liked it!

[@sebastianchomiakow6091]

Literally THE BEST explanatory video I have ever seen. Straight to the point with all information easily broken down. Terrific!

[@Developmentthatpays]

How has it taken me 2 years to find this lovely comment. THANK YOU!

[@diogeneslantern18]

18 January is my birthday. I wish I had watched your content when I was starting out with my business :) it is a treasure trove of great info

[@estefmendiburu4200]

I am not related to Product Management at all! However, I do have to recruit product owners and I have to dive a bit into the skills /experience required to place the correct questions. This was so clear and so well put together, that I honestly feel more equipped to interview these kind of positions. I additionally learned a lot about Scrum/Kanban today :) Thanks!

[@Developmentthatpays]

That's awesome!

[@chengrace8701]

Incredible tutorial. Wonderful. Good job.

[@puliranjit]

such a short , simplified and perfect way to summarize the differences ...Kudos to the author!

[@Developmentthatpays]

Thank you! Glad you liked it 👍

[@blessidunion]

Best video on this subject on the Internet. Suddenly after 20 videos on the subject I get it. Completely.

[@jsrrrmg]

With a Kanban system, there should be virtually no "Backlog" a.k.a. "Buffer". That is one on the major purposes of having a continuous 1-Piece-Flow system.

[@MaxwellSmartA86]

I'm a huge fan of your teaching methods. If I may ask...what do you use for the animations? Learning this skill would help me teach my team and colleagues. Thank you for doing these!

[@Developmentthatpays]

+Chris Carmichael - That's nice of you to say so!. Re. the animations, I'll get around to doing a video on this at some point. In the meantime I hope this is helpful: I occasionally use Apple Motion, but 95% of the time I use Apple Keynote. And much of the animation uses Keynote's Magic Move transition. (I believe PowerPoint has a similar transition.) I make all of the transitions slow, export the entire presentation to QuickTime, then edit the visuals to the audio in Final Cut Pro.

[@jorgerosaljr]

I'm trying to understand the scrum concept for hours but got some confusion. But your 5min video saves me a lot of headaches. Concise, direct-to-the-point, and very informative. Thank you.

[@Developmentthatpays]

Great comment! I'm glad you liked the video.

[@TrekkingKaiser]

Great, thank you! Perfect editing and visualisation of information. Quick, highly informative and convenient.

[@Developmentthatpays]

Thank you! You just amde my day!

[@Dwavard]

Great pace, v clear, thank you for uploading this :-)

[@Developmentthatpays]

Thank you! Glad you enjoyed it.

[@GeaVox]

Oh joy! An English voice, at LAST! Proper speech, properly structured explanation!

[@Developmentthatpays]

Why thank you. Awfully decent of you to say so :)

[@GeaVox]

I really enjoyed your tutorial. Merry Christmas and a Happy 2018!

[@Developmentthatpays]

Thank you!

[@zootius]

I thought you were Welsh though ;)

[@jamesmarwood3146]

That's a North East English accent, some similarities to Welsh but different.

[@satheshkumark5837]

Loved it.. especially pull.. difference in scrum and kanban

[@ahimsadesi]

Such a great overview video with helpful graphics. Thank you.

[@nathancarnelos]

where i work they say we use scrum but, rely we use both, we do daily meting, retrospective, 2 week sprint and when the TO DO list is done we pull from the back-log lol

[@krukd1mka]

Scrumban

[@cleversonsutil4495]

Agreed! And if the task is not completed in the sprint, we move it to the next.

[@marmanlive]

Good shot, thnx much, really defines well enough!!!!

[@Developmentthatpays]

Thank you!

[@prabhanshusaraswat7579]

Very crisp platter in many many videos on youtube. Thanks for building such a short but valuable video.

[@Developmentthatpays]

You are most welcome! 😊

[@talisman_tv5221]

great video. in my team some people call our approach as Scrumban. But its just regular scrum with Kanban board, nothing else

[@AlexandraBondareva]

Great video! one thing - I think scrum is not a methodology, it's a framework. And not sure if Kanban has such things as standups, as it is coming from Extreme Programming. Is it dictated by Kanban that it should be a part of the framework, like daily scrum in Scrum?

[@Developmentthatpays]

You're right, you're right: it's a framework not a methodology. I'm not sure about what Kanban dictates: Kanban isn't as "codified" as Scrum. For what it's worth, I can tell you that every Kanban team I've been a part of does a daily standup.

[@AnLAdCearbhaill]

@Flat Iron Silly question friend

[@vd853]

Animations are helpful in memorizing these stuff.

[@Developmentthatpays]

Glad you liked the animations!

[@ayeshapanchavi8093]

One of the best videos to learn the difference between Kanban and Scrum just in 5 minutes. Thank you for creating this video and sharing with us ❤ Cheers! 🎉

[@Developmentthatpays]

My pleasure!

[@techseeker76]

Brilliant!! Short, crisp & precise. Well presented too , well done!!

[@Developmentthatpays]

Thank you!! 👍

[@NitinSharma-ly9so]

Correction at 2:40, ones the sprint backlog has been created and a requirement comes up, the product owner can discuss with the dev team if they can accommodate the requirement in the current sprint.

[@Developmentthatpays]

You're... correct!

[@sacharora5265]

This is correct, that PO can present the new requirement and let team judge if they want to work in current sprint or leave it for next sprint. Alternatively, it is new, urgent and management wants it as done yesterday - then option is to replace something from current sprint to accomodate immediately. Here SM role is support team, push the new thing to next sprint or get something removed to accomodate new item. Otherwise, team will be under pressure.

[@abduvosidmalikov]

Indeed a very useful video, thank you! I've got a question: one of the clearest differences between Kanban & Scrum is that in Kanban, Items are “pulled” directly from the Product Backlog to the Kanban Board. But in Scrum, only selected items are pulled from Product Backlog to the Sprint Backlog (intermediary) first and then pulled into the Agile Board. In Kanban, do teams ignore Prioritazation because there is no intermediary like Sprint Backlog? Isn't this bad? In Kanban, while pulling items from Product Backlog to Kanban Board how do teams decide which items should be pulled/developed first, how do they give priority to tasks? Or do they develop tasks randomly, in any way they want?

[@Developmentthatpays]

What an awesome question! Scrum teams ask the question "what are the next things we should work on?"; Kanban teams ask the question "What's the next thing we should work on?" This means that - for a kanban team - the top of the product backlog must be carefully ordered. Some teams add an additional column - between the backlog and Dev - often called "ready". It contains a limited number of ordered items. The Ready column can - and should! change at any time. Does that make sense?

[@abduvosidmalikov]

@@Developmentthatpays thanks, it really does. Awesome answer. I can see that in Scrum, we are interested in taking itemS in bulk (thingS) from Backlog while in Kanban we take the most important item from the top of the Backlog. (am I right?) Another thing is: what's the difference between that "ready" column and the DONE column in Kanban Board?

[@Developmentthatpays]

You're right... although I'd say it differently. One of the problems that agile helps us with is the (very human) tendency to work on too many things at the same time. Scrum says "work on a strictly limited number of items"; Kanban says "work on just one item". The Done column is the final column; the Ready column (if present) is the first column (after the backlog). Take a look at this (section of) video for more on this: kzbin.info/www/bejne/nJi3ZXSXgMh1i6M

[@abduvosidmalikov]

@@Developmentthatpays every time you are answering me I'm extracting something new and the knowledge is building up. when you said "Ready" column, you meant Ready to BE DEVELOPED (not Ready to BE RELEASED, as I wrongly understood it), am I right? Scrum says "work on a strictly limited number of items" => while Kanban's READY column is more flexible. Scrum's Sprint Backlog is something that is STRICT/CLOSED while Kanban's READY column can change at any time.. yeah?

[@sacharora5265]

@@abduvosidmalikov No, Ready means that the item is reviewed and is ready for team to take on when next Build or Active column is having space or limit available in queue. May try to elborate which will help whats in video - To Do - backlog or items in bag which a team needs to work. (RAW, may be not in order or sequence). As there is NO PO, so team is best to judge what to pick next (worst thing I feel (as Agile Coach) while working with KANBAN teams) Build - Here team is working on some thing, what this means that they have discussed and understood what is asked for and they know how to deliver it. Done / Completed / Closed - when the work is all completed and released for end user to test and enjoy this piece. Ready column - it fits between To Do and Build column # Ready column helps when a lead is looking on new things or backlog items brining them in sequence so that team can pick immidiate available next item in queue. So team knows that what is next thing they need to work on - similar to Scrum approach you can say. Here Lead is acting as virtual PO for team. @Development That Pays - please add/correct above if sounds going here n there :) as I am still learning Kanban coaching

[@abdullahkamil8041]

this more comprehensive than lecture class! thank you :3

[@setsunaes]

I ADORE you, I have to present a paper about those agile methodologies and this video gave the punch my dull paper needed to become a great work. Thanks.

[@Developmentthatpays]

What a cracking comment! Glad to help!

[@ds-nb4ln]

There are several suggestions for how to pass the Asvab test Take a rest Don't get too stressed about it Look at some example exams online (I discovered these and why they work on Wilfs Exam Blueprint site )

[@makeitbetter9685]

When are demos and retrospectives usually performed during Kanban? It was mentioned that Kanban is a continuous process and doesn't have sprints, does that mean that demos and retrospectives are done everytime something is ready to be delivered to the customer?

[@Developmentthatpays]

It is trickier in kanban, as there's no natural "trigger". Holding a demos and retros at each release would be (potentially) much too frequent. It's up to the team to decide when to to hold demos and retros. (And yes, there's a danger than they won't happen often enough.)

[@ClintonVincen]

In Scrum: Is there a guideline as to who(developers) owns the items in the sprint backlog, or is that at the discretion of the development team ?

[@Developmentthatpays]

It's very clear: the Product Owner owns the Product Backlog. But that doesn't mean that she is all-powerful. Here's why: it's the Development Team that gets to choose the items for each Sprint (the Sprint Backlog). And the team is not obliged to pick the top-most items.

[@odiewan67]

In my team, each developer usually is expected to pick their own stories, unless the PO or the SML has a preference

[@alexm4694]

Awesome video! Concise, simple to follow, and incredibly effective. Thank you!

[@Developmentthatpays]

Thank you! Great comment!

[@allourlips]

Very clear succinct description and explanation. Honestly as a certified CSM and CSPO I did not truly understand the variations between the two. I am aware of Continuous iterative integration and the like but this video made things crystal clear… THANK YOU!

[@Developmentthatpays]

Cyrus Mody - That's a huge compliment. Thank you!

[@Developmentthatpays]

Cyrus Mody - That's a huge compliment. Thank you!

[@user-mb4xy2cz3t]

Ah, good ol daily meetings, the most hated thing ever. Sadly, the systems were not designed to help developers, they were designed to help micromanage the devs.

[@Developmentthatpays]

I was going to disagree with you... and then I saw how many times your comment was up-voted!

[@drawmaster77]

we always have few engineers who just love hearing themselves talk, team is also very large so their domain is different from others and nobody understands what they are talking about, it's so frustrating!

[@alexgehales]

@@drawmaster77 The secret to avoid this issue is to set time limits and rules in how feedback can be given. Anything that is outside can be taken offline.

[@julianb4157]

If all devs are awesome, they need almost no management, and these meetings are either unnecessary or very fast. Back in the real world, that's not the case. Sadly, some devs are bad (inept, slow, lazy, whatever). Those ones need more managing - it's rarely as simple as "fire them and get better ones." Any methodology that can only work if all the team are way-above-average is seriously flawed. On average, a chunk of the team will be no better than average. Hence the need for these kind of meetings. If the team's good, they don't need or get micromanaged by a decent manager. If there's micro-managing, either the manager or the team are problematic - and it's not always the manager at fault.

[@k.g.8503]

Why would anyone be micromanaging at dailies? I mean, anything you use incorrectly can be blamed for not working.

[@Yetipfote]

0:00 tbh I came to this video to learn about how to cook cup cakes.

[@saswatibhattacharjee4992]

kzbin.info/www/bejne/fnnQZ5uwra2jsLs

[@Michael-ed5fs]

Thanks a lot, Gary, wonderful explanation, accurate and concise! And that British pronunciation really rocks :)

[@Developmentthatpays]

You are very welcome. Glad you liked the video... and the accent 😀

[@user-sz1tc2xi2d]

excellent presentation in finest way

[@thought-provoker]

Two years late to the party, but a few comments. There are a LOT of misconceptions and dangerous oversimplifications in the video. Non-exclusive listing: * the role of the Product Owner is exclusive to Scrum, although many non-Scrum team use it as well. It's NOT an "Agile" thing. * the role of an "Agile Coach" is not defined in Kanban - how the role is defined in an organization varies widely. * a key difference between Scrum and Kanban is that Scrum suggests a single team to have end to end process responsibility, whereas Kanban is neutral to the idea that there could be handovers in the process. * Some Scrum teams not only use Kanban boards, but embed Kanban as their method of delivery. Therefore, it's not "confusing" at all when they talk about having a Kanban board. * There's nothing in Scrum that forces having a single Release at Sprint End. Many Scrum teams find value in Continuous Delivery/Deployment. * Kanban's WIP limits should not only be on individual activities, but on the Value Stream. There's no value in generating WIP that doesn't get processed in a timely manner. * One of the key principles in the manifesto for agile software development is daily collaboration between developers and "the business" (i.e. customers). The initial diagram is dangerously oversimplified. If developers don't interact with customers but only deliver what they think solves the backlog item, the result is usually low quality. * The way the arrows in the initial diagram look like, this is still a PUSH process, not a PULL process. In a pull process, the arrows would be reversed. * It's not called a "ritual", it's called "event" in Scrum - and Kanban prescribes none of them. * Kanban is basically a set of principles (such as evolutionary change, customer centricity and self-organization) as well as practices (such as flow management and making policies explicit) that are entirely ignored in the video. Sorry for the harsh critique, but I feel Kanban is entirely misrepresented and the proposed differences between the two frameworks could lead teams to decide for an approach under false assumptions. Here are the key differences: Scrum = build an effective team. Kanban = create an effective delivery process. That's why you can choose none, either or both.

[@Developmentthatpays]

I'm broadly in agreement with you. The video was never intended to be a tutorial: it was more about "documenting" real-life teams... making real-life mistakes. Having said that, I'm aware that (a) the video has become popular and (b) there is a danger that people are being misled. At some point I'm going to do an "Everything wrong with..." video - and I'll borrow heavily from your comment! Thanks again.

[@martineyles]

Is there a way to download the cheat sheet, or must I "pay" with my email address?

[@Developmentthatpays]

Yes, you do need to enter your email address: that allows me to send you a new version when it's updated. (It's already been updated multiple times.)

[@steveabiola447]

@@Developmentthatpays Can you please send me the sheet too? Thanks

[@titusmulumba314]

I have learned a lot in quite a short time. Thanks a lot for the video.

[@1m1r0z]

Truly excellent and succinct. Better than any similar video I've seen on KZbin in every way, especially because it's accurate and saves time. Thank you.

[@Developmentthatpays]

Thank you! Very nice of you to day so. 👍

[@xen2297]

Aaaand here's a video that does in 5 minutes what a thousand blog posts have not done in a decade.

[@davidroberts3152]

Scrum isn't really a pull process because it doesn't typically prescribe pulling across activities. E.g. Code to Test. Typically when Code is complete it is pushed to a tester.

[@Developmentthatpays]

Two things: 1. It's common practice (as you point out) for devs to push to Test. That's always struck me as unfair: the devs get to pull from the backlog; why should they have all the fun? The Test team should be given the same consideration. All it takes is another column (or a buffer zone) on the Agile board . 2. If you zoom out a bit - and view the tech team as a whole - the pull becomes more evident.

[@TraveltasticGuideToTravel]

This is some interesting stuff, who knew your work life could have such an impact on this

[@prabhumishra3323]

This was an eye opener on this concept. Thank you

[@covelus]

good video, but those noises are annoying, I would avoid in following videos ('Bottleneck traffic signal' and 'Important')

[@Developmentthatpays]

I have been guilty of over-doing the noises in the past. Thanks for the feedback.

[@DudeWatIsThis]

In my team, we simply use a mixture of boths styles, with longer sprints, and minus the cult-like stuff :D

[@elontrudeau]

Best video out there I have found, and you nailed it by saying you can adapt these processes for your business needs. Too many companies force a text book approach on these systems believing it will work and can cause more problems and push people to quit their jobs. It's a framework not doctrine.

[@Developmentthatpays]

"It's a framework not doctrine."

[@dave_cj]

Very good video with great efforts on the graphical representation. Thank you!

[@Developmentthatpays]

Really glad you liked it!

[@TheShadowless]

Scrum: What’s the difference between me and you? Kanban: I bought 5 bank accounts, 3 ounces and 2 vehicles.

[@Developmentthatpays]

?!?

[@dmitrydanilov3417]

Waterfall: Until my death, I'm Bangladesh

[@nithyavasudevan3822]

@@Developmentthatpays Dr.Dre song

[@IoDavide1]

This method look like the method adopted the day after Turing invented the computer... I really cannot find anything new...

[@Developmentthatpays]

OK. (Did Turing invent the computer?)

[@IoDavide1]

Development That Pays sorry for my comment, but it seems a very ordinary developing method, never heard something different. Yes, he did.

[@OlufemiOlajiga]

A perfect mix of Scrum + Kanban = ScrumBan which works perfectly for Agile marketing teams

[@MrSuriyam]

Thank you for the summarized video.

[@Developmentthatpays]

My pleasure!

[@antoniog9814]

Scrum & Kanban are NOT methodologies. They are frameworks. Agile is the methodology and Scrum & Kanban fall under it.

[@genpowernow]

You're right, you're right. When I made this video, I wasn't aware of the distinction: I've corrected this in more recent episodes - and in my Mini-course.

[@MrKieranthompson]

Agile is absolutely not a methodology as it follows no strict guidelines, it is to be used and adapted to the specific requirements of the business owner and the customer. Scrum and Kanban fall under the methodology convention as they have specific guidelines in place that distinguish them from other agile methodologies.

[@Developmentthatpays]

I guess it's a matter of degree: there's plenty of "wiggle room" in Scrum and (especially) Kanban.

[@LukePighetti]

Kanban existed long before software development, so it cannot be a subset of agile software development.

[@mig25foxbat]

Well, it was developed at roughly the same time - the 1950s. But of course it can be used as a subset of Agile. The computer is a subset of "internet connected devices", yet computers existed before the internet...

[@sacredgeometry]

This is absolutely incorrect. Agile tells you literally nothing about process its just a set of values. No matter how many times the people who wrote the manifesto say this there will always be people who don't understand it.

[@Developmentthatpays]

I really do need to do a video or three on the Agile Manifesto.

[@m.f.8752]

Great explanations for both. Thank you. Explained simply and without top-heavy graphics.

[@Developmentthatpays]

You're very welcome!

[@JaydenLawson]

Thanks for the video! Not sure which to use but will consider both!

[@azraeljudahbenisrael]

FRAMEWWORK! not Methodology

[@Developmentthatpays]

I know, I know. I'm ashamed of myself. 😱

[@linkinparkroxx]

@@Developmentthatpays Whats the difference?

[@ademtepe2855]

Wow, it has been only 1 and a half minute and it has already proved that it's the best content I've ever watched on the subject.

[@Developmentthatpays]

THANK YOU. Lovely comment!

[@kaikiatong7684]

After watching so many videos and reading so much, this video gives me the clearest picture of Scrum and Kanban.

[@Developmentthatpays]

Lovely comment - THANK YOU!

[@CarlosMGomez]

Excellent video, it is a pleasure to share it... just a little question, Do you have another link to the cheet-sheet? the description link is broken :(

[@suresh1957]

Short, succinct and to the point. Overjoyed that I somehow stumbled upon this video. Thanks once again. Suresh/ Strasbourg, France

[@Developmentthatpays]

Merci!

[@michaels.8058]

The 'OnTime' tool looks like a great product for project management. Great video! *thumbs-up*

[@Developmentthatpays]

Is that the Axosoft product?

[@afaf6478]

Oh man, i found your channel and I LOVE your videos

[@WorldadventureswithLauraTrent]

Had no idea what it was, learnt a bit thankyou.

[@ronh2660]

well presented. most materials have much too granular definitions, which makes near impossible to truly understand the 'why'

[@SaiKiran-lp2iw]

Such a wonderful explanation. It was crystal clear... The notes provided at the end is much helpful

[@Developmentthatpays]

Really glad it was helpful!

[@danecustance2734]

Thanks. Great explinations which are very clear and easy to follow.

[@Developmentthatpays]

Glad you liked it!

[@faridjabbouritcs2517]

Great Amazing animations and Teacher. 5 minutes made a big difference in my understanding of Kanban and Scrum and Agile

[@Developmentthatpays]

Excellent!

[@ManishChackoATx]

OK seriously-where has this video been the last 2 years? Amazingly simple that even I can understand :). If I had to pick a nit, I'd point out the "cheetsheat" spelling error at 4:58 but I don't want this content to be removed and so I won't mention it :) (because it has simplified Scrum and KanBan to an incredible level, everybody needs to watch it). Seriously guys, good job!!!! 4.95/5 Stars!!!

[@samarendrapatel2040]

Nice video. Helped me in undersanding the difference between Scrum and Kanban in more clear manner.

[@Developmentthatpays]

Excellent - I'm glad it was helpful 👍

[@justwatching2960]

I watched in double speed, so in 2 minutes I understand now what has confused for long time, and couldn't find the answer for. Great video!

[@Developmentthatpays]

Excellent hack!

[@vadrif-draco]

Bruh the sound effects lmao Aside from that, great video.

[@Developmentthatpays]

Yeah...: I was a bit heavy-handed with sound effects back then.

[@alexandarnikolov1272]

Thank You !Only for 5 min. I learned the core of the item!

[@toothache90]

You just saved me from reading a tedious book, thank you!

[@Developmentthatpays]

Yes, those Agile books can be tedious ;)

[@claudiamchang]

So helpful. Which program did you use for the graphic/animation please?

[@anthonyrcaz]

I just reviewed four videos on Kanban to show my teams interested in Kanban. One was gorgeous but bashes scrum. The other was a snooze fest and missed all the key ideas. Your video was the porridge that was just right! I think I communicate better than most, and I could NOT have done it this well, so thank you! I have only one criticism. Your definition of agile at the beginning is actually the definition of iterative, not agile. My favorite quote for this, said by my client Andres Borque: Agile = Iterative + Culture. What makes Scrum and Kanban Agile is the high trust, self-organizing, transparent, collaborative culture. Delivering smaller increments is a part of agile, but it is also a part of iterative (like RUP) even if you aren't embracing agile. Either way, thank you for a great video. I will recommend it be used with the teams at my current client. :)

[@Developmentthatpays]

Just call me Goldilocks! Great comments of the video. Your "Agile = Iterative + Culture" point is just the kind of distinction I love to dig in to. It's on the list for a future episode!