Scrum và Kanban: khác nhau ở đâu, và cái nào hợp với nhóm nhỏ
Tác giả: Andrei Finogeev, nhà sáng lập Weft ·
Scrum lên kế hoạch công việc theo các sprint cố định dài một tháng hoặc ngắn hơn, với ba trách nhiệm (Product Owner, Scrum Master, Developers) và bốn sự kiện trong mỗi sprint. Kanban không có sprint và không quy định vai trò: công việc chảy liên tục trên bảng, và nhóm giới hạn rõ ràng số việc đang làm. Chọn Scrum khi một nhóm vài người cần nhịp bàn giao cố định và một mục tiêu ổn định cho mỗi chu kỳ; chọn Kanban khi công việc đến bất ngờ và ưu tiên thay đổi hằng ngày. Scrumban nằm giữa hai cái: dòng chảy của Kanban, với sprint chỉ ở chỗ nào có ích.
Scrum, Kanban và Scrumban: bảng so sánh nhanh
Scrum theo định nghĩa của Scrum Guide 2020, Kanban theo định nghĩa của Kanban Guide (v2025.5). Scrumban không có hướng dẫn chính thức; cột này mô tả cách nó thường được vận hành.
| Scrum | Kanban | Scrumban | |
|---|---|---|---|
| Nhịp độ | Sprint cố định một tháng hoặc ngắn hơn, nối tiếp nhau | Dòng chảy liên tục, không có vòng lặp | Dòng chảy liên tục; sprint tùy chọn, thường một hoặc hai tuần |
| Vai trò | Product Owner, Scrum Master, Developers | Không quy định | Không quy định; thường một người nắm ưu tiên |
| Cuộc họp | Sprint Planning, Daily Scrum (15 phút), Sprint Review, Sprint Retrospective | Không quy định | Chỉ những gì nhóm thấy có ích, thường là planning và review |
| Thứ giới hạn công việc | Những gì nhóm cam kết cho sprint | Một giới hạn rõ ràng cho việc đang làm | Giới hạn việc đang làm, cộng mục tiêu sprint nếu có |
| Đổi phạm vi giữa chu kỳ | Sprint Goal giữ cố định; Sprint Backlog có thể được tinh chỉnh | Bất cứ lúc nào: việc tiếp theo được kéo vào khi có chỗ | Bất cứ lúc nào; mục tiêu sprint là đích nhắm, không phải khóa cứng |
| Thước đo chính | Tiến độ hướng tới Sprint Goal và Product Goal | Việc đang làm, throughput, tuổi của hạng mục công việc, cycle time | Thường là các thước đo dòng chảy của Kanban |
| Bảng | Tùy chọn; đặt lại mỗi sprint | Cốt lõi của phương pháp; tồn tại lâu dài | Tồn tại lâu dài; sprint là một lát cắt của nó |
| Hợp nhất với | Nhóm sản phẩm đến khoảng mười người cùng hướng tới một mục tiêu | Hỗ trợ khách hàng, vận hành và bất kỳ ai có công việc đến ngoài kế hoạch | Nhóm nhỏ và founder làm một mình muốn có dòng chảy và một mục tiêu ngắn hạn |
Scrum là gì
Scrum được Ken Schwaber và Jeff Sutherland trình bày lần đầu tại hội nghị OOPSLA năm 1995; quy tắc ngày nay là Scrum Guide 2020. Một Scrum Team thường có mười người hoặc ít hơn, và làm việc theo sprint: các sự kiện có độ dài cố định một tháng hoặc ngắn hơn, bắt đầu ngay khi sprint trước kết thúc.
Mỗi sprint có bốn sự kiện. Sprint Planning (tối đa tám giờ cho sprint một tháng) đặt Sprint Goal và chọn công việc. Daily Scrum là buổi kiểm tra 15 phút dành cho Developers. Sprint Review (tối đa bốn giờ) trình bày kết quả cho các bên liên quan, và Sprint Retrospective (tối đa ba giờ) xem lại cách nhóm đã làm việc.
Scrum có ba artifact, mỗi cái gắn với một cam kết: Product Backlog (Product Goal), Sprint Backlog (Sprint Goal) và Increment (Definition of Done).
Kanban là gì
Kanban Guide định nghĩa Kanban là “một chiến lược tối ưu hóa dòng chảy giá trị qua một quy trình”. Nó bắt nguồn từ hệ thống thẻ mà Toyota dùng để báo hiệu khi nào cần sản xuất thêm, và được điều chỉnh cho công việc tri thức vào những năm 2000.
Nó có ba thực hành: xác định và trực quan hóa quy trình làm việc, chủ động quản lý các hạng mục trong đó, và cải tiến nó. Quy tắc cứng duy nhất là những người trong hệ thống kiểm soát rõ ràng số hạng mục đang làm giữa lúc bắt đầu và lúc xong: giới hạn việc đang làm (WIP limit).
Kanban không quy định vai trò, sprint hay cuộc họp. Nó theo dõi bốn thước đo dòng chảy: việc đang làm, throughput, tuổi của hạng mục công việc và cycle time.
Ưu và nhược điểm
Scrum
- Nhịp cố định: ai cũng biết khi nào đến hạn kết quả tiếp theo
- Mục tiêu rõ ràng cho mỗi sprint giữ nhóm không bị trôi
- Có sẵn những thời điểm để xem xét sản phẩm và quy trình
- Bốn sự kiện mỗi sprint là chi phí thời gian thật sự với nhóm hai hay ba người
- Việc gấp hoặc phải chờ sprint sau, hoặc phá vỡ kế hoạch
- Cần có người cho mỗi trách nhiệm, điều một founder không thể tự chia
Kanban
- Bắt đầu ngay trên bảng bạn đang có; không cần cài gì ngoài một WIP limit
- Có thể kéo việc mới vào bất cứ lúc nào
- Thước đo dòng chảy cho thấy công việc bị kẹt ở đâu
- Không có hạn chót hay mục tiêu sẵn, nên việc kéo dài có thể bị trôi
- Không có WIP limit thì nó chỉ là danh sách việc cần làm chia cột
- Việc lên kế hoạch trước hoàn toàn do nhóm tự lo
Nên chọn cái nào
- Nhóm sản phẩm năm đến mười người với lộ trình ổn định
- Scrum. Các sự kiện xứng đáng khi nhiều người cần thống nhất một mục tiêu mỗi vài tuần.
- Hỗ trợ khách hàng, vận hành, hoặc nhóm sống nhờ các yêu cầu gửi đến
- Kanban. Việc đến lúc nào thì đến lúc đó; một WIP limit và cột Done rõ ràng quan trọng hơn kế hoạch sprint.
- Founder làm một mình hoặc nhóm hai đến năm người
- Scrumban. Giữ một bảng liên tục có WIP limit, và dùng sprint một hoặc hai tuần làm mục tiêu ngắn hạn, không cần đủ bộ sự kiện Scrum.
Scrumban: điểm cân bằng
Scrumban được Corey Ladas mô tả như một cách để nhóm Scrum chuyển sang dòng chảy dựa trên cơ chế kéo (pull). Trong thực tế, đó là một bảng Kanban có WIP limit không bao giờ đặt lại, cộng với sprint như các khung thời gian tùy chọn gom một phần công việc. Hướng dẫn đầy đủ của chúng tôi trình bày các quy tắc và cách thiết lập bảng: Scrumban là gì?
Khi AI agent làm một phần công việc
Nếu ChatGPT, Claude, Cursor hay Codex nhận việc thay bạn, các sự kiện của Scrum không có ai tham dự: agent không đi họp standup. Điều vẫn quan trọng là những gì Kanban mang lại: một bảng cho thấy việc gì đang làm, một WIP limit để không bắt đầu mười việc cùng lúc, và một quy tắc rõ ràng khi nào một thẻ là xong.
Điểm nghẽn cũng dịch chuyển. Agent làm xong việc rất nhanh, và bước chậm trở thành việc bạn xem lại những gì chúng đã làm. Một giới hạn cho số việc đã xong được phép chờ bạn chính là WIP limit cho cột của con người.
Weft là bảng Scrumban được xây cho điều này: cột, sprint tùy chọn, giới hạn số việc đã xong được phép chờ bạn xem lại, và một AI nhận việc trước khi bắt đầu, báo tiến độ, và dừng lại hỏi bạn khi chỉ bạn mới quyết định được.
Câu hỏi
Scrum và Kanban có giống nhau không?
Không. Cả hai đều là cách tiếp cận agile và đều hay dùng bảng, nhưng Scrum lên kế hoạch công việc theo sprint cố định với vai trò và sự kiện định sẵn, còn Kanban có dòng chảy liên tục, không quy định vai trò và có giới hạn rõ ràng cho việc đang làm.
Kanban có chạy sprint không?
Bản thân Kanban thì không: Kanban Guide không quy định vòng lặp nào. Những nhóm thêm sprint vào bảng Kanban thường đang làm Scrumban.
Một sprint Scrum diễn ra thế nào?
Sprint là một khoảng thời gian cố định một tháng hoặc ngắn hơn. Nó bắt đầu bằng Sprint Planning, nơi đặt Sprint Goal; Developers họp Daily Scrum 15 phút; nó kết thúc bằng Sprint Review về kết quả và Sprint Retrospective về quy trình, rồi sprint tiếp theo bắt đầu ngay.
Ai đã nghĩ ra Scrumban?
Thuật ngữ này được ghi công cho Corey Ladas, người đã mô tả Scrumban trong các bài tiểu luận và một cuốn sách năm 2009 như một cách để nhóm Scrum chuyển sang cơ chế kéo kiểu Kanban.
Scrum có phải là Agile không?
Không. Agile là tập hợp giá trị và nguyên tắc trong Agile Manifesto năm 2001; Scrum và Kanban là hai cách làm việc cụ thể tuân theo chúng.
Lập trình viên làm một mình có dùng Scrum được không?
Không đúng như cách nó được viết: Scrum giả định một nhóm có ba trách nhiệm tách biệt. Lập trình viên làm một mình thường giữ những phần có ích, một backlog và một mục tiêu sprint ngắn, và vận hành bảng theo kiểu Kanban — đó chính là Scrumban.
Nguồn
Đọc ngày 11 tháng 11, 2026.