Kanban Vs Scrum
Kanban vs Scrum
H ow to make the most of both
Henrik Kniberg
henrik.kniberg crisp.se
Version 1.1 (2009-06-29)
Deprecated version! Latest version is available at http://www.infoq.com/minibooks/kanban-scrum-minibook Backlog
Develop
Selected
3
2
Ongoing
Done
FLOW
Deploy
1
Live :o)
Kanban vs Scrum – how to make the best of both (Henrik Kniberg)
Deprecated version! Latest version is available at http://www.infoq.com/minibooks/kanban-scrum-minibook This book has moved!
The latest version is available at InfoQ: http://www.infoq.com/minibooks/kanban-scrum-minibook (Still free, but registration is required. It’s quick.)
The InfoQ version includes:
Foreword by Mary Poppendieck
Foreword by David Anderson …show more content…
We’ve selected three states: To Do, Ongoing, and Done. You can choose whatever states you like – some teams add states such as Integrate, Test, Release, etc. Don’t forget the less is more principle though.
So what’s the difference between these two sample boards then? Yep - the little 2 in the middle column on the kanban board. That’s all. That 2 means “there may be no more than 2 items in this column at any given moment”.
In Scrum there is no rule preventing the team from putting all items into the Ongoing column at the same time! However there is an implicit limit since the iteration itself has a fixed scope. In this case the implicit limit per column is 4, since there are only 4 items on the whole board. So Scrum limits
WIP indirectly, while Kanban limits WIP directly.
Most Scrum teams eventually learn that it is a bad idea to have too many ongoing items, and evolve a culture of trying to get the current items done before starting new items. Some even decide to explicitly limit the number of items allowed in the Ongoing column and then – tadaaa – the Scrum board has become a Kanban board!
page 14 / …show more content…
“I want high capacity, low lead time, high quality, and high predictability. So I’ll turn the knows to 10, 1, 10, 10 respectively.”
Wouldn’t that be great? Unfortunately there are no such direct controls. Not that I know of at least.
Let me know if you find any.
Instead what we have is a bunch of indirect controls.
Scrum and Kanban are both empirical in the sense that you are expected to experiment with the process and customize it to your environment. In fact, you have to experiment. Neither Scrum nor
Kanban provide all the answers – they just give you a basic set of constraints to drive your own process improvement.
·
Scrum says you should have cross-functional teams. So who should be on what team? Don’t know, experiment.
·
Scrum says the team chooses how much work to pull into a sprint. So how much should they pull in? Don’t know, experiment.
·
Kanban says you should limit WIP. So what should the limit be? Don’t know, experiment.
As I mentioned earlier, Kanban imposes fewer constraints than Scrum. This means you get more parameters to think about, more knobs to turn. That can be both a disadvantage or an
H ow to make the most of both
Henrik Kniberg
henrik.kniberg crisp.se
Version 1.1 (2009-06-29)
Deprecated version! Latest version is available at http://www.infoq.com/minibooks/kanban-scrum-minibook Backlog
Develop
Selected
3
2
Ongoing
Done
FLOW
Deploy
1
Live :o)
Kanban vs Scrum – how to make the best of both (Henrik Kniberg)
Deprecated version! Latest version is available at http://www.infoq.com/minibooks/kanban-scrum-minibook This book has moved!
The latest version is available at InfoQ: http://www.infoq.com/minibooks/kanban-scrum-minibook (Still free, but registration is required. It’s quick.)
The InfoQ version includes:
Foreword by Mary Poppendieck
Foreword by David Anderson …show more content…
We’ve selected three states: To Do, Ongoing, and Done. You can choose whatever states you like – some teams add states such as Integrate, Test, Release, etc. Don’t forget the less is more principle though.
So what’s the difference between these two sample boards then? Yep - the little 2 in the middle column on the kanban board. That’s all. That 2 means “there may be no more than 2 items in this column at any given moment”.
In Scrum there is no rule preventing the team from putting all items into the Ongoing column at the same time! However there is an implicit limit since the iteration itself has a fixed scope. In this case the implicit limit per column is 4, since there are only 4 items on the whole board. So Scrum limits
WIP indirectly, while Kanban limits WIP directly.
Most Scrum teams eventually learn that it is a bad idea to have too many ongoing items, and evolve a culture of trying to get the current items done before starting new items. Some even decide to explicitly limit the number of items allowed in the Ongoing column and then – tadaaa – the Scrum board has become a Kanban board!
page 14 / …show more content…
“I want high capacity, low lead time, high quality, and high predictability. So I’ll turn the knows to 10, 1, 10, 10 respectively.”
Wouldn’t that be great? Unfortunately there are no such direct controls. Not that I know of at least.
Let me know if you find any.
Instead what we have is a bunch of indirect controls.
Scrum and Kanban are both empirical in the sense that you are expected to experiment with the process and customize it to your environment. In fact, you have to experiment. Neither Scrum nor
Kanban provide all the answers – they just give you a basic set of constraints to drive your own process improvement.
·
Scrum says you should have cross-functional teams. So who should be on what team? Don’t know, experiment.
·
Scrum says the team chooses how much work to pull into a sprint. So how much should they pull in? Don’t know, experiment.
·
Kanban says you should limit WIP. So what should the limit be? Don’t know, experiment.
As I mentioned earlier, Kanban imposes fewer constraints than Scrum. This means you get more parameters to think about, more knobs to turn. That can be both a disadvantage or an