Mở đầu — vì sao bài này quan trọng
Khi mới tiếp cận Jira, hầu hết chúng ta chỉ nhìn thấy phần nổi của tảng băng: tạo issue, kéo thả trên board, đóng sprint. Nhưng nếu bạn đã từng làm PM (Product/Project Manager) trong một đội có 3-4 team cùng chạy song song, bạn sẽ nhanh chóng nhận ra rằng Jira "mặc định" gần như không bao giờ vừa với cách team bạn làm việc. Board hiển thị sai thứ tự cột, issue của team khác lọt vào sprint của mình, số liệu velocity nhảy loạn xạ, và mỗi lần họp retro lại có người phàn nàn "Jira của mình rối quá".
Gốc rễ của gần như tất cả những nỗi đau đó nằm ở phần cấu hình (configuration) — thứ mà phần lớn người dùng bỏ qua vì tưởng nó "của admin". Sự thật là: một PM giỏi Jira không phải là người tạo issue nhanh, mà là người biết thiết kế board và cấu hình filter sao cho toàn team nhìn vào là hiểu ngay việc gì đang chảy ở đâu.
Bài học này tập trung vào cấu hình board nâng cao — trái tim của trải nghiệm Jira hằng ngày. Chúng ta sẽ đi sâu vào cách một board thực sự được cấu tạo, sự khác biệt cốt lõi giữa Scrum board và Kanban board, cách kiểm soát column, swimlane, filter và các biểu đồ đo lường. Đây là nền tảng bắt buộc trước khi bạn bước sang những bài về JQL, workflow hay automation ở các phần sau của khóa học. Nắm chắc bài này, bạn sẽ tiết kiệm được hàng chục giờ "vật lộn" với Jira mỗi quý.
Khái niệm cốt lõi
Board thực chất là gì?
Điều đầu tiên và quan trọng nhất cần hiểu: trong Jira, một board không phải là nơi chứa dữ liệu — nó chỉ là một "ống kính" (lens) nhìn vào dữ liệu. Dữ liệu thật (các issue) nằm trong project. Board chỉ quyết định bạn nhìn thấy issue nào và bạn nhìn chúng theo cách nào.
Cách một board chọn issue để hiển thị chính là board filter — một câu truy vấn JQL (Jira Query Language) nằm phía sau mỗi board. Ví dụ, filter mặc định của một board có thể là project = "ECOM" ORDER BY Rank ASC. Chính vì board chỉ là lens, nên bạn hoàn toàn có thể tạo nhiều board khác nhau trên cùng một project — một board cho team Frontend, một board cho team Backend, một board tổng cho PM — mà không hề nhân bản dữ liệu.
Hiểu được điều này giúp bạn thoát khỏi hiểu lầm phổ biến nhất: nghĩ rằng "board thuộc về project". Không — board là công cụ của người xem, và bạn có quyền thiết kế nó.
Scrum Board — làm việc theo nhịp sprint
Scrum board được sinh ra cho các team làm việc theo chu kỳ cố định (sprint), thường 1-2 tuần. Luồng công việc điển hình:
Backlog → Sprint Planning → Board (đang chạy sprint) → Reports
- Backlog: nơi bạn chứa và sắp xếp thứ tự ưu tiên tất cả story/task chưa được đưa vào sprint. Đây là "kho" của PM.
- Sprint Planning: bạn kéo các item từ backlog vào một sprint, cam kết khối lượng công việc cho chu kỳ tới.
- Active Sprint (Board): chỉ hiển thị các issue trong sprint đang chạy, chia theo cột trạng thái (To Do / In Progress / Done).
- Reports: sau khi đóng sprint, bạn có velocity chart (đo năng lực team qua nhiều sprint) và burndown chart (đo tiến độ tiêu thụ công việc trong một sprint).
Kanban Board — dòng chảy liên tục
Kanban board dành cho team làm việc theo dòng chảy liên tục (continuous flow), không chia chu kỳ. Không có sprint, không có "planning" theo lô — việc đến là làm, xong là giao. Board này phù hợp với đội vận hành, support, maintenance, hoặc team sản phẩm ưu tiên tốc độ giao hàng liên tục.
Hai khái niệm cốt lõi chỉ Kanban mới có:
- WIP limit (Work-In-Progress limit): giới hạn số issue tối đa được phép nằm trong một cột. Nếu cột "In Progress" đặt WIP = 3 mà đang có 4 item, Jira sẽ tô đỏ cột để cảnh báo team đang ôm quá nhiều việc dở dang.
- Backlog column + Kanban backlog: Kanban board có thể bật một cột backlog ngay trên board hoặc một khu backlog riêng để lọc việc trước khi đưa vào dòng chảy.
Ba thành phần cấu hình quyết định trải nghiệm board
Dù là Scrum hay Kanban, ba thứ bạn sẽ tinh chỉnh nhiều nhất là:
- Columns & Statuses (Cột và trạng thái): Mỗi cột trên board map tới một hoặc nhiều status trong workflow. Điểm mấu chốt mà nhiều người bỏ sót: một cột có thể gộp nhiều status. Ví dụ cột "Done" có thể chứa cả status
ResolvedvàClosed. Nếu một status trong workflow không được map vào cột nào, issue mang status đó sẽ biến mất khỏi board — đây là nguyên nhân số một khiến người dùng hoảng loạn "issue của tôi đâu mất rồi?".
- Swimlanes (Làn bơi): chia board theo hàng ngang. Bạn có thể chia swimlane theo Assignee, theo Epic, theo Story, theo Priority, hoặc theo một truy vấn JQL tùy chỉnh. Đây là công cụ cực mạnh cho PM để tách bạch các dòng công việc.
- Quick Filters (Bộ lọc nhanh): các nút bấm nhanh phía trên board, mỗi nút là một mảnh JQL, giúp lọc tạm thời (chỉ hiện việc của tôi, chỉ hiện bug, chỉ hiện việc quá hạn) mà không đổi filter gốc.
Tình huống thực tế
Tình huống 1 — Tiki: một project, hai team, hai board
Giả sử tại một công ty thương mại điện tử như Tiki, project CHECKOUT được cả team Web và team Mobile dùng chung vì họ cùng phát triển luồng thanh toán. Ban đầu cả hai team chung một Scrum board. Kết quả: mỗi lần planning, backlog dài 200 item lẫn lộn cả việc web lẫn mobile, hai Scrum Master tranh nhau kéo item, velocity chart vô nghĩa vì đo chung năng lực của hai team có tốc độ rất khác nhau.
Cách xử lý bằng cấu hình: PM tạo hai board riêng trên cùng project. Board Web dùng filter project = CHECKOUT AND component = "Web" ORDER BY Rank ASC, board Mobile dùng component = "Mobile". Mỗi board có sprint riêng, velocity riêng. Dữ liệu vẫn nằm chung một project (thuận tiện cho báo cáo tổng), nhưng mỗi team có "ống kính" của mình.
Bài học: Khi hai nhóm có nhịp làm việc khác nhau, đừng nhồi vào một board. Board là lens — hãy tạo nhiều lens thay vì tách project một cách tốn kém.
Tình huống 2 — Startup fintech ở TP.HCM: issue "bốc hơi" sau khi thêm status mới
Một startup fintech khoảng 25 người thêm một status mới tên Code Review vào workflow để phản ánh đúng quy trình dev. Sáng hôm sau, cả team hoảng loạn: khoảng 12 issue đang review "biến mất" khỏi board, tưởng bị xóa. Ban giám đốc còn tưởng mất dữ liệu.
Nguyên nhân thật: status Code Review mới tạo chưa được map vào cột nào trên board. Trong Jira, issue mang status "mồ côi" (unmapped) sẽ không hiển thị. Dữ liệu vẫn còn nguyên trong database — chỉ là lens không nhìn thấy chúng.
Cách xử lý: Vào Board Settings → Columns, kéo status Code Review vào giữa cột "In Progress" và "Done" (hoặc tạo hẳn một cột "Review" mới). Ngay lập tức 12 issue xuất hiện trở lại.
Bài học: Mỗi khi thêm hoặc đổi status trong workflow, việc bắt buộc tiếp theo là kiểm tra column mapping của mọi board dùng project đó. Đây là quy trình hai bước không thể tách rời.
Tình huống 3 — Team support tại Base.vn: chuyển từ sprint sang dòng chảy
Một team chăm sóc khách hàng kỹ thuật dùng Scrum board 2 tuần. Nhưng công việc của họ là xử lý ticket đến bất chợt — không thể "lên kế hoạch cho 2 tuần tới". Kết quả: mỗi sprint đều vỡ kế hoạch, burndown chart lởm chởm, planning trở thành hình thức tốn thời gian.
Cách xử lý: PM chuyển team sang Kanban board, bỏ hoàn toàn khái niệm sprint. Đặt WIP limit = 5 cho cột "In Progress" để mỗi kỹ sư không ôm quá nhiều ticket cùng lúc. Dùng Cumulative Flow Diagram để phát hiện nghẽn.
Sau một tháng, họ phát hiện cột "Waiting for Customer" luôn phình to — nghĩa là điểm nghẽn nằm ở khâu chờ khách phản hồi, không phải năng lực team. Insight này chỉ lộ ra nhờ chọn đúng loại board.
Bài học: Loại board phải khớp với bản chất luồng công việc. Việc đến ngẫu nhiên thì dùng Kanban; việc lên kế hoạch được theo lô thì dùng Scrum. Chọn sai loại board khiến mọi số liệu trở nên vô nghĩa.
Hướng dẫn từng bước
Dưới đây là quy trình cấu hình một board nâng cao từ đầu. (Giao diện Jira Cloud có thể đổi vị trí menu theo thời gian, nhưng logic thì bất biến.)
Bước 1 — Xác định board filter. Trước khi tạo board, hãy tạo (hoặc chọn) một filter JQL định nghĩa rõ board này hiển thị issue nào. Ví dụ: project = ECOM AND type in (Story, Bug, Task) ORDER BY Rank ASC. Mệnh đề ORDER BY Rank là bắt buộc để tính năng kéo-thả sắp xếp ưu tiên hoạt động.
Bước 2 — Tạo board và chọn loại. Vào Boards → Create board, chọn Scrum hay Kanban tùy bản chất luồng công việc (dựa trên phân tích ở phần trên). Gắn board vào filter đã tạo ở Bước 1.
Bước 3 — Cấu hình Columns. Vào Board Settings → Columns. Tại đây bạn:
- Tạo/đổi tên/xóa cột.
- Kéo từng status vào đúng cột. Kiểm tra không status nào bị bỏ sót (unmapped).
- Với Kanban, đặt Min/Max cho từng cột để bật WIP limit.
- Cấu hình cột "Done": nên map cả các status kết thúc như
Resolved,Closed.
priority = Highest, làn "Còn lại" = mặc định. Sắp xếp thứ tự các làn hợp lý (khẩn nằm trên cùng).Bước 5 — Thiết lập Quick Filters. Vào Board Settings → Quick Filters. Thêm các nút thường dùng: "Việc của tôi" = assignee = currentUser(), "Chỉ Bug" = type = Bug, "Quá hạn" = due < now(). Mỗi nút chỉ là một mảnh JQL nối vào filter gốc.
Bước 6 — Cấu hình Card layout & Estimation. Trong Card Layout, chọn các trường hiển thị trên thẻ (ví dụ hiện thêm Epic Link, Due Date). Trong Estimation (Scrum), chọn đơn vị ước lượng — Story Points là tiêu chuẩn cho velocity.
Bước 7 — Kiểm tra Reports. Với Scrum, chạy thử một sprint và xem Burndown/Velocity có ra số liệu hợp lý không. Với Kanban, bật Cumulative Flow Diagram và Control Chart.
Lỗi thường gặp & mẹo
Lỗi 1 — Status không được map, issue biến mất. Như tình huống fintech phía trên. Mẹo: Sau mỗi lần chạm vào workflow, luôn mở Board Settings → Columns và xác nhận cột "Unmapped Statuses" trống.
Lỗi 2 — Quên ORDER BY Rank trong board filter. Nếu filter kết thúc bằng ORDER BY created hay bất cứ thứ gì khác, chức năng kéo-thả sắp xếp ưu tiên sẽ tắt và bạn không hiểu vì sao không kéo được thẻ. Mẹo: Board dùng để quản trị ưu tiên thì luôn kết thúc bằng ORDER BY Rank ASC.
Lỗi 3 — Nhầm board với project. Xóa board vì tưởng xóa dữ liệu, hoặc tạo project mới chỉ để có "góc nhìn" mới. Mẹo: Cần góc nhìn mới thì tạo board mới trên project cũ. Board rẻ và không đụng dữ liệu.
Lỗi 4 — Đặt WIP limit quá chặt hoặc bỏ hẳn. WIP = 1 khiến team tắc nghẽn giả tạo; không đặt WIP thì Kanban mất tác dụng. Mẹo: Bắt đầu với WIP ≈ số thành viên đang làm ở cột đó, rồi tinh chỉnh theo thực tế.
Lỗi 5 — Swimlane theo Assignee cho team lớn. Với 15 người, chia làn theo assignee tạo ra 15 làn dài lê thê. Mẹo: Team lớn nên chia làn theo Epic hoặc theo Query (nhóm ưu tiên) để nhìn được bức tranh dòng công việc thay vì bức tranh cá nhân.
Mẹo tổng quát cho PM: Hãy tạo một board tổng hợp cấp PM với swimlane theo team (bằng Query) và quick filter theo trạng thái rủi ro (quá hạn, blocked). Board này không dùng để dev làm việc mà để bạn nắm toàn cảnh trong các buổi sync.
Bài tập thực hành
Hãy thực hiện trên một project Jira thật (dùng bản Free Cloud nếu chưa có):
- Tạo dữ liệu nền: Tạo 12-15 issue gồm Story, Task, Bug với priority khác nhau trong một project.
- Bài tập Scrum board: Tạo một Scrum board với filter kết thúc bằng
ORDER BY Rank ASC. Cấu hình 4 cột: To Do / In Progress / Review / Done, trong đó cột Done map cảDonevàClosed. Đặt estimation là Story Points. Kéo 6 issue vào một sprint, start sprint, di chuyển vài thẻ qua các cột rồi complete sprint. Mở Velocity và Burndown chart quan sát.
- Bài tập Kanban board: Trên cùng project đó, tạo thêm một Kanban board (chứng minh cho bản thân rằng một project có nhiều board). Đặt WIP limit = 3 cho cột In Progress. Kéo 4 issue vào để cột chuyển đỏ và quan sát cảnh báo.
- Bài tập swimlane & quick filter: Trên board bất kỳ, tạo swimlane bằng Query gồm 2 làn: "Khẩn" =
priority = Highestvà làn mặc định. Thêm 2 quick filter: "Việc của tôi" và "Chỉ Bug".
- Bài tập chẩn đoán: Thêm một status mới vào workflow, cố tình không map nó vào cột nào, quan sát issue biến mất, rồi tự sửa bằng cách map status vào cột phù hợp. Ghi lại quy trình 2 bước bạn rút ra.
Tóm tắt
Board trong Jira không phải nơi chứa dữ liệu mà là một ống kính (lens) nhìn vào issue của project, được điều khiển bởi một board filter viết bằng JQL. Chính vì thế, một project có thể có nhiều board phục vụ nhiều góc nhìn khác nhau mà không nhân bản dữ liệu.
Scrum board dành cho công việc lên kế hoạch được theo chu kỳ sprint, với luồng Backlog → Planning → Active Sprint → Reports, và đo lường bằng velocity/burndown. Kanban board dành cho dòng chảy liên tục, dùng WIP limit để kiểm soát việc dở dang và Cumulative Flow Diagram để phát hiện nghẽn. Chọn đúng loại board theo bản chất luồng công việc là quyết định quan trọng nhất — chọn sai khiến mọi số liệu vô nghĩa.
Ba đòn bẩy cấu hình bạn sẽ chạm nhiều nhất là Columns/Statuses (nhớ: status không map thì issue biến mất), Swimlanes (chia dòng công việc thông minh, tránh chia theo assignee cho team lớn), và Quick Filters (lọc nhanh không đụng filter gốc). Nắm chắc những nguyên tắc này, bạn đã có nền tảng vững để bước vào các bài JQL, workflow và automation ở phần sau của khóa học.