Kanban Vs Scrum - QCon San Francisco 2021
Kanban vs ScrumMaking the most of bothQCon, San FranciscoNov 18, 2009Henrik KnibergAgile/Lean coach @ Crisp, und: developer, manager, entreprenuerBoard ofdirectorshenrik.kniberg@crisp.se 46 70 4925284
Purpose of this presentationTo clarify Kanban and Scrum by comparing them.so you can figure outhow these may come to usein your context.Henrik Kniberg2
Split your organizationScrum in a nutshellSplit your productLarge group spending a long time building a huge thingSmall team spending a little time building a small thing. but integrating regularly to see the wholeOptimize business valueOptimize process Split timeJanuaryApril Henrik Kniberg3
Typical ScrumboardHenrik Kniberg4
the unofficialThe bottom lineCore ScrumIf you achieve these you can ignore therest of the checklist. Your process is f ine.These are central to Scrum. Without theseyou probably shouldn’t call it Scrum.Delivering working, testedsoftware every 4 weeks or lessDelivering what thebusiness needs mostProcess iscontinuously improvingClearly def ined product owner(PO)Scrum ChecklistRetrospective happens af terevery sprintResults in concreteimprovement proposalsSome proposals actuallyget implementedWhole team POparticipatesPO has a product backlog(PBL)Henrik KnibergRecommended but not always necessaryMost of these will usually be needed, but not always all of them. Experiment!Team has all skills needed tobring backlog items to DoneTeam members not locked intospecific rolesSprint tasks are estimatedEstimates f or ongoing tasksare updated dailyPO is empowered toprioritizeTop items are prioritizedby business valueIterations that are doomed tofail are terminated earlyPO has knowledge toprioritizeTop items are estimatedPO has direct contact withteamEstimates written by theteamPO has product vision that is insync with PBLPO has direct contact withstakeholdersTop items in PBL smallenough to fit in a sprintPO speaks with one voice(in case PO is a team)PO understands purposeof all backlog itemsTeam has a sprint backlogHave sprint planning meetingsHighly visiblePO participatesUpdated dailyPO brings up-to-date PBLOwned exclusively by theteamWhole team participatesWhole team participatesAll items in sprint plan havean estimateEveryone on the teamparticipates in estimatingPO uses velocity f orrelease planningPO available when team isestimatingVelocity only includesitems that are DoneEstimate relative size (storypoints) rather than timeWhole team knows top 1-3impedimentsSM has strategy f or how tof ix top impedimentSM focusing on removingimpedimentsProblems & impedimentsare surf acedEscalated to managementwhen team can’t solveWhole team believes planis achievablePO satisfied withprioritiesTeam has a Scrum Master (SM)SM sits with the teamTimeboxed iterationsDemo happens af ter everysprintShows working, testedsoftwareFeedback received f romstakeholders & POHave Definition of Done (DoD)Henrik KnibergDoD achievable withineach iterationTeam respects DoDIteration length 4 weeks orlessAlways end on timeTeam not disrupted orcontrolled by outsidersTeam usually deliverswhat they committed toTeam members sit togetherMax 9 people per teamVelocity is measuredPBL and product vision is highlyvisibleResults in a sprint planDaily Scrum happensPBL items are broken intotasks within a sprintTeam has a sprint burndownchartHighly visibleUpdated dailyDaily Scrum is every day, sametime & placePO participates at least af ew times per weekMax 15 minutesEach team member knowswhat the others are doingScalingPositive indicatorsThese are pretty f undamental to anyScrum scaling ef f ort.Leading indicators of agood Scrum implementation.You have a Chief ProductOwner (if many POs)Having fun! High energy level.Dependent teams do Scrum ofScrumsOvertime work is rare andhappens voluntarilyDependent teams integratewithin each sprintDiscussing, criticizing, andexperimenting with the process5PO Product owner SM Scrum Master PBL Product Backlog DoD Definition of Donehttp://www.crisp.se/scrum/checklist Version 2.1 (2009-08-17)
Typical waterfall Scrum evolution1. WaterfallRequirements2. ”Scrum But”3. ScrumPORequirementsFeatureteam 1DesignFeatureteam 2Design & codeCodeTestHenrik KnibergTest6
Kanban in a nutshellVisualize the workflowLimit WIP (work in progress)Measure & optimize flowTo do5Dev3HTest2DGRelease3CDone!ABKFLOWUseful starting point for more info:http://www.limitedwipsociety.org7
看板Roots of KanbanKan Ban”Visual teManufactureThe two pillars of the Toyotaproduction system are just-in-timeand automation with a humantouch, or autonomation.The tool used to operate thesystem is kanban.Henrik KnibergTaiichi OhnoFather of theToyota Production System8
Kanban in software developmentHenrik Kniberg9
Typical Scrum Kanban evolutionScrum step 1Featureteam 1Featureteam 2Featureteam 2ScrumScrumScrumScrum step 2Featureteam 1ScrumFeatureteam 2ScrumFeatureteam 2ScrumOperations / support teamScrumHenrik KnibergScrum KanbanFeatureteam 1ScrumFeatureteam 2ScrumFeatureteam 2ScrumOperations / support teamKanban10
Thinking toolsa.k.a. ”mindsets” or ”philosophies”Tool”anything used as a means ofaccomplishing a task or purpose.”- dictionary.comLeanPhysical toolsAgileSystems ThinkingTheory of ConstraintsToolkitsa.k.a. ”frameworks”RUPScrumXPKanbanProcess toolsa.k.a. ”organizational patterns”Product Owner rolePair programmingVisualize the workflowTo do5Dev3HTestReleaseDC23Done!AGBKFLOWHenrik Kniberg11
Can we compare Kanban and Scrum?Should we?Henrik Kniberg12
Any tool can be misusedThe old toolwas better!Never blamethe tool!13Henrik Kniberg13
Compare for understanding, not judgementMore prescriptiveMore adaptiveRUP(120 ) Architecture ReviewerBusiness DesignerBusiness-Model ReviewerBusiness-Process AnalystCapsule DesignerChange Control ManagerCode ReviewerConfiguration ManagerCourse DeveloperDatabase DesignerDeployment ManagerDesign ReviewerDesignerGraphic ArtistImplementerIntegratorProcess EngineerProject ManagerProject ReviewerRequirements ReviewerRequirements SpecifierSoftware ArchitectStakeholderSystem AdministratorSystem AnalystTechnical WriterTest AnalystTest DesignerTest ManagerTesterTool SpecialistUser-Interface DesignerArchitectural analysisAssess Viability of architecturalproof-of-conceptCapsule designClass designConstruct architectural proof-ofconceptDatabase designDescribe distributionDescribe the run-time architectureDesign test packages and classesDevelop design guidelinesDevelop programming guidelinesIdentify design elementsIdentify design mechanismsIncorporate design elementsPrioritize use casesReview the architectureReview the designStructure the implementationmodelSubsystem designUse-case analysisUse-case designAnalysis modelArchitectural proof-of-conceptBill of materialsBusiness architecture documentBusiness caseBusiness glossaryBusiness modeling guidelinesBusiness object modelBusiness rulesBusiness use case Business use case realizationBusiness use-case modelBusiness visionChange requestConfiguration audit findingsConfiguration management planData modelDeployment modelDeployment planDesign guidelinesDesign modelDevelopment caseDevelopment-organizationassessmentEnd-user support mateirlaGlossaryImplementation modelInstallation artifactsIntegration build planIssues listIteration assessmentIteration planManual styleguideProgramming guidelinesQuality assurance planReference architectureRelease notesRequirements attributesRequirementsmanagement planReview recordRisk listRisk management planSoftware architecturedocumentSoftware developmentplanSoftware requirementsspecificationStakeholder requestsStatus assessmentSupplementary businessspecificationSupplementary specificationTarget organization assessmentTest automation architectureTest casesTest environment configurationTest evaluation summaryTest guidelinesTest ideas listTest interface specificationTest planTest suiteTool guidelinesTraining materialsUse case modelUse case packageUse-case modeling guidelinesUse-case realizationUse-case storyboardUser-interface guidelinesUser-interface prototypeVisionWork orderWorkload analysis modelHenrik KnibergScrum(9)XP(13) Whole teamCoding standardTDDCollective ownershipCustomer testsPair programmingRefactoringPlanning gameContinuous integrationSimple designSustainable paceMetaphorSmall releases Scrum MasterProduct OwnerTeamSprint planning meetingDaily ScrumSprint reviewProduct backlogtSprint backlogBUrndown chartKanban(3) Do Whatever(0)Visualize the workflowLimit WIPMeasure and optimize lead timeDo not develop an attachmentto any one weaponor any one school of fightingMiyamoto Musashi17th century samurai14
Distinguish the tool itselffrom specific usage techniquesSpecific patterns, techniques,”best practices”, etcScrumcoreHenrik KnibergKanbancore15
Scrum prescribes 3 rolesProductownerTeamScrumMasterPOSMHenrik Kniberg16
Scrum prescribes timeboxed iterationsScrum teamKanban team 1week 1week 3week 4Sprint 1Plan & commitKanban team 2week 2week 5week 6week 7week 8Sprint 2Review(release?)Retrospectiveweek 1week 2week 3week 4week 5week 6week 7week 8week 1week 2week 3week 4week 5week 6week 7week 8Retrospectives (4w)Planning cadence (2w)Release cadence (1w)Kanban team 3Retrospectives (4w)Planning (on demand)Release (on demand)Henrik Kniberg17
Both limit WIP, but in different waysKanban boardScrum boardTo doOngoing Done :o)To doOngoing Done :o)2ABBCCDDFLOWWIP limited per unit of time(iteration)Henrik KnibergAFLOWWIP limited per workflow state18
Both are empiricalCapacityLead timeQualityPredictability(aka velocity)(aka cycle time)(defect rate, etc)(SLA fulfillment, etc)Kanban is more configurableMany small teamsLow WIP limitsFew workflow statesFew large teamsMany workflow statesLong iterationsLittle planningLots of planningHenrik KnibergOh no, more decisions!High WIP limitsShort iterations. etc .Great! More options!. etc .19
I’d like to have E!Scrum discourages changein mid-iterationPOWait until a To Do slotbecomes available!Or swap out C or D!Wait until next sprint!KanbanScrumTo doOngoing Done :o)To do2Ongoing Done :o)2CACADBDBFLOWFLOWPoliciesHenrik Kniberg20
Scrum board is reset between eachiterationScrumFirst day of sprintMid-sprintLast day of sprintKanbanAny dayHenrik Kniberg21
Scrum prescribes cross-functional teamsScrum teamKanban team 1Cross-functionalteamHenrik KnibergKanban team 2Specialist Cross-functionalteamSpecialistteam22
Scrum backlog items must fit in a sprintScrumSprint 1Sprint 2Sprint 3Sprint 4KanbanLong running taskWIP limit 3Henrik KnibergLong running task23
Scrum prescribes estimation and velocityV 81V 722Sprint 1Henrik Kniberg231Sprint 2V 913112221Likely velocity: 8 per sprint(sustainable pace?)Sprint 324
Both allow working on multiple productssimultaneouslyKanban example 1Scrum example 1Green ProductGreen teamScrum example 2All productsCross-product teamHenrik KnibergColor-coded tasksYellow ProductYellow teamScrum example 3All productsCross-product teamKanban example 2Color-coded swimlanes25
The Toyota WayBoth are Leanand AgileAgile Manifesto1.2.3.4.Individuals and Interactionsover Processes and ToolsWorking Softwareover ComprehensiveDocumentationCustomer Collaborationover Contract NegotiationResponding to Changeover Following a Plan1.2.3.4.5.6.7.8.9.10.11.12.13.Henrik Kniberg14.Base your management decisions on a Long-TermPhilosophy, Even at the Expense of Short-Term FinancialGoalsCreate Continuous Process Flow to Bring Problems to theSurfaceUse Pull Systems to Avoid OverproductionLevel Out the Workload (Heijunka)Build a Culture of Stopping to Fix Problems, to Get QualityRight the First TimeStandardized Tasks are the Foundation for ContinuousImprovement and Employee EmpowermentUse Visual Controls So No Problems are HiddenUse Only Reliable, Thoroughly Tested Technology ThatServes Your People and ProcessesGrow Leaders Who Thoroughly Understand the Work, Livethe Philosophy, and Teach It to OthersDevelop Exceptional People and Teams Who Follow YourCompany’s PhilosophyRespect Your Extended Network of Partners and Suppliers byChallenging Them and Helping Them ImproveGo and See for Yourself to Thoroughly Understand theSituation (Genchi Genbutsu)Make Decisions Slowly by Concensus, ThoroughlyConsidering All Options; Implement Decisions RapidlyBecome a Learning Organization Through RelentlessReflection (Hansei) and Continuous Improvement (Kaizen)26
Minor difference:Scrum prescribes a prioritized product backlogScrum:Product backlog mustexistChanges to productbacklog take effect nextsprint (not current sprint)Product backlog must besorted by “business value”Kanban:Product backlog is optionalChanges to product backlogtake effect as soon ascapacity becomes availableAny prioritization scheme canbe used. For example:Take any itemAlways take the top itemAlways take the oldest item20% on maintainance items,80% on new featuresSplit capacity evenly betweenproduct A and product BAlways take red items firstPoliciesHenrik Kniberg27
Minor difference:Scrum prescribes daily meetings. but many Kanban teams do that anyway.Henrik Kniberg28
Minor difference:In Scrum, burndown charts are prescribedNo specific types of diagramsprescribed in Kanban. Teamsuse whatever they need.Cumulative FlowHenrik Kniberg29
Evolve your own unique board!Henrik KnibergSome of these photos courtesy ofDavid Anderson, Mattias Skarin,and various other people30
Kanban www.crisp.se/kanban/examplekick-start exampleHenrik KnibergNext2Analysis3Development3OngoingOngoing Done2009-09-01orem ipsum dolor sitamet, co adi pis cingelit nisl2009-08-20orem olor sit amet, conse ctetur adi pis cingelit nislorem ipsum dolorsit amet, co nsectetur2009-08-29orem ipsum dolor sitamet, nse ctetur adipis cing elit nislorem ipsum dolorsit amet, co nse2009-08-25orem ipsum dolor sitctetur adi pis cing elitnislorem ipsum dolororem ipsum dolorsit amet, co nsesit amet, co nse cteturcteturDefinition of Done: Goal is clear First tasks defined Story split (if necessary)Feature / storyDate whenadded to board2009-09-30(description)Doneorem ipsum dolorsit amet, co nsecteturorem ipsum dolorsit amet, co nsectetur2009-09-022009-08-20Ongoingorem ipsum dolor sitamet, adi pis cing elitnislorem ipsum dolorsit amet, co nsecteturxxxx kjdorem ipsumdjdolord xxxsit amet, co nsecteturorem ipsum dolorsit amet, co nsecteturAcceptance Prod22009-08-272009-09-082009-08-30orem ipsumdolor sitorem ipsum doloramet,co nseamet, co sitnsecteturcteturadi pis cingelit nislDoneversion 1.22009-11-16Definition of Done: Code clean & checked in on trunk Integrated & regression tested Running on UAT environmentHard deadline(if applicable) priority panicWho is analyzing /testing right nowTask / defect(description) cription) defect completed blocked who is doingthis right nowDefinition of Done: Customer accepted Ready for productionWhat to pull first1. Panicfeatures(should be swarmed and keptmoving. Interrupt other workand break WIP limits asnecessary)2. Priority features3. Hard deadline features(only if deadline is at risk)4. Oldest features
Comparison:Typical Scrum board & Kanban boardScrumSprint backlogProductbacklogEEFFGHGCommitted Ongoing Done :o)A?BICJ HLKMDKanbanFHDevNextBacklog2GIJ LKMHenrik KnibergOngoingDBEC3DoneAIn production :o)XQR32
Scenario 1 – one piece flowNextBacklogA2DevIn production :o)3OngoingDoneBGCFHJMDILKHenrik KnibergE33
Scenario 1 – one piece flowNextBacklog2OngoingDoneBCFHMIn production :o)3AGJDevDILKHenrik KnibergE34
Scenario 1 – one piece flowBacklog2OngoingDoneBCFHMIn production :o)3AGJDevNextDILKHenrik KnibergE35
Scenario 1 – one piece flowDevNextBacklog2OngoingCGDIn production :o)3DoneABFHJMILKHenrik KnibergE36
Scenario 1 – one piece flow.DevNextBacklog2In production :o)3OngoingDoneCGDABFHJMILKHenrik KnibergE37
Scenario 2 – Deployment problemNextBacklogPOA2DevIn production :o)3OngoingDoneBGCFHJMDILKHenrik KnibergE38
Scenario 2 – Deployment problemNextBacklog2POOngoingDoneBCFHMIn production :o)3AGJDevDILKHenrik KnibergE39
Scenario 2 – Deployment problemDevNextBacklogPOG2In production :o)3OngoingCADBDoneFHJMILKHenrik KnibergE40
Scenario 2 – Deployment problemDevNextBacklogPO2OngoingCGDIn production :o)3DoneABFHJMILKHenrik KnibergE41
Scenario 2 – Deployment problemBacklogPO2GDFHJMDevNextIn production :o)3OngoingDoneCA!?BILKHenrik KnibergE42
Scenario 2 – Deployment problemBacklogPO2FHMIn production :o)3Ongoing!?GJDevNexetDoneADBECILKHenrik Kniberg43
Scenario 2 – Deployment problemNextBacklogPO2FHMIn production :o)3OngoingDoneAGJDevDBECILKHenrik Kniberg44
Scenario 2 – Deployment problemNextBacklogPO2DevIn production :o)3OngoingDoneAGDFHJMEBCILKHenrik Kniberg45
Scenario 2 – Deployment problemBacklogPOIn production :o)3OngoingDoneHABEFM2DGJDevNextCILKHenrik Kniberg46
”One day in Kanban ban/Henrik Kniberg47
Kanban & dfComparison summarySimilaritiesBoth are Lean and AgileBoth based on pull schedulingBoth limit WIPBoth use transparency to drive processimprovementBoth focus on delivering releasablesoftware early and oftenBoth are based on self-organizing teamsBoth require breaking the work intopiecesIn both cases the release plan iscontinuously optimized based onempirical data (velocity / lead time)Henrik KnibergDifferencesScrumKanbanTimeboxed iterations prescribed.Timeboxed iterations optional.Team commits to a specific amountof work for this iteration.Uses Velocity as default metric forplanning and process improvement.Cross-functional teamsprescribed.Items broken down so they can becompleted within 1 sprint.Burndown chart prescribedCommitment optional.WIP limited indirectly (per sprint)Estimation prescribedCannot add items to ongoingiteration.A sprint backlog is owned by onespecific teamPrescribes 3 roles (PO/SM/Team)A Scrum board is reset betweeneach sprintPrescribes a prioritized productbacklogUses Lead time as default metric forplanning and process improvement.Cross-functional teams optional.Specialist teams allowed.No particular item size is prescribed.No particular type of diagram isprescribedWIP limited directly (per workflowstate)Estimation optionalCan add new items whenevercapacity is availableA kanban board may be sharedby multiple teams or individualsDoesn’t prescribe any rolesA kanban board is persistentPrioritization is optional.48
Don’t be dogmaticGo away! Don’t talk to us!We’re in a Sprint.Come backin 3 weeks.Henrik KnibergThough ShaltLimit WIP49
RetrospectivesEssential skills neededfor both Kanban and ScrumSplitting the system intodeliverable incrementsSoftwarecraftsmanshipRoot-cause analysisTeams notfocusedTeams notbusinessorientedTeams don’t haveown POTeam not gettingfeedback fromcustomerTeams groupedby com ponentIneffectiverequirementscom municationHard toplanDelayed releasesNotm easuringvelocityTeams disruptedduring sprintMany operationalproblem sLack of disciplinein teamsLack oftransparancyNoburndownsBad throughput indevelopm entFear ofcommittingProblemsestimatingUnclear roles &responsibilitiesToo much focuson written specsLack of teamspiritFeature split acrossm ultiple team sPO doesn’t haveown teamCutting qualityinstead of scopeManydefectsDifficult toreleaseLack of testautomationHard tochange nrik.kniberg/cause-effect-diagrams.pdfHenrik Kniberg50
Take-away points1. Know your goalHint: Agile/Lean/Kanban/Scrum isn’t it.2. Never blame the toolTools don’t fail or succeed. People do.There is no such thing as a good or bad tool. Only goodor bad decisions about when, where, how, and why touse which tool.3. Don’t limit yourself to one toolLearn as many as possible.Compare for understanding, not judgement.4. Experiment & enjoy the rideDon’t worry about getting it right from start.The only real failure is the failure to learn from failure.Henrik Kniberg51
Henrik Kniberg52
Team Scrum Master. 17 Scrum prescribes timeboxed iterations Scrum team Henrik Kniberg week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 Sprint 1 Plan & commit Review . Great! More options! Oh no, more decisions! 20 Scrum discourages change in mid-iteration Henrik Kniberg To do O
Kanban and Scrum classroom training, and Kanban and Scrum certification programs before you certify your knowhow in Kanban and Scrum. International Scrum Institute provides twelve major online Kanban and Scrum certification programs. These programs have bee
either a 2-tiered Kanban. board or Intermediate. Kanban board with. swimlanes and sub-columns. 2-tiered. Kanban boards are. commonly found in. scenarios that involve a. project management. organization that. utilizes a portfolio. Kanban board in. combination with. upstream or delivery. Kanban boards. Intermediate Kanban. boards are used by .
Scrum Master Product Owner Scrum Roles Scrum Team DevTeam Scrum Master: Accountable for facilitating, mentoring and enacting effective Scrum . Manual Testing Okay PO Acceptance DocoComplete WIP Limits -Maximum number of Kanban in each column. Kanban Board Ready (5) Discovery (3) Delivery (5) UAT (3) Ready for
This Scrum and Scrum Master Guide is a free, quick reference material designed to help aspiring scrum masters discover the ins and outs of Scrum. It throws light on the fundamental principles of the scrum, scrum terminologies, Agile Manifesto, scrum theories, scrum tools, different roles, responsibilities, and more. SCRUM & SCRUM MASTER
either a 2-tiered Kanban. board or Intermediate. Kanban board with. swimlanes and sub-columns. 2-tiered. Kanban boards are. commonly found in. scenarios that involve a. project management. organization that. utilizes a portfolio. Kanban board in. combination with. upstream or delivery. Kanban boards. Intermediate Kanban. boards are used by .
The size attribute of a kanban determines the replenishment quantity. The size of the kanban affects the effectiveness of the kanban system significantly; when the kanban size is too high, the system contains more inventory than necessary, which is unacceptable. When the kanban size is too low, the system will eventually run out of inventory.
Kanban works, with 87% reporting Kanban to be more or. much more effective than other methods. S U M M A R Y. Tooling matters. Tools designed for Kanban are highly recommended, while. general agile tools claiming to have Kanban support continue to fall short. Kanban adoption is growing. 86% of respondents indicated that they expect to
making formal decisions at the final “appeal” stage of our process (see page 75 for more details ) All figures relate to the financial year 2012/2013. 4 annual review 2012/2013 . Financial Ombudsman Service Financial Ombudsman Service . annual review 2012/2013 5. chairman’s foreword. Sir Nicholas Montagu . kcb. we have resolved . more cases. than in any previous year – and each of .
