Mở đầu — vì sao bài này quan trọng
Khi bạn ngồi vào kỳ thi PSM I, sẽ có một vài câu hỏi cố tình "gài" bạn bằng cách trộn lẫn khái niệm của Scrum với Kanban. Ví dụ kinh điển: "Trong Scrum, đội nên dùng một bảng Kanban để giới hạn công việc đang làm (WIP limit) phải không?" Câu trả lời "by the book" không đơn giản là Có hay Không — nó đòi hỏi bạn hiểu rõ Scrum là gì, Kanban là gì, và ranh giới giữa hai khái niệm này nằm ở đâu.
Đây là một vùng kiến thức mà rất nhiều thí sinh người Việt mất điểm oan, vì trên thực tế ở các công ty Việt Nam, hai từ "Scrum" và "Agile" và "Kanban" thường bị dùng lẫn lộn. Bạn nghe sếp nói "team mình làm Scrum" nhưng thực ra cái team đó đang dùng một bảng Trello kéo thẻ qua lại mà không có Sprint, không có Sprint Goal, không có Retrospective. Khi bạn đã quen với "Scrum thực tế bị biến dạng" ở công ty, bạn rất dễ chọn sai đáp án trong phòng thi vốn yêu cầu "Scrum theo đúng Scrum Guide".
Bài này giúp bạn tách bạch ba thứ: Scrum (một framework dựa trên empiricism với cadence cố định), Kanban (một phương pháp tối ưu dòng chảy công việc), và Scrumban (cách kết hợp hai thứ). Mục tiêu không phải để bạn trở thành chuyên gia Kanban — PSM I không kiểm tra điều đó — mà để bạn không bị nhầm lẫn khi đề thi cố tình đặt Kanban cạnh Scrum.
Khái niệm cốt lõi
Scrum là gì — nhìn lại nhanh
Scrum là một framework gọn nhẹ (lightweight framework) giúp con người, đội nhóm và tổ chức tạo ra giá trị thông qua các giải pháp thích ứng (adaptive solutions) cho những vấn đề phức tạp. Điểm cốt lõi để phân biệt với Kanban nằm ở những đặc trưng sau:
- Dựa trên cadence (nhịp cố định): Scrum vận hành theo Sprint — một timebox cố định, thường từ 1 đến 4 tuần. Mọi việc lập kế hoạch, kiểm tra và thích ứng đều "gắn neo" vào nhịp Sprint này.
- Ba commitments: Product Goal (cho Product Backlog), Sprint Goal (cho Sprint Backlog), và Definition of Done (cho Increment).
- Năm events: The Sprint (event bao trùm), Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
- Ba accountabilities: Product Owner, Scrum Master, Developers.
- Trọng tâm: tạo ra một Increment "Done", có thể release được, ít nhất một lần mỗi Sprint; thanh tra và thích ứng theo nhịp.
Kanban là gì
Kanban (xuất phát từ hệ thống sản xuất của Toyota, tiếng Nhật nghĩa là "tấm thẻ tín hiệu") là một phương pháp quản lý dòng chảy công việc, tập trung vào việc trực quan hóa và tối ưu luồng (flow) thay vì tổ chức công việc theo từng đợt cố định. Những đặc trưng cốt lõi:
- Dựa trên flow (dòng chảy liên tục): Không có timebox bắt buộc. Công việc được kéo (pull) qua các cột trên bảng khi có năng lực tiếp nhận, thay vì được "đẩy" theo lô.
- Trực quan hóa công việc (visualize the workflow): Một bảng Kanban với các cột như "To Do → In Progress → Review → Done" để mọi người thấy rõ trạng thái.
- Giới hạn WIP (Work In Progress limit): Đây là trái tim của Kanban — giới hạn số lượng việc được làm đồng thời ở mỗi cột, nhằm giảm tình trạng "ôm nhiều việc, không xong việc nào".
- Quản lý flow và đo lường: Các chỉ số đặc trưng là Cycle Time (thời gian một item đi từ bắt đầu đến hoàn thành) và Throughput (số item hoàn thành trong một khoảng thời gian).
- Cải tiến liên tục (kaizen): thay đổi từ từ, tiệm tiến, không cần "đại tu" vai trò hay cấu trúc.
So sánh trực diện Scrum vs Kanban
| Tiêu chí | Scrum | Kanban |
|---|---|---|
| Nhịp làm việc | Cadence — Sprint timebox cố định | Flow — liên tục, không timebox |
| Cách lấy việc | Cam kết theo Sprint (Sprint Planning) | Kéo (pull) khi có năng lực |
| Vai trò | 3 accountabilities (PO, SM, Devs) | Không quy định vai trò |
| Sự kiện | 5 events | Không bắt buộc sự kiện nào |
| Commitments | Product Goal, Sprint Goal, DoD | Không có (nhưng có chính sách rõ ràng) |
| Giới hạn WIP | Không bắt buộc (do team tự quyết) | Bắt buộc, là nguyên lý cốt lõi |
| Thay đổi giữa chu kỳ | Sprint Backlog không nên bị thay đổi gây hại Sprint Goal | Có thể tái ưu tiên bất cứ lúc nào |
| Chỉ số tiêu biểu | Velocity (tùy chọn), tiến độ tới Sprint Goal | Cycle Time, Throughput, WIP |
Scrumban — sự kết hợp
Scrumban là cách kết hợp khung tổ chức của Scrum với các kỹ thuật quản lý flow của Kanban. Hiểu đơn giản: bạn vẫn giữ Sprint, các events, các accountabilities và commitments của Scrum, nhưng bổ sung thêm những công cụ từ Kanban như WIP limit, trực quan hóa workflow chi tiết, và đo Cycle Time để cải thiện cách công việc chảy qua đội trong Sprint.
Điểm mấu chốt cho PSM I: Scrum hoàn toàn cho phép bạn dùng các kỹ thuật của Kanban. Scrum Guide không cấm WIP limit, không cấm dùng bảng trực quan, không cấm đo Cycle Time. Scrum là một framework "có chủ ý chưa hoàn chỉnh" — nó định ra phần khung, còn bạn lấp đầy bằng kỹ thuật phù hợp. Vì thế, dùng Kanban bên trong Scrum không hề "vi phạm" Scrum, miễn là bạn không bỏ đi những phần cốt lõi của Scrum (Sprint, events, accountabilities, commitments).
Đây chính là cái bẫy của đề thi: nhiều người tin rằng "dùng Kanban thì không còn là Scrum nữa". Sai. Bạn chỉ không còn là Scrum khi bạn bỏ Sprint, bỏ Sprint Review, bỏ vai trò Product Owner... chứ không phải khi bạn thêm một WIP limit.
Tình huống thực tế
Ví dụ 1 — Startup fintech ở TP.HCM nhầm "kéo thẻ Trello" là Scrum
Một startup fintech khoảng 25 người ở Quận 1, TP.HCM, có một đội phát triển 6 người. Sếp kỹ thuật tuyên bố "team mình chạy Scrum". Nhưng khi quan sát kỹ: họ dùng một bảng Trello với các cột To Do / Doing / Done, kéo thẻ qua lại liên tục, không có Sprint, không có Sprint Planning, lập trình viên tự lấy việc bất cứ lúc nào, và "Retro" chỉ là buổi cà phê hai tháng một lần khi rảnh.
Diễn giải: Đây thực ra gần với Kanban hơn là Scrum — và còn là Kanban làm chưa tới, vì họ không đặt WIP limit, không đo Cycle Time. Nó cũng không phải Scrum vì thiếu toàn bộ cadence: không Sprint, không Sprint Goal, không Increment "Done" mỗi Sprint, không có ba accountabilities rõ ràng. Việc gọi nó là "Scrum" chỉ là cái nhãn marketing nội bộ.
Bài học rút ra: Trong phòng thi PSM I, nếu một câu hỏi mô tả một đội "kéo thẻ liên tục, không Sprint, không event", thì dù đề có gọi đó là "Scrum team", về bản chất nó không vận hành theo Scrum. Có Trello board không có nghĩa là có Scrum; có flow liên tục thì gần Kanban. Đừng để cái nhãn đánh lừa — hãy nhìn vào việc đội đó có giữ các phần cốt lõi của Scrum hay không.
Ví dụ 2 — Đội sản phẩm tại một công ty e-commerce Đông Nam Á bổ sung WIP limit vào Scrum
Một đội 7 Developers tại một sàn thương mại điện tử lớn (giả định kiểu Tiki/Shopee) chạy Scrum với Sprint 2 tuần đầy đủ: Sprint Planning, Daily Scrum, Review, Retro, có PO và SM. Vấn đề của họ: cuối mỗi Sprint luôn có 4–5 hạng mục dở dang vì ai cũng "ôm" 2–3 task cùng lúc. Trong một buổi Retrospective, đội quyết định thử áp WIP limit: mỗi cột "In Progress" và "Code Review" trên bảng chỉ cho phép tối đa 3 thẻ. Họ cũng bắt đầu đo Cycle Time trung bình của mỗi task.
Sau 4 Sprint, Cycle Time giảm từ trung bình 6,2 ngày xuống còn 3,8 ngày, và số hạng mục "carry over" sang Sprint sau giảm rõ rệt. Đội vẫn giữ nguyên Sprint, vẫn cam kết Sprint Goal, vẫn giao Increment "Done".
Diễn giải: Đây chính là Scrumban đúng nghĩa. Đội không bỏ Scrum — họ chỉ thêm một kỹ thuật của Kanban (WIP limit + đo Cycle Time) để cải thiện flow bên trong Sprint. Quyết định này nảy sinh tự nhiên từ Sprint Retrospective, đúng tinh thần "inspect and adapt".
Bài học rút ra: Thêm công cụ Kanban vào Scrum không làm bạn "rời khỏi" Scrum. Trong đề thi, một câu hỏi kiểu "Đội Scrum có được phép giới hạn WIP và dùng bảng Kanban không?" thì đáp án đúng là Có — Scrum không cấm, và đây là cách hợp lệ để cải thiện cách công việc chảy qua đội.
Ví dụ 3 — Đội vận hành/hỗ trợ chọn Kanban thay vì Scrum
Một công ty SaaS ở Hà Nội có một đội Operations 5 người chuyên xử lý sự cố hạ tầng và yêu cầu khẩn cấp từ khách hàng. Công việc của họ đến bất ngờ, không thể lập kế hoạch trọn vẹn cho hai tuần, mức độ ưu tiên thay đổi từng giờ. Họ từng cố ép mình vào Scrum nhưng thất bại: Sprint Goal liên tục bị phá vỡ vì sự cố P1 ập đến, Sprint Backlog phải thay đổi mỗi ngày.
Cuối cùng họ chuyển hẳn sang Kanban thuần: một bảng trực quan, WIP limit chặt, ưu tiên lại liên tục, đo Cycle Time và Throughput hàng tuần để báo cáo SLA.
Diễn giải: Bản chất công việc của đội này là "luồng yêu cầu đến ngẫu nhiên" chứ không phải "phát triển sản phẩm theo mục tiêu Sprint". Với loại công việc này, cadence cố định của Scrum gây cản trở hơn là giúp ích. Kanban — với flow liên tục và khả năng tái ưu tiên tức thời — phù hợp hơn nhiều.
Bài học rút ra: Scrum không phải lúc nào cũng là lựa chọn tốt nhất. Scrum mạnh nhất cho công việc phức tạp, hướng sản phẩm, có thể tổ chức quanh một mục tiêu (Goal). Kanban mạnh ở những luồng công việc liên tục, khó dự đoán, hướng dịch vụ. PSM I không yêu cầu bạn chọn giúp doanh nghiệp, nhưng việc hiểu "khi nào loại công việc nào hợp với cái nào" sẽ giúp bạn xử lý những câu hỏi tình huống tỉnh táo hơn.
Hướng dẫn từng bước
Khi gặp một câu hỏi PSM I trộn lẫn Scrum và Kanban, hãy đi theo trình tự tư duy sau:
- Xác định đề đang nói về framework nào. Đọc kỹ: đề mô tả Sprint, events, accountabilities (đó là Scrum) hay mô tả flow liên tục, WIP, pull (đó là Kanban)? Đừng tin cái nhãn, tin vào mô tả vận hành.
- Nhớ rằng Scrum Guide cố tình "im lặng" về kỹ thuật. Nếu câu hỏi là "Scrum có cho phép kỹ thuật X không?" (WIP limit, bảng trực quan, đo Cycle Time), thì đáp án mặc định nghiêng về "Có, Scrum không cấm" — miễn là kỹ thuật đó không phá vỡ phần cốt lõi của Scrum.
- Kiểm tra xem phần cốt lõi của Scrum có còn nguyên không. Một thứ vẫn là Scrum chừng nào còn giữ: Sprint (cadence), 5 events, 3 accountabilities, 3 commitments, và giao Increment "Done". Bỏ một trong những thứ này thì không còn là Scrum.
- Phân biệt "thêm vào" và "thay thế". Thêm WIP limit vào Scrum = vẫn là Scrum (Scrumban). Thay Sprint bằng flow liên tục = không còn là Scrum.
- Với câu hỏi tình huống, hỏi: bản chất công việc là gì? Phát triển sản phẩm phức tạp quanh một mục tiêu → Scrum hợp. Luồng dịch vụ/yêu cầu đến liên tục, ưu tiên thay đổi từng giờ → Kanban hợp. Cần cả hai → cân nhắc Scrumban.
- Chọn đáp án "by the book". PSM I luôn dựa trên Scrum Guide. Đừng chọn đáp án dựa trên cách công ty bạn đang làm — hãy chọn theo đúng định nghĩa chuẩn.
Lỗi thường gặp & mẹo
Lỗi 1 — Tin rằng "dùng Kanban là không còn Scrum". Đây là hiểu lầm phổ biến nhất. Scrum cho phép dùng các kỹ thuật Kanban bên trong nó. Mẹo: nhớ câu thần chú "Scrum là framework chưa hoàn chỉnh có chủ ý — bạn được phép thêm kỹ thuật".
Lỗi 2 — Nghĩ WIP limit là một quy định của Scrum. Không. WIP limit là nguyên lý cốt lõi của Kanban, không phải của Scrum. Scrum Guide không hề bắt buộc WIP limit. Đội Scrum có thể dùng nó, nhưng nó không nằm trong định nghĩa Scrum.
Lỗi 3 — Gọi mọi bảng kéo-thả là "Kanban" hoặc mọi bảng là "Scrum board". Một cái bảng chỉ là công cụ trực quan. Bản thân nó không quyết định bạn đang dùng framework nào. Bản chất nằm ở cách vận hành (cadence vs flow), không ở cái bảng.
Lỗi 4 — Nhầm Velocity với Throughput. Velocity (gắn với Scrum, mang tính tùy chọn) đo lượng công việc đội hoàn thành mỗi Sprint, thường tính bằng story points. Throughput (gắn với Kanban) đếm số item hoàn thành trong một khoảng thời gian. Chúng không thay thế cho nhau.
Lỗi 5 — Cho rằng Kanban có Product Owner hoặc Scrum Master. Kanban không quy định vai trò nào cả. Nếu đề nói "Trong Kanban, Product Owner chịu trách nhiệm về backlog", hãy cảnh giác — đó là đặc trưng của Scrum, không phải Kanban.
Mẹo ghi nhớ nhanh: Scrum = cadence (nhịp), Kanban = flow (dòng chảy), Scrumban = cadence + flow. Ba từ khóa này đủ để bạn xử lý phần lớn câu hỏi so sánh.
Bài tập thực hành
- Phân loại tình huống. Với mỗi mô tả sau, hãy xác định đó là Scrum, Kanban, hay Scrumban, và giải thích lý do:
- Bóc tách cái nhãn. Mô tả một đội ở công ty (thật hoặc giả định) mà bạn biết đang tự gọi là "Scrum". Liệt kê: họ có Sprint không? Có đủ 5 events không? Có 3 accountabilities không? Có giao Increment "Done" mỗi Sprint không? Từ đó kết luận họ thực sự đang làm Scrum, Kanban, hay một thứ lai tạp chưa rõ ràng.
- Trả lời câu hỏi kiểu thi. "Một đội Scrum muốn giới hạn số lượng công việc đang làm đồng thời để cải thiện dòng chảy. Điều này có được phép trong Scrum không?" Viết ra đáp án và lý do "by the book" của bạn.
- Tự kiểm tra phân biệt chỉ số. Giải thích bằng lời của bạn sự khác nhau giữa Velocity, Cycle Time và Throughput, mỗi chỉ số gắn với framework nào.
Tóm tắt
- Scrum là framework dựa trên cadence (Sprint timebox), với 5 events, 3 accountabilities, 3 commitments (Product Goal, Sprint Goal, DoD), trọng tâm là giao Increment "Done" theo nhịp và thanh tra–thích ứng.
- Kanban là phương pháp dựa trên flow liên tục, cốt lõi là trực quan hóa workflow và giới hạn WIP, đo Cycle Time và Throughput; không quy định vai trò hay sự kiện bắt buộc.
- Scrumban = giữ khung Scrum và thêm kỹ thuật Kanban (WIP limit, đo flow). Đây vẫn là Scrum, không phải sự "phản bội" Scrum.
- Điểm thi cốt lõi: Scrum Guide cố tình không quy định kỹ thuật cụ thể, nên Scrum cho phép dùng các công cụ Kanban bên trong nó. Bạn chỉ rời khỏi Scrum khi bỏ đi phần cốt lõi (Sprint, events, accountabilities, commitments).
- Đừng tin cái nhãn: một đội tự gọi là "Scrum" nhưng kéo thẻ liên tục không Sprint thì không vận hành theo Scrum. Hãy nhìn cách vận hành, không nhìn tên gọi.
- Ba từ khóa vàng: Scrum = cadence, Kanban = flow, Scrumban = cadence + flow.