Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi mười PM đang dùng Jira rằng "Board của bạn là Scrum hay Kanban?", bạn sẽ ngạc nhiên khi phần lớn trả lời theo kiểu "à, cứ tạo project rồi có board sẵn thôi, tôi không để ý". Và đó chính là gốc rễ của rất nhiều rắc rối sau này: team dùng board Scrum nhưng làm việc theo tư duy Kanban, hoặc ngược lại, dẫn đến các chỉ số bị sai lệch, họp hành lộn xộn, và quan trọng nhất là không ai đo được hiệu suất thật của đội.
Board (bảng công việc) trong Jira không chỉ là một cái màn hình đẹp để kéo-thả thẻ (drag-and-drop card). Nó là công cụ định hình cách làm việc của cả team. Chọn đúng loại board đồng nghĩa với việc bạn chọn đúng nhịp làm việc, đúng bộ chỉ số để đo, và đúng kiểu họp để điều phối. Chọn sai, bạn sẽ ép một đội vận hành cần sự linh hoạt tối đa vào khuôn khổ sprint cứng nhắc, hoặc để một đội phát triển sản phẩm trôi nổi không có cam kết rõ ràng.
Trong bài này, chúng ta sẽ đi sâu vào hai loại board cốt lõi của Jira — Scrum board và Kanban board — hiểu bản chất, so sánh trực diện, và quan trọng nhất là biết khi nào chọn cái nào. Đây là kiến thức nền tảng mà một PM giỏi phải nắm chắc trước khi bàn tới sprint planning, velocity hay backlog refinement ở các bài sau. Hãy xem đây là bài học "chọn đúng con đường trước khi bắt đầu đi".
Khái niệm cốt lõi
Board là gì trong Jira?
Trong Jira, một board là góc nhìn trực quan (visual view) hiển thị các issue (công việc) dưới dạng thẻ, được sắp xếp theo cột tương ứng với trạng thái công việc. Một điểm cực kỳ quan trọng mà nhiều người mới hiểu sai: board không phải là project. Board chỉ là một "cửa sổ" nhìn vào các issue, và bạn có thể tạo nhiều board khác nhau cùng nhìn vào một tập dữ liệu, được lọc bởi một câu truy vấn gọi là board filter (thường viết bằng JQL).
Điều này có nghĩa là một project có thể có nhiều board, và một board có thể gom issue từ nhiều project. Đây là sự linh hoạt rất mạnh mà chúng ta sẽ tận dụng ở các bài về multi-team.
Scrum board — làm việc theo nhịp sprint
Scrum board được thiết kế cho các đội làm việc theo sprint — những khoảng thời gian cố định (timebox) thường kéo dài 1 đến 4 tuần, phổ biến nhất là 2 tuần. Triết lý của Scrum board xoay quanh vài nguyên tắc:
- Cam kết đầu sprint (commit): Đầu mỗi sprint, team chọn ra một tập công việc từ backlog và cam kết hoàn thành trong sprint đó. Tập công việc này được "đóng băng" tương đối.
- Giao hàng cuối sprint (deliver): Cuối sprint, những gì cam kết được kỳ vọng hoàn thành và tạo ra giá trị có thể bàn giao.
- Reset giữa các sprint: Khi một sprint kết thúc, board được "dọn sạch" — các issue chưa xong được chuyển lại backlog hoặc sang sprint kế tiếp, và board bắt đầu lại cho sprint mới.
- Đo velocity: Vì mỗi sprint là một đơn vị đo cố định, Scrum board cho phép tính velocity — số story point trung bình team hoàn thành mỗi sprint — để dự báo năng lực tương lai.
Scrum board phù hợp với: đội phát triển sản phẩm có lộ trình rõ ràng, làm việc theo chu kỳ, có thể lập kế hoạch trước 2 tuần, và cần dự báo tiến độ dài hạn. Ví dụ điển hình là team xây dựng tính năng mới cho một app, một team làm dự án phần mềm cho khách hàng với các mốc bàn giao.
Kanban board — dòng chảy công việc liên tục
Kanban board đi theo triết lý hoàn toàn khác: dòng chảy liên tục (continuous flow), không có timebox, không có sprint. Công việc được kéo vào khi có năng lực, làm xong thì lấy tiếp việc mới — như một dây chuyền sản xuất chạy không nghỉ. Các đặc trưng cốt lõi:
- Không có sprint: Không có điểm bắt đầu/kết thúc cố định. Việc đến lúc nào làm lúc đó, ưu tiên theo mức độ khẩn cấp.
- WIP limit (giới hạn công việc đang làm): Đây là "trái tim" của Kanban. Bạn đặt giới hạn số issue tối đa được phép ở mỗi cột (ví dụ cột "In Progress" tối đa 3 thẻ). Khi cột đã đầy, không ai được kéo thêm việc vào cho tới khi có việc chảy sang cột kế tiếp. Nguyên tắc này ép team hoàn thành trước, bắt đầu sau (stop starting, start finishing).
- Đo cycle time và lead time: Thay vì velocity, Kanban đo thời gian một việc đi từ đầu đến cuối dòng chảy. Chúng ta sẽ học sâu về các chỉ số này ở bài 29.
- Không reset: Board chạy liên tục, không có chuyện "dọn board" định kỳ.
So sánh trực diện
Để bạn dễ hình dung, đây là bảng đối chiếu nhanh:
| Tiêu chí | Scrum board | Kanban board |
|---|---|---|
| Nhịp làm việc | Theo sprint (1–4 tuần) | Dòng chảy liên tục |
| Cam kết phạm vi | Cam kết đầu sprint | Kéo việc khi có năng lực |
| Kiểm soát tải | Số việc trong sprint | WIP limit theo cột |
| Chỉ số chính | Velocity, burndown | Cycle time, lead time, throughput |
| Reset board | Có, mỗi sprint | Không |
| Backlog view riêng | Có | Có (Kanban backlog, tùy cấu hình) |
| Phù hợp nhất | Phát triển sản phẩm có kế hoạch | Vận hành, support, việc đến bất chợt |
Tình huống thực tế
Tình huống 1 — Startup fintech ở TP.HCM chọn sai board
Một startup fintech tại Quận 1, TP.HCM (gọi là VietPay) có đội kỹ thuật 8 người, vừa lập project Jira mới. Theo mặc định họ dùng Scrum board vì "ai cũng bảo Agile là Scrum". Nhưng thực tế công việc của họ 70% là xử lý sự cố thanh toán khẩn cấp từ đối tác ngân hàng — những việc đến bất ngờ, phải xử lý trong ngày, không thể chờ tới sprint sau.
Kết quả sau 3 sprint: mỗi sprint họ cam kết 40 story point nhưng chỉ hoàn thành 22, vì liên tục phải "phá sprint" để nhét việc khẩn vào. Velocity nhảy loạn xạ (22, 31, 18), burndown chart trông như "răng cưa". PM báo cáo cho ban giám đốc rằng team làm không hiệu quả, trong khi thực tế team làm rất cật lực nhưng bị ép vào sai khuôn khổ.
Bài học: Khi hơn nửa khối lượng công việc là việc đến bất ngờ, không thể lên kế hoạch trước, Scrum là công cụ sai. Sau khi chuyển sang Kanban board với WIP limit cột "In Progress" là 4, team của VietPay đo được cycle time trung bình 1,8 ngày cho mỗi sự cố, và ban giám đốc lần đầu có con số thật để đánh giá. Board phải phục vụ cách team làm việc, không phải bắt team làm việc theo board.
Tình huống 2 — Team sản phẩm tại Tiki dùng Scrum đúng bài
Một team phát triển tính năng giỏ hàng của một sàn thương mại điện tử lớn (tình huống giả định dựa trên bối cảnh Tiki) gồm 6 kỹ sư, 1 PM, 1 designer. Công việc của họ là xây dựng tính năng mới theo roadmap quý — rõ ràng, có thể lập kế hoạch trước, ít bị gián đoạn đột xuất vì đã có team riêng lo phần vận hành/sự cố.
Họ dùng Scrum board với sprint 2 tuần. Đầu sprint, PM cùng team chọn khoảng 34 story point vào sprint dựa trên velocity trung bình 3 sprint gần nhất là 33. Cuối sprint có sprint review demo tính năng, có retrospective. Sau 6 sprint, velocity ổn định quanh mức 32–35, và PM có thể tự tin nói với sếp: "Với backlog hiện tại còn 210 point, team sẽ hoàn thành trong khoảng 6–7 sprint, tức là giữa tháng 9".
Bài học: Khi công việc có thể lập kế hoạch và team được bảo vệ khỏi gián đoạn, Scrum board phát huy tối đa sức mạnh: nhịp làm việc ổn định, velocity đáng tin, và khả năng dự báo cực kỳ giá trị cho việc lập kế hoạch sản phẩm. Đây chính là "đất diễn" lý tưởng của Scrum.
Tình huống 3 — Đội IT Helpdesk của một ngân hàng dùng Kanban
Đội IT nội bộ (12 người) của một ngân hàng tại Hà Nội nhận yêu cầu hỗ trợ từ toàn bộ nhân viên: cấp quyền truy cập, sửa lỗi máy tính, xử lý ticket phần mềm. Việc đến liên tục qua service desk, mức độ ưu tiên thay đổi từng giờ.
Họ dùng Kanban board với các cột: To Do → In Progress → Waiting for User → Done. WIP limit ở "In Progress" đặt là 8 (tương ứng năng lực thực tế của đội, khoảng 2 việc/người đang xử lý). Ban đầu đội hay bỏ dở việc để nhảy sang việc mới, khiến hàng chục ticket "treo" nửa chừng. Sau khi siết WIP limit, mỗi khi cột "In Progress" đầy 8 thẻ, không ai được kéo thêm — buộc phải đẩy việc đang dở cho xong. Trong 2 tháng, lượng ticket tồn giảm 35%, và cycle time trung bình từ 4,2 ngày xuống 2,6 ngày.
Bài học: WIP limit không phải là "sự giới hạn" tiêu cực — nó là công cụ ép team tập trung và hoàn thành. Với đội vận hành/support, đây là thứ Kanban mang lại mà Scrum không có. Đừng đặt WIP limit quá cao (vô nghĩa) hay quá thấp (nghẽn giả tạo); hãy bắt đầu từ năng lực thực tế của đội rồi tinh chỉnh.
Hướng dẫn từng bước
Dưới đây là quy trình thực tế để chọn và thiết lập board phù hợp trong Jira (giao diện Cloud, phiên bản mới với các "project type" như Team-managed và Company-managed):
Bước 1 — Phân tích bản chất công việc của team. Trước khi động vào Jira, trả lời 3 câu hỏi: (a) Công việc có thể lập kế hoạch trước 2 tuần không? (b) Team có bị gián đoạn bởi việc khẩn thường xuyên không? (c) Bạn cần dự báo tiến độ (velocity) hay cần tối ưu thời gian xử lý (cycle time)? Nếu (a) có, (b) không, (c) là dự báo → Scrum. Nếu (a) không, (b) có, (c) là thời gian xử lý → Kanban.
Bước 2 — Chọn template khi tạo project. Khi tạo project mới, Jira hỏi bạn chọn template. Chọn "Scrum" hoặc "Kanban" tương ứng. Với project đã tồn tại, bạn có thể tạo board mới độc lập bằng cách vào Boards → Create board và chọn loại.
Bước 3 — Cấu hình board filter. Vào Board settings → General. Đây là nơi định nghĩa issue nào hiển thị trên board bằng JQL (ví dụ project = ABC AND type != Epic). Đây là bước quyết định phạm vi board.
Bước 4 — Thiết lập các cột (columns). Vào Board settings → Columns. Ánh xạ (map) các status của workflow vào cột board. Với Kanban, đây cũng là nơi bạn đặt WIP limit cho từng cột (nhập giá trị Min/Max). Với Scrum, thường không cần WIP limit.
Bước 5 — Với Scrum: cấu hình ước lượng và sprint. Vào Board settings → Estimation, chọn đơn vị ước lượng (Story Points). Sau đó vào Backlog view, tạo sprint đầu tiên, kéo issue vào và bấm Start sprint (chọn độ dài 1–4 tuần).
Bước 6 — Với Kanban: bật Backlog và Kanban board. Kanban board trong Jira cũng có một cột "Backlog" hoặc một backlog view riêng để chứa việc chưa bắt đầu. Cấu hình cột "Done" để tự động ẩn issue cũ (ví dụ ẩn sau 14 ngày) giúp board gọn gàng.
Bước 7 — Kiểm chứng bằng dữ liệu sau 2–3 tuần. Đừng coi việc chọn board là quyết định vĩnh viễn. Sau vài tuần, nhìn vào velocity/burndown (Scrum) hoặc cycle time/cumulative flow (Kanban). Nếu chỉ số "loạn", đó là tín hiệu bạn có thể chọn sai loại board.
Lỗi thường gặp & mẹo
Lỗi 1 — Dùng Scrum board nhưng không thật sự chạy sprint. Rất nhiều team tạo sprint rồi để nó chạy vô thời hạn, không bao giờ close, không review. Đây là "Scrum giả": bạn có công cụ Scrum nhưng vận hành như Kanban lộn xộn. Nếu bạn không định cam kết và reset theo chu kỳ, hãy dùng Kanban.
Lỗi 2 — Bỏ qua WIP limit trên Kanban. Kanban mà không có WIP limit chỉ là một danh sách việc màu mè. Sức mạnh thật của Kanban nằm ở giới hạn công việc đang làm. Không đặt WIP limit = vứt bỏ 80% giá trị của phương pháp.
Lỗi 3 — Nghĩ rằng "Agile = Scrum". Kanban cũng hoàn toàn là Agile. Đừng để định kiến này ép đội vận hành vào sprint không cần thiết.
Lỗi 4 — Nhầm lẫn board với project. Nhớ rằng board chỉ là góc nhìn được lọc. Bạn có thể có một board Kanban cho team support và một board Scrum cho team dev cùng nhìn vào các project khác nhau.
Mẹo 1 — Bắt đầu với Kanban nếu bạn chưa chắc. Với team mới, chưa quen Agile, Kanban nhẹ nhàng hơn vì ít nghi thức. Bạn có thể trực quan hóa dòng chảy trước, rồi chuyển sang Scrum khi team đã trưởng thành và công việc ổn định.
Mẹo 2 — Có thể chạy hybrid (Scrumban). Một số team dùng sprint để lập kế hoạch nhưng vẫn áp WIP limit theo cột. Jira cho phép linh hoạt cấu hình này. Đừng coi Scrum và Kanban là hai lựa chọn loại trừ tuyệt đối.
Mẹo 3 — Đặt WIP limit từ năng lực thực, không đặt cảm tính. Công thức khởi đầu tốt: khoảng 1–2 việc đang làm trên mỗi thành viên. Đội 6 người → WIP limit "In Progress" khoảng 6–8. Rồi quan sát và tinh chỉnh.
Bài tập thực hành
- Phân loại tình huống: Với mỗi đội sau, hãy quyết định nên dùng Scrum hay Kanban board và giải thích trong 2–3 câu: (a) Đội marketing nội bộ chạy chiến dịch theo tháng; (b) Đội DevOps xử lý cảnh báo hệ thống 24/7; (c) Đội phát triển tính năng mới cho app đặt xe theo roadmap quý.
- Thiết lập thực tế: Tạo một project Jira miễn phí (Jira Cloud có gói free tới 10 người). Tạo một Kanban board, thêm 8 issue giả, cấu hình 4 cột với WIP limit ở cột "In Progress" là 3. Thử kéo issue thứ 4 vào cột đã đầy và quan sát cảnh báo Jira hiển thị.
- Chuyển đổi tư duy: Lấy chính công việc hiện tại của đội bạn (hoặc một đội bạn biết). Viết ra 5 loại việc thường gặp, đánh dấu việc nào "lập kế hoạch được" và việc nào "đến bất chợt". Dựa trên tỷ lệ, đề xuất loại board phù hợp và biện luận.
- Đọc chỉ số: Nếu velocity của một team Scrum là 25, 28, 12, 30, 9 qua 5 sprint, bạn nghi ngờ điều gì về cách team này đang làm việc? (Gợi ý: sự dao động lớn thường là dấu hiệu team bị gián đoạn — có thể họ hợp với Kanban hơn.)
Tóm tắt
Board trong Jira không phải là chi tiết kỹ thuật nhỏ nhặt — nó định hình cách cả team làm việc, đo lường và phối hợp. Scrum board phục vụ các đội làm việc theo sprint có timebox (1–4 tuần), cam kết phạm vi đầu sprint, giao hàng cuối sprint, reset giữa các chu kỳ và đo bằng velocity; phù hợp với phát triển sản phẩm có kế hoạch và cần dự báo. Kanban board phục vụ dòng chảy liên tục, không sprint, kiểm soát tải bằng WIP limit và đo bằng cycle time/lead time; phù hợp với đội vận hành, support và công việc đến bất chợt.
Nguyên tắc vàng: chọn board theo bản chất công việc của team, đừng ép team theo board. Khi phân vân, hãy phân tích ba yếu tố — khả năng lập kế hoạch, mức độ gián đoạn, và chỉ số bạn cần — rồi để dữ liệu sau 2–3 tuần xác nhận lựa chọn. Nắm chắc nền tảng này, bạn đã sẵn sàng đi sâu vào sprint planning, backlog refinement và các chỉ số hiệu suất ở những bài tiếp theo.