Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa gia nhập một team phát triển sản phẩm với vai trò Business Analyst. Ngày đầu tiên, Scrum Master mở JIRA lên và hỏi: "Em muốn nhìn backlog trên board nào? Mình đang chạy Scrum nhưng team Support thì dùng Kanban." Nếu bạn không hiểu rõ sự khác biệt giữa hai loại board này, bạn sẽ rất khó tham gia vào các buổi planning, refinement, hay đơn giản là theo dõi xem story mình viết ra đang nằm ở đâu trong quy trình.
Board trong JIRA không chỉ là một bảng kéo-thả màu mè. Nó là tấm gương phản chiếu cách team bạn vận hành. Một Scrum board nói lên rằng team làm việc theo nhịp sprint cố định, cam kết một lượng công việc nhất định trong khoảng thời gian định trước. Một Kanban board lại nói rằng team làm việc theo dòng chảy liên tục, ưu tiên tốc độ phản hồi và giới hạn việc đang làm dở.
Với một BA, hiểu board không phải để "vọc tool cho vui". Nó quyết định cách bạn cấu trúc backlog, cách bạn viết và sắp xếp user story, cách bạn truyền đạt tiến độ cho stakeholder, và cách bạn nhận biết khi nào team đang bị nghẽn. Bài này sẽ giúp bạn phân biệt rạch ròi Scrum board và Kanban board, hiểu khi nào chọn loại nào, và biết cách đọc một board như một người làm nghề thực thụ.
Khái niệm cốt lõi
Board là gì trong JIRA
Trong JIRA, board là một giao diện trực quan hiển thị các issue (story, task, bug...) dưới dạng các thẻ (card) được sắp xếp theo cột (column). Mỗi cột thường tương ứng với một trạng thái (status) trong workflow. Khi một issue chuyển trạng thái, thẻ của nó di chuyển từ cột này sang cột khác.
Điểm quan trọng cần nhớ: board chỉ là một góc nhìn (view). Dữ liệu thật sự nằm ở các issue. Một dự án có thể có nhiều board cùng nhìn vào một tập issue, mỗi board phục vụ một nhóm người khác nhau. Board được điều khiển bởi một filter (bộ lọc JQL) — filter quyết định issue nào xuất hiện trên board đó.
JIRA cung cấp hai loại board chính: Scrum board và Kanban board. Cả hai đều hiển thị thẻ theo cột, nhưng triết lý vận hành phía sau hoàn toàn khác nhau.
Scrum Board — làm việc theo nhịp (timebox-based)
Scrum board được thiết kế cho team làm việc theo sprint — những chu kỳ thời gian cố định, thường kéo dài từ 1 đến 4 tuần (phổ biến nhất là 2 tuần). Triết lý cốt lõi là: team cam kết một lượng công việc cụ thể cho mỗi sprint, rồi tập trung hoàn thành đúng lượng đó trong khung thời gian định sẵn.
Đặc trưng nhận diện một Scrum board:
- Có một khu vực Backlog riêng biệt, nơi BA và Product Owner sắp xếp thứ tự ưu tiên các story chưa được đưa vào sprint.
- Có khái niệm Sprint — bạn tạo sprint, kéo story vào sprint, rồi bấm "Start Sprint".
- Khi sprint đang chạy, board chỉ hiển thị các issue thuộc sprint hiện tại.
- Có Sprint Report và Burndown Chart đi kèm để đo lường tiến độ.
Backlog To Do In Progress In Review Done
Trong đó, Backlog là kho chứa công việc tương lai, còn To Do → In Progress → In Review → Done là hành trình của một issue trong sprint hiện tại. Mỗi sáng đứng họp daily standup, team nhìn vào các cột này để biết ai đang làm gì, cái gì đang kẹt ở In Review.
Scrum board phù hợp khi: công việc có thể lập kế hoạch trước được, team muốn một nhịp giao hàng đều đặn, và stakeholder cần biết "cuối sprint này sẽ có gì".
Kanban Board — làm việc theo dòng chảy (flow-based)
Kanban board không có sprint, không có timebox. Triết lý cốt lõi là dòng chảy liên tục (continuous flow): công việc cứ đến là kéo vào, làm xong cái nào ship cái đó, không chờ đến cuối chu kỳ.
Đặc trưng nhận diện một Kanban board:
- Không có nút "Start Sprint" — công việc luôn ở trạng thái "đang chảy".
- Có khái niệm WIP Limit (Work In Progress Limit) — giới hạn số lượng thẻ tối đa được phép nằm trong một cột tại một thời điểm. Đây là trái tim của Kanban.
- Có thể có cột Backlog tích hợp ngay trên board (gọi là Kanban backlog), không tách riêng như Scrum.
- Đo lường bằng Cumulative Flow Diagram và Cycle Time thay vì burndown.
To Do In Progress (3) In Review (2) Done
Con số trong ngoặc là WIP limit. Nếu cột "In Progress" đã có 3 thẻ, team không được kéo thêm thẻ thứ 4 vào — buộc phải hoàn thành bớt trước. Điều này ngăn team "ôm đồm" quá nhiều việc dở dang cùng lúc, giúp lộ ra điểm nghẽn (bottleneck) rất nhanh.
Kanban board phù hợp khi: công việc đến không đều và khó dự đoán (như đội Support, vận hành, bug-fixing), ưu tiên là rút ngắn thời gian phản hồi, và team không cần ràng buộc vào nhịp sprint.
So sánh nhanh Scrum vs Kanban
| Tiêu chí | Scrum Board | Kanban Board |
|---|---|---|
| Đơn vị thời gian | Sprint cố định (1–4 tuần) | Không có, dòng chảy liên tục |
| Cam kết | Cam kết theo sprint | Không cam kết theo lô |
| Giới hạn việc | Bằng sprint scope | Bằng WIP Limit theo cột |
| Backlog | Tách riêng, có refinement | Tích hợp trên board |
| Đo lường chính | Burndown, Velocity | Cycle Time, Cumulative Flow |
| Reset board | Mỗi đầu sprint | Không bao giờ reset |
| Phù hợp với | Phát triển tính năng theo kế hoạch | Support, vận hành, luồng việc bất định |
Tình huống thực tế
Ví dụ 1 — Tiki: đội phát triển tính năng chọn Scrum
Một đội sản phẩm tại Tiki phụ trách tính năng "Tiki Xu" (điểm thưởng tích lũy) gồm 8 người: 1 PO, 1 BA (là bạn), 4 developer, 1 tester, 1 designer. Roadmap tính năng đã được lãnh đạo duyệt cho cả quý, công việc rõ ràng và lập kế hoạch được.
Team chọn Scrum board với sprint 2 tuần. Là BA, bạn duy trì backlog gồm khoảng 40 story. Mỗi sprint, trong buổi planning, team kéo khoảng 12–15 story (tương đương 30 story point) từ backlog vào sprint. Board hiển thị đúng 5 cột: Backlog | To Do | In Progress | In Review | Done.
Đến giữa sprint, burndown chart cho thấy đường tiến độ đang nằm trên đường lý tưởng — nghĩa là team đang chậm. Nhờ nhìn board, bạn phát hiện 4 story bị kẹt ở cột "In Review" vì chỉ có một senior dev review code. BA phối hợp với Scrum Master đề xuất thêm người review.
Bài học rút ra: Scrum board cho phép đo lường cam kết theo sprint và phát hiện sớm rủi ro không kịp tiến độ. Backlog tách riêng giúp BA tự do sắp xếp ưu tiên mà không làm rối board của sprint đang chạy.
Ví dụ 2 — VNG: đội vận hành game chọn Kanban
Một đội Live Operations của VNG vận hành một tựa game mobile. Công việc của họ là xử lý sự cố, yêu cầu cân bằng game, và lỗi do người chơi báo. Đặc điểm: việc đến bất chợt, không đoán trước được — hôm nay có thể 3 ticket, mai có thể 20 ticket sau một bản update.
Ép đội này vào sprint 2 tuần là vô lý, vì không thể "cam kết" trước sẽ có bao nhiêu sự cố. Họ chọn Kanban board với các cột: Backlog | Selected for Dev | In Progress (WIP 3) | Testing (WIP 2) | Done.
WIP Limit phát huy tác dụng ngay. Một tuần nọ, cột "Testing" liên tục đầy 2 thẻ, các thẻ ở "In Progress" làm xong nhưng không thể đẩy sang được. Board "đỏ rực" ở cột Testing. Nhìn cumulative flow diagram, BA chỉ ra rằng dải băng màu của trạng thái Testing đang phình to — dấu hiệu rõ ràng rằng khâu kiểm thử là điểm nghẽn. Quản lý quyết định bổ sung một tester. Cycle time trung bình giảm từ 5 ngày xuống 3 ngày trong tháng sau.
Bài học rút ra: Kanban board với WIP Limit biến điểm nghẽn thành thứ "nhìn thấy được". Với công việc bất định, Kanban giúp team phản ứng nhanh mà không bị gò bó bởi kế hoạch sprint.
Ví dụ 3 — Một startup fintech chuyển từ Scrum sang Kanban một phần
Một startup fintech ở Singapore với 25 nhân sự kỹ thuật ban đầu chạy toàn bộ team theo Scrum. Nhưng sau 6 tháng, đội Customer Support Engineering than phiền rằng họ luôn bị "vỡ sprint": cứ giữa sprint là có sự cố khẩn cấp từ khách hàng, kéo họ ra khỏi công việc đã cam kết.
Là BA hỗ trợ nhiều team, bạn nhận ra vấn đề: bản chất công việc của đội Support không phù hợp với mô hình cam kết theo sprint. Đề xuất được đưa ra: giữ Scrum cho 3 đội phát triển tính năng, nhưng chuyển đội Support sang Kanban board riêng với WIP Limit chặt. Cả hai loại board vẫn nhìn vào cùng một dự án JIRA, chỉ khác filter và cấu hình.
Sau khi chuyển, đội Support không còn khái niệm "vỡ sprint" nữa — việc gì khẩn thì kéo lên đầu cột To Do, WIP Limit đảm bảo họ không ôm quá nhiều cùng lúc. SLA phản hồi cải thiện 40%.
Bài học rút ra: Trong cùng một tổ chức, các team khác nhau có thể dùng loại board khác nhau. Vai trò của BA là nhận diện bản chất công việc để tư vấn đúng loại board, thay vì áp một mô hình cho tất cả.
Hướng dẫn từng bước
Dưới đây là quy trình tạo và đọc một board trên JIRA (giao diện JIRA Cloud, áp dụng tương tự cho Data Center).
Bước 1 — Xác định bản chất công việc của team. Trước khi tạo board, hãy hỏi: công việc có lập kế hoạch trước được không? Có cần nhịp giao hàng đều đặn không? Nếu có → Scrum. Nếu việc đến bất định, ưu tiên tốc độ phản hồi → Kanban.
Bước 2 — Tạo board. Vào dự án, chọn menu bên trái, tìm phần Boards → Create board. JIRA sẽ hỏi bạn chọn Scrum board hay Kanban board. Tiếp đó chọn nguồn dữ liệu: tạo board từ một project có sẵn, hoặc từ một filter (board sẽ hiển thị mọi issue khớp filter đó).
Bước 3 — Cấu hình cột (Columns). Vào Board settings → Columns. Mỗi cột map tới một hoặc nhiều status. Hãy đảm bảo các status trong workflow đều được gán vào đúng cột, nếu không issue sẽ "biến mất" khỏi board. Ví dụ map: status "Code Review" và "QA Review" cùng vào cột "In Review".
Bước 4 (chỉ Kanban) — Đặt WIP Limit. Trong Board settings → Columns, mỗi cột có ô đặt Max (giới hạn tối đa) và Min. Đặt WIP Limit hợp lý — quy tắc kinh nghiệm là khoảng bằng số người có thể làm việc song song ở cột đó, cộng một chút dư. Khi cột vượt giới hạn, JIRA sẽ tô đỏ để cảnh báo.
Bước 5 (chỉ Scrum) — Tạo và bắt đầu sprint. Vào tab Backlog, bấm Create Sprint, kéo các story từ backlog vào sprint, rồi bấm Start Sprint, đặt tên, mục tiêu (sprint goal) và thời lượng. Board sẽ chỉ hiển thị issue của sprint đang chạy.
Bước 6 — Cấu hình swimlane (làn ngang). Trong Board settings → Swimlanes, bạn có thể chia board theo Epic, theo Assignee, hoặc theo Story. Với BA, chia swimlane theo Epic rất hữu ích để thấy từng nhóm tính năng đang tiến tới đâu.
Bước 7 — Đọc board hằng ngày. Quét từ phải sang trái (Done về To Do). Để ý thẻ nào nằm quá lâu ở một cột — đó là dấu hiệu bị kẹt. Với Kanban, để ý cột nào chạm WIP Limit. Với Scrum, đối chiếu với burndown để xem nhịp độ.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm board với project. Nhiều người mới nghĩ "xóa board là mất dữ liệu". Sai. Board chỉ là view; xóa board không xóa issue. Bạn có thể tạo lại board mới nhìn vào cùng tập issue bất cứ lúc nào.
Lỗi 2 — Status không được map vào cột. Triệu chứng kinh điển: một issue có thật nhưng không thấy trên board. Nguyên nhân thường là status của nó chưa được gán vào cột nào trong Board settings. Hãy kiểm tra phần Columns đầu tiên.
Lỗi 3 — Đặt WIP Limit quá lỏng (hoặc bỏ trống). WIP Limit bằng 99 thì cũng như không có. Mục đích của WIP là tạo "sức ép tích cực" để team hoàn thành việc dở trước khi nhận việc mới. Đặt chặt thì điểm nghẽn mới lộ ra.
Lỗi 4 — Cố ép team Support vào Scrum. Như ví dụ fintech, áp Scrum cho công việc bất định gây "vỡ sprint" liên tục, làm team mất niềm tin vào quy trình. Đúng bản chất việc thì chọn đúng board.
Lỗi 5 — Filter của board quá rộng hoặc quá hẹp. Board được điều khiển bởi filter. Filter sai khiến board hiển thị thừa issue của project khác, hoặc thiếu issue cần thấy. Hãy kiểm tra filter trong Board settings → General.
Mẹo cho BA:
- Dùng Quick Filters để lọc nhanh ngay trên board (ví dụ: chỉ hiện story của một Epic, chỉ hiện issue gán cho mình).
- Đặt swimlane theo Epic khi present tiến độ cho stakeholder — họ sẽ hiểu "tính năng X xong đến đâu" thay vì nhìn rừng thẻ.
- Khi chưa chắc chọn Scrum hay Kanban, có thể bắt đầu bằng Kanban (đơn giản hơn), rồi chuyển sang Scrum khi team đã ổn định nhịp làm việc.
Bài tập thực hành
- Phân loại tình huống. Cho ba team sau, hãy quyết định mỗi team nên dùng Scrum board hay Kanban board và giải thích lý do trong 1–2 câu: (a) đội phát triển tính năng mới cho app ngân hàng theo roadmap quý; (b) đội xử lý ticket hỗ trợ khách hàng; (c) đội nội dung marketing chạy chiến dịch theo từng đợt 2 tuần.
- Thiết kế cột. Vẽ ra cấu trúc cột cho một Kanban board của đội QA, kèm WIP Limit hợp lý cho mỗi cột. Giải thích vì sao bạn chọn con số WIP đó.
- Thực hành trên JIRA. Nếu bạn có tài khoản JIRA (có thể đăng ký bản free), hãy tạo một Scrum board và một Kanban board cho cùng một project. Kéo thử vài issue qua các cột và quan sát sự khác biệt: Scrum yêu cầu Start Sprint, Kanban thì không.
- Đọc điểm nghẽn. Mô tả một tình huống board "đỏ" ở cột In Review (Scrum) hoặc Testing (Kanban). Bạn sẽ đề xuất hành động gì với Scrum Master để giải tỏa điểm nghẽn?
- Tự phản tư. Team hiện tại của bạn (hoặc team trong mơ) đang dùng loại board nào? Nó có thật sự phù hợp với bản chất công việc không, hay đang bị áp đặt? Viết một đoạn ngắn lập luận.
Tóm tắt
Board trong JIRA là tấm gương phản chiếu cách team vận hành, và là công cụ làm việc hằng ngày của BA. Có hai loại chính:
- Scrum board vận hành theo nhịp sprint cố định (1–4 tuần), có backlog tách riêng, đo bằng burndown và velocity. Tối ưu cho khả năng dự báo — phù hợp công việc lập kế hoạch trước được như phát triển tính năng theo roadmap.
- Kanban board vận hành theo dòng chảy liên tục, không có sprint, dùng WIP Limit để kiểm soát việc dở dang và phơi bày điểm nghẽn, đo bằng cycle time và cumulative flow. Tối ưu cho tốc độ phản hồi — phù hợp công việc bất định như Support, vận hành.