The difference between scrum and Kanban

Kanban ： In the products (work-in-progress, WIP) Must be limited
WIP Cap and pull production

1. Scrum Brief introduction to Kanban
   Scrum： Organization split , Work splitting , Development time split , Optimize release plan , Process optimization
   Kanban ： Process visualization , Limit WIP, Measuring the production cycle

2. Scrum And kanban
   Scrum And Kanban are process tools
   Scrum And Kanban just give some clear constraints and guidance , such as ,Scrum The constraints are fixed length iterations and cross functional teams , The constraint of Kanban is to have visible kanban , The queue size should be constrained
   Agile methods are also called lightweight methods

3. Scrum Roles are defined
   Scrum Three roles are defined ：PO/Team/SM, Kanban doesn't specify any roles

4. Scrum Specifies a fixed length of iteration
   Scrum The iteration of is a mixture of three activities ： plan / Process improvement / Release

5. Scrum By iteration limit WIP, Kanban is restricted by process status WIP

6. Scrum And Kanban are both empiricism , Need introspection / feedback / adjustment

7. Scrum Reject changes during iterations
   The principle of Kanban is “ Go out one by one , Come in one ”, Response time is equal to the processing time of the task at hand
   Scrum The average response practice of is equal to sprint Half the length

8. About the size of the mission
   Scrum The team only promises to accomplish tasks within an iteration , If the task is too big, split it
   The Kanban does not specify the task scale, which must be completed in a certain period of time

9. Scrum Estimates and productivity are specified , The Kanban does not specify an estimate
   Some teams skip estimates , Split each task to a size close to , Count the number of features completed per week
   Some teams package tasks into MMF( Minimum marketable characteristics ), Measure each MMF Production cycle , establish SLA( Service quality commitment )

10. How cross product teams use backlog
    You can put the product backlog As a team backlog To view
    Multiple products can be distinguished by swimlanes

---

scrum And Kanban , After reading this book, I really know better than before （ Consider oneself ）

1. scrum More focus on team organization and task splitting （ The implementation of ）, Kanban focuses more on the visualization of task flow （ present ）
2. Kanban makes the team's work more transparent , More detailed work needs scrum To implement （ Three will , Various roles , Estimate ,sprint）
3. Both are process tools , Like the design pattern, it is the previous experience , Applying it to the team needs to take its essence and discard its dross , Explore ways that are appropriate for the team
4. The team usually will scrum Combined with Kanban

Several key words in the book ,

WIP：work-in-progress, In the products ,WIP Must be limited to kanban One of the main ideas of
lane ： The beginning is in UML It appears that , It's called swimlane There are also people called. partition, Except for the vertical columns defined by state , You can also use horizontal lanes to distinguish , For example, distinguish multiple products in a team
T Shirt law ： Used to make estimates , Small / in / Big , Qualitative but not quantitative

Scrum
Break down the organization into groups 、 Cross functional 、 Self organizing teams .

Break down the work into small parts 、 Tangible deliverables , The delivery and scheduling personnel are responsible for the list of requirements and ranking priorities according to importance , The team estimates the relative workload of each project .

Divide the whole development time into short iterations of fixed duration （ Usually from one to four weeks ）, Demonstrate new releasable features after each iteration .

Optimize publishing and update priorities with customers , Based on observations released after each iteration .
The optimization process , Review after each iteration

We don't rely on a large team , Spend a lot of time building behemoths ; But with a small team in a short time
Make small pieces , Assemble the whole picture in regular integration .

Two 、 Introduction to Kanban development mode
Visualization of workflow
Break down work into tasks , Write it on a cardboard , On the wall
Name the column , To display the status of the task in the workflow
Limit “ In the products ”（work in progress, abbreviation WIP） – Clearly set the limit of how many work tasks can be done at the same time in each state . The essence of Kanban is a very simple thought ： In the products （work-in-progress,WIP） Must be limited . Only the current work is delivered , Or there is a pull from the downstream , New work can begin .
Measuring the production cycle （ The average time to complete a task ）, Optimize the development process , Shorten the development cycle and make it more predictable .

The same thing

Both are consistent with lean and agile thinking
Both use " Pull type " Schedule
Both limit the amount of work in development
Both are driven by transparency
Both centralized early and constant shipment software
Both are based on self-organizing teams
Both require a breakdown of the work
In both cases, the release plan is based on empirical data （ Speed ／ The development cycle ） Continue to optimize

Difference

Scrum Kanban development mode
Regular iterations are required No definite time iteration is specified , You can plan separately 、 Release 、 Process improvement , Can be event driven rather than time bound
The team promises a certain amount of work in each iteration Commitment is not necessary
At speed （Velocity） As measurement data for planning and process improvement Use the development cycle as metrics for planning and process improvement
Assign cross functional teams There is no cross functional team assigned , Specialized teams are also allowed
Task breakdown , Can be done in one iteration No task size specified
Specify to use the combustion diagram No chart specified
Indirectly limit work in development （ Every iteration ） Set limits on work in development （ Each workflow state ）
Specify the estimation process No estimation method specified
You cannot add new work tasks to an iteration As long as productivity permits , You can add tasks at any time
A single team is responsible for Sprint Backlog Multiple teams and members share kanban
Specify three roles （ Product owner ／ScrumMaster/ The team ） There are no team roles assigned
Scrum board Reset after each iteration Kanban reflects sustainable development
Prescribing prioritized product backlog Priority is not required

Scrum And XP

Difference ：Scrum Very prominent Self-Orgnization（ management ）,XP Focus on strong engineering practices constraint . The two can be combined in specific applications , Enable... In management mode Scrum, In practice , Create a project that suits your team XP(“start with Scrum and then invent your own version of XP.”)

The following is a reprint of ：

One of the differences ： Different iteration lengths

XP One of the Sprint The iteration length of is approximately 1~2 Zhou , and Scrum The iteration length of is generally 2~ 4 Zhou .

The second difference : In iteration , Allow to modify requirements

XP In an iteration , If one User Story( User story , That is, a demand ) It hasn't been implemented yet , You can consider replacing it with another requirement , The principle of substitution is that the amount of time required to implement is equal . and Scrum This is not allowed Of , Once the iteration kick-off meeting is completed , No requirements are allowed to be added , And there are Scrum Master Keep a strict check on , The development team is not allowed to be disturbed

The third difference : In iteration ,User Story Whether to implement strictly according to the priority

XP It is important to observe the priority . but Scrum It is very flexible at this point , It can be done without priority ,Scrum The reason for this is ： If the priority problem solver , Delayed by other things , Can't claim the task , Then the whole progress will be delayed . Another reason is , If by priority User Story #6 and #10, although #6 High priority , But if #6 The implementation depends on #10, Have to give priority to #10.

The fourth difference : During the implementation of the software , Whether strict engineering methods are adopted , Ensure progress or quality

Scrum No, Give a prescription of engineering practice for the whole implementation process of the software , Require developers to consciously guarantee .

but XP The definition of the whole process method is very strict , The regulations require the use of TDD, Automatic test , Pair programming , Simple design , Refactoring and other constraints on team behavior . therefore , The original author thinks that , At this point ,XP The practice of , But it brings agile into a confusing contradiction , because xp Idea , Combine agile patterns , The message to the team is “ You are a completely self - Managing Organization , But you have to achieve TDD, Pair programming , … wait ”

It's not hard to find out , The four differences are obvious ： Scrum Very prominent Self-Orgnization, XP Focus on strong engineering practice constraints

Enable... In management mode Scrum, In practice , Create a project that suits your team XP(“start with Scrum and then invent your own version of XP.”)