Scrum vs Kanban - What's the Difference? + FREE CHEAT SHEET

if you found this video the chances are you've just done a search for the difference between scratch okay well you've come to the right place not only do I have a great video for you I also have a cheat sheet for you to download hi this is Gary welcome to development that pays we've got a ton of stuff to get through today so let's get straight at it scrum and Kanban or perhaps the best known of a whole range of agile software development methodologies 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 the customers and fed back into the process it's the product owners job to take input from customers and from other stakeholders and to organize it into a prioritized list of features and user stories this list is known as the product backlog now 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 and it's this person's job to help the product owner and the 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 select that scrum and Kanban have in common is that both of pull systems without getting into too much detail the pull system ensures that work gets from product backlog the customer in the shortest possible time the pull system also helps to uncover a bottlenecks in the process which helps to ensure that work gets from product backlog to the 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 teams work in a series of sprints most commonly two weeks in duration each sprint is preceded 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 believed it could commit to delivering in a single sprint this is the poll 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 crop up have to wait for the next sprint it's common practice for scrum teams to use a board to track the progress of work it's called a scrum board or an agile board or even slightly confusingly Kanban board each day during the sprint there's a scrum meeting it's a standard meeting where the team takes a maximum of 15 minutes to discuss progress and to identify any blockers at the end of the sprint the work completed during the sprint is packaged for release 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 the stakeholders and the Sprint retrospective which is an examination of what went well what went badly what can be improved the aim of the retrospective is to ensure that the next sprint is more efficient and effective than the last and that scrum Kanban does a few things differently there's no two week sprint Kanban is a continuous process and of course there's no sprint backlog the pull system in Kanban happens in a different way via work-in-progress limits 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 would set a limit between two and four items the lower the better let's see the pole system in action when testing of a particular feature is complete the corresponding ticket moves to the done column the empty column is a signal to the previous column to send another ticket that's the pole similarly when the build column is almost empty it's a signal to the dev team to select another high-priority item from the backlog that's the pool again Kanban has a number of rituals in common with scrum although the naming is slightly different daily stand-up meetings demos for stakeholders and retrospectives so now you know the difference between scrum and Kanban two important things to say at this point first thing neither scrum nor Kanban are as prescriptive as I may have made them appear high-performing teams discover what works for them and flex the system accordingly secondly I've put together a cheat sheet for you that covers everything that we've talked about today plus an additional note that I think you will find useful you can grab a copy from my blog via the link that you'll find somewhere around this video if you like this video please click to like share it with your colleagues and be sure to subscribe for a brand new episode every Wednesday thank you very much for watching I look forward to talking to you again very soon Cheers [Music] you

Channel: Development That Pays

Views: 1,221,747

Rating: 4.9438725 out of 5

Keywords: Difference between scrum and kanban, Difference between kanban and scrum, scrum vs kanban, kanban vs scrum, kanban, scrum, scrum kanban, agile, Development That Pays

Id: rIaz-l1Kf8w

Length: 5min 31sec (331 seconds)

Published: Wed Jan 18 2017