jueves, 16 de junio de 2011



  • Both are Lean and Agile

  • Both use pull scheduling

  • Both limit WIP

  • Both use transparency to drive process improvement

  • Both focus on delivering releasable software early and often

  • Both are based on self-organizing teams

  • Both require breaking the work into pieces

  • In both cases the release plan is continuously optimized based on empirical data (velocity / lead time)

Scrum Kanban
Timeboxed iterations prescribed. Timeboxed iterations optional. Can have separate cadences for planning, release, and process improvement. Can be event-driven instead of timeboxed.
Team commits to a specific amount of work for this iteration. Commitment optional.
Uses Velocity as default metric for planning and process improvement. Uses Lead time as default metric for planning and process improvement.
Cross-functional teams prescribed. Cross-functional teams optional. Specialist teams allowed.
Items must be broken down so they can be completed within 1 sprint. No particular item size is prescribed.
Burndown chart prescribed No particular type of diagram is prescribed
WIP limited indirectly (per sprint) WIP limited directly (per workflow state)
Estimation prescribed Estimation optional
Cannot add items to ongoing iteration Can add new items whenever capacity is available
A sprint backlog is owned by one specific team A kanban board may be shared by multiple teams or individuals
Prescribes 3 roles (PO/SM/Team) Doesn’t prescribe any roles
A Scrum board is reset between each sprint A kanban board is persistent
Prescribes a prioritized product backlog Prioritization is optional

If you've asked this question yourself, or needed to answer it for someone else, you should take some time to read Kniberg's Kanban vs Scrum article.

Extracted from: http://www.infoq.com/news/2009/05/kniberg-kanban-v-scrum