看板開發方式是近年引起很多討論和注目的一種敏捷開發實施，有不少人問到「看板開發方式如何跟Scrum比較？」，Henrik Kniberg就嘗試迴應這問題。
Henrik Kniberg最新發表 比較看板開發方式和Scrum的"實務指引" ，Kniberg在這精要的文章中指出看板開發和Scrum如何類似以及如何不同。
文章開始以一個清單介紹兩種方式：
一、Scrum簡介
把組織細分成小組、跨功能、自我組織團隊。把工作細分成細小、實在的交付成果，交排人員負責需求清單以及跟據重要性排優先級別，由團隊估算每個項目相對工量。把整個開發時間分成固定時長的短迭代（通常於一至四星期），在每個迭代後演示新增可發佈功能。優化發佈以及跟客戶一起更新優先級別，基於每個迭代後發佈的觀察。優化過程，在每個迭代之後進行回顧
二、看板開發方式簡介
工作流程形象化把工作細分成任務，寫在卡紙上，貼在牆上把欄命名好，來顯示任務在工作流程中的狀況限制“在製品”（work in progress，簡稱 WIP） – 明確設定限制在每個狀態下同一時間能有多少工作任務度量生產週期（即完成一個任務的平均時間），優化開發過程，縮短開發週期和使它更易於預測。
相同點
兩者都符合精益和敏捷思考兩者使用"拉動式"安排日程兩者限制開發中工作數目兩者是透過透明度來驅動過程開進兩者集中提早及衡常的付運軟件兩者基於自我組織團隊兩者要求把工作細分在兩個情況下發布計劃都是基於經驗數據（速度／開發週期）持續優化
不同點
| Scrum | 看板開發方式 |
|---|---|
| 要求定時迭代 | 沒指定定時限迭代，可以分開計劃、發佈、過程改進，可以事件驅動而不是限定時限 |
| 團隊在每個迭代承諾一定數目的工作 | 承諾不是必須的 |
| 以速度（Velocity）作爲計劃和過程改進的度量數據 | 使用開發週期作爲計劃和過程改進的度量數據 |
| 指定跨功能團隊 | 沒有指定跨功能團隊，也容許專門團隊 |
| 工作任務細分，可於一個迭代中完成 | 沒有指定工作任務大小 |
| 指定使用燃燒圖 | 沒有指定任何圖表 |
| 間接限制開發中工作（每個迭代） | 設定開發中工作的限制（每個工作流程狀態） |
| 規定估算過程 | 沒有指定任何估算方式 |
| 在迭代中不能加入新工作任務 | 只要生產力容許，可以隨時加工作任務 |
| 由單一團隊負責 Sprint Backlog | 多個團隊和團員分享看板 |
| 指定三個角色（產品負責人／ScrumMaster/團隊） | 沒有指定任何團隊角色 |
| Scrum board 在每個迭代後重設 | 看板反映持久開發情況 |
| 規定優先化的 product backlog | 優先級是非必須的 |
