Mở đầu — vì sao bài này quan trọng
Nếu bạn từng mở một board JIRA và thấy issue thì rối tung, cột thì lộn xộn, một số task lẽ ra phải hiện thì lại biến mất, còn task của team khác lại "lạc" vào board của mình — thì gần như chắc chắn vấn đề không nằm ở JIRA, mà nằm ở cấu hình board. Đây là một trong những kỹ năng bị xem nhẹ nhất nhưng lại quyết định trực tiếp đến trải nghiệm làm việc hằng ngày của cả team.
Với vai trò BA (Business Analyst), bạn thường là người "dọn nhà" cho cả team Agile. Bạn không chỉ viết user story, mà còn phải đảm bảo cái board mà team nhìn vào mỗi sáng standup phản ánh đúng thực tế công việc. Một board cấu hình sai sẽ khiến PO không thấy được tiến độ thật, Dev cãi nhau "tại sao card này nằm cột này", còn QA thì không biết nên kéo issue đi đâu sau khi test xong.
Trong bài này, chúng ta sẽ đi sâu vào cách cấu hình một Agile board đúng nghĩa: từ việc hiểu board thực chất là gì (một góc nhìn được lọc bằng JQL), đến cách thiết lập board filter, ánh xạ cột (column mapping) với status, swimlanes, quick filters, và những thiết lập tinh chỉnh khác. Lưu ý: bài này tập trung vào cấu hình board — không phải so sánh Scrum vs Kanban (đã có ở Bài 9), không phải sprint planning (Bài 12), cũng không phải backlog refinement (Bài 11). Ở đây chúng ta học cách "lắp ráp và chỉnh" chính cái board đó.
Khái niệm cốt lõi
Board là một góc nhìn (view), không phải một kho chứa dữ liệu
Đây là hiểu lầm phổ biến nhất. Nhiều người nghĩ board "chứa" các issue. Sai. Trong JIRA, issue luôn thuộc về project. Board chỉ là một cửa sổ nhìn vào tập issue đó, được lọc qua một câu JQL gọi là board filter.
Board filter JQL (ví dụ):
project = PROJ AND issuetype in (Story, Task, Bug, Sub-task)
ORDER BY Rank ASC
Câu JQL trên quyết định board của bạn sẽ thấy issue nào. Nếu một issue không khớp với điều kiện này, nó đơn giản là không xuất hiện trên board — dù nó vẫn tồn tại trong project. Đây là chìa khóa để hiểu mọi hành vi "kỳ lạ" của board: issue biến mất, issue lạ xuất hiện, sprint không thấy card... gần như luôn truy về board filter.
Bốn thành phần cấu hình quan trọng của một board
Khi vào phần Board settings (Configure board), bạn sẽ thấy các tab chính sau, và đây là những thứ một BA cần nắm vững:
1. General / Filter — định nghĩa board filter (câu JQL ở trên). Đây là nền móng. Mọi thứ khác xây trên tập issue mà filter này trả về.
2. Columns (Cột) — ánh xạ giữa cột hiển thị trên board và các status của workflow. Một cột có thể gom nhiều status. Ví dụ cột "In Progress" có thể bao gồm cả status In Development lẫn Code Review. Status nào không được map vào cột nào sẽ nằm trong vùng Unmapped Statuses và issue ở status đó sẽ không hiện trên board — đây là bẫy rất hay gặp.
3. Swimlanes (Làn bơi) — chia board thành các hàng ngang để nhóm issue. Phổ biến nhất: swimlane theo Assignee, theo Epic, theo Stories (mỗi story là một làn chứa sub-task), hoặc theo JQL tùy chỉnh (ví dụ làn riêng cho issue ưu tiên cao).
4. Quick Filters (Bộ lọc nhanh) — các nút bấm nhanh ngay trên board để lọc tạm thời, ví dụ "Chỉ task của tôi", "Chỉ Bug", "Ưu tiên High". Quick filter cũng viết bằng JQL nhưng chỉ thêm điều kiện lọc tạm, không thay đổi board filter gốc.
Column mapping — phần dễ sai nhất
Hãy nhớ nguyên tắc: cột trên board ≠ status trong workflow. Status là khái niệm của workflow (Bài 5); cột là khái niệm hiển thị của board. Bạn ánh xạ một-nhiều: một cột chứa một hoặc nhiều status.
Khi Dev kéo card từ cột "To Do" sang cột "In Progress", thực chất JIRA đang chạy một transition để đổi status của issue sang status đầu tiên được map trong cột "In Progress". Nếu workflow không cho phép transition từ status hiện tại sang status đích, JIRA sẽ báo lỗi hoặc không cho kéo. Vì vậy cấu hình cột và cấu hình workflow phải khớp nhau.
Board filter dùng chung — con dao hai lưỡi
Nhiều board có thể dùng chung một filter, và một filter có thể được nhiều người chỉnh. Điều này tiện cho việc tái sử dụng nhưng nguy hiểm: ai đó sửa filter cho board của họ có thể vô tình làm hỏng board của bạn. Đây là lý do BA cần đặt tên filter rõ ràng và kiểm soát quyền chỉnh sửa (share/edit permission của saved filter).
Tình huống thực tế
Tình huống 1 — Tiki: card của team Payment "lạc" sang board team Search
Tại một team công nghệ kiểu Tiki, dự án ECOM được dùng chung cho nhiều squad: Search, Payment, Logistics. Squad Search có board riêng với board filter:
project = ECOM ORDER BY Rank ASC
Vấn đề: filter này lấy toàn bộ issue của project ECOM, nên board của Search đầy ắp card của Payment và Logistics. Mỗi sáng standup, team Search phải cuộn qua hàng trăm card không liên quan, và burndown chart thì sai bét vì tính cả công việc của squad khác.
BA của squad Search xử lý bằng cách thêm điều kiện component vào board filter:
project = ECOM AND component = "Search" ORDER BY Rank ASC
Sau khi sửa, board chỉ còn ~40 card thật sự của Search. Burndown trở nên đáng tin. Bài học: board filter phải đủ hẹp để chỉ chứa phạm vi công việc của team sở hữu board. Với project dùng chung, hãy lọc thêm theo component, label, hoặc một custom field như "Squad".
Tình huống 2 — Một fintech ở TP.HCM: issue "Code Review" biến mất khỏi board
Một công ty fintech mở rộng workflow, thêm status mới Code Review nằm giữa In Development và Done. Lập trình viên chuyển issue sang Code Review, và ngay lập tức card... biến mất khỏi board. Cả team hoảng vì tưởng mất việc.
Nguyên nhân: status mới Code Review chưa được map vào cột nào, nên nó rơi vào vùng Unmapped Statuses. Issue ở status không-được-map sẽ không hiển thị trên board.
BA vào Board settings → Columns, kéo Code Review vào cột "In Progress" (gom chung với In Development), hoặc tạo hẳn một cột mới "Review" giữa "In Progress" và "Done". Card hiện lại ngay. Bài học: mỗi khi workflow thêm status mới, phải kiểm tra ngay column mapping. Quy tắc vàng: không bao giờ để status đang được sử dụng nằm trong vùng Unmapped.
Tình huống 3 — Agency phần mềm ở Hà Nội: swimlane theo Epic giúp khách hàng đọc được board
Một agency làm dự án outsource cho khách Nhật, mỗi sprint chạy 5–6 Epic song song (Onboarding, Báo cáo, Tích hợp API...). Board mặc định để tất cả card trộn vào nhau, khiến PM khách hàng không hình dung được "Epic nào đang chậm".
BA cấu hình swimlane theo Epic. Ngay lập tức board chia thành các làn ngang, mỗi làn là một Epic, các card story/task của Epic đó nằm gọn trong làn. Thêm vào đó, BA tạo ba quick filter: "Only Bugs" (issuetype = Bug), "My Issues" (assignee = currentUser()), và "Blocked" (labels = blocked). Trong buổi review với khách, chỉ cần bật quick filter "Blocked" là cả phòng thấy ngay 4 card đang kẹt và thuộc Epic nào.
Bài học: swimlane và quick filter không thay đổi dữ liệu, chúng chỉ thay đổi cách trình bày. Nhưng đúng cách trình bày lại quyết định việc cuộc họp 30 phút trôi chảy hay rối loạn.
Hướng dẫn từng bước
Dưới đây là quy trình cấu hình một Agile board từ đầu, áp dụng cho cả board Scrum lẫn Kanban (phần khác biệt giữa hai loại đã học ở Bài 9, ở đây ta tập trung cấu hình).
Bước 1 — Tạo board và chọn nguồn issue. Vào Boards → Create board, chọn loại (Scrum hoặc Kanban). Khi tạo, JIRA hỏi bạn muốn tạo board từ một project có sẵn hay từ một saved filter. Nếu board chỉ phục vụ một team/một phạm vi, tạo từ project rồi tinh chỉnh filter sau; nếu board cần gộp nhiều project, tạo từ saved filter.
Bước 2 — Tinh chỉnh board filter (quan trọng nhất). Vào Board settings → General. Mở filter và viết JQL đủ hẹp:
project = PROJ AND issuetype in (Story, Task, Bug, Sub-task)
ORDER BY Rank ASC
Lưu ý luôn để ORDER BY Rank ASC ở cuối — đây là điều cho phép bạn kéo-thả sắp xếp thứ tự ưu tiên trên board và backlog. Thiếu nó, tính năng ranking sẽ không hoạt động đúng.
Bước 3 — Cấu hình Columns và ánh xạ status. Vào tab Columns. Tạo các cột phản ánh quy trình thực tế của team (thường: To Do → In Progress → Done, hoặc chi tiết hơn). Kéo từng status vào đúng cột. Kiểm tra kỹ vùng Unmapped Statuses — phải đảm bảo không có status nào đang dùng bị bỏ sót ở đó.
Bước 4 — Đặt giới hạn WIP (tùy chọn nhưng nên có với Kanban). Ngay tại tab Columns, bạn có thể đặt Min/Max cho từng cột. Ví dụ cột "In Progress" đặt Max = 5: khi vượt 5 card, cột chuyển sang màu đỏ nhắc team đừng ôm quá nhiều việc cùng lúc.
Bước 5 — Cấu hình Swimlanes.
Vào tab Swimlanes, chọn kiểu phân làn: theo Stories, Assignee, Epic, hoặc Queries (JQL tùy chỉnh). Nếu chọn Queries, bạn định nghĩa từng làn bằng một câu JQL, ví dụ làn "Ưu tiên khẩn" với priority = Highest.
Bước 6 — Tạo Quick Filters.
Vào tab Quick Filters, thêm các nút lọc nhanh hữu ích. Mỗi quick filter là một mệnh đề JQL (không cần project, vì nó cộng thêm vào board filter):
assignee = currentUser() -> "My Issues"
issuetype = Bug -> "Only Bugs"
labels = blocked -> "Blocked"
Bước 7 — Card layout và Card colors (tinh chỉnh hiển thị). Tab Card layout cho phép thêm tối đa ba trường hiển thị ngay trên mặt card (ví dụ Story Points, Due date, Component). Tab Card colors cho phép tô màu card theo Issue Type, Priority, Assignee hoặc Query — giúp đọc board nhanh hơn bằng mắt.
Bước 8 — Kiểm thử lại bằng mắt. Quay lại board, kéo thử vài card qua các cột để chắc chắn transition hoạt động, bật/tắt quick filter, đổi swimlane và xác nhận mọi thứ hiển thị đúng như kỳ vọng.
Lỗi thường gặp & mẹo
Lỗi 1 — Board filter quá rộng. Để project = X trần trụi khiến board chứa cả issue của team khác. Mẹo: với project dùng chung, luôn lọc thêm theo component/label/squad.
Lỗi 2 — Quên map status mới. Mỗi lần workflow đổi, kiểm tra ngay Unmapped Statuses. Mẹo: đặt lịch nhắc rằng "đổi workflow = kiểm tra column mapping".
Lỗi 3 — Nhầm giữa sửa quick filter và sửa board filter. Quick filter chỉ là lớp lọc tạm cộng thêm; board filter mới là gốc. Nếu muốn loại bỏ vĩnh viễn một loại issue khỏi board, sửa board filter — đừng dựa vào quick filter.
Lỗi 4 — Sửa saved filter dùng chung mà không kiểm tra ai đang dùng. Trước khi sửa một filter, kiểm tra xem nó có đang là nguồn của board nào khác không. Mẹo: đặt tên filter theo team, ví dụ Search Squad Board Filter, và giới hạn quyền edit.
Lỗi 5 — Thiếu ORDER BY Rank trong board filter. Khiến không kéo-thả sắp thứ tự được. Luôn giữ mệnh đề này.
Mẹo nâng cao: Với board gộp nhiều project (multi-project, sẽ học sâu hơn ở Bài 43), dùng quyền BA để chuẩn hóa tên label và component giữa các project, nếu không quick filter và swimlane theo JQL sẽ không hoạt động đồng nhất. Ngoài ra, hãy giữ số cột vừa phải (3–5 cột) — quá nhiều cột khiến board trông như bảng Excel và làm loãng ý nghĩa của từng giai đoạn.
Bài tập thực hành
- Phân tích board hiện tại. Mở một board bạn đang dùng (hoặc tạo board demo), vào Board settings → General và đọc kỹ board filter JQL. Viết ra giấy: board này đang lấy issue của project nào, loại issue gì, có lọc thêm điều kiện nào không. Đánh giá filter này đã đủ hẹp chưa.
- Sửa column mapping. Vào tab Columns, kiểm tra vùng Unmapped Statuses. Nếu có status nào đó bị bỏ sót, hãy map nó vào cột hợp lý. Nếu không có, hãy thử tạo một status giả trong workflow, quan sát nó rơi vào Unmapped, rồi map lại — để cảm nhận cơ chế.
- Tạo ba quick filter. Lần lượt thêm: "My Issues" (
assignee = currentUser()), "Only Bugs" (issuetype = Bug), và một quick filter tùy bạn chọn cho team mình. Bật/tắt và quan sát board thay đổi thế nào.
- Cấu hình swimlane theo Epic. Đổi swimlane sang kiểu Epic (hoặc Stories nếu chưa có Epic). Mô tả lại trong 3–4 câu: cách trình bày này giúp ích gì cho buổi standup của team bạn.
- Tình huống tự luận. Giả sử team bạn vừa thêm status
Waiting for Customervào workflow và phàn nàn rằng "một số card biến mất". Viết ra các bước chẩn đoán và khắc phục — đây chính là kỹ năng bạn sẽ dùng thường xuyên với vai trò BA.
Tóm tắt
- Board là một góc nhìn được lọc bằng JQL, không phải nơi chứa issue. Issue luôn thuộc về project; board chỉ hiển thị tập issue khớp với board filter.
- Bốn trụ cột cấu hình: Filter (gốc), Columns (ánh xạ cột ↔ status), Swimlanes (phân làn để nhóm), Quick Filters (lọc nhanh tạm thời).
- Sai lầm chí mạng nhất là status chưa được map (rơi vào Unmapped → issue biến mất) và board filter quá rộng (lẫn việc của team khác).
- Luôn giữ
ORDER BY Rank ASCtrong board filter để kéo-thả sắp ưu tiên hoạt động. - Column mapping phải khớp với workflow: kéo card = chạy transition, nên cấu hình cột và workflow phải đồng bộ.
- Với vai trò BA, board được cấu hình tốt chính là công cụ giao tiếp mạnh nhất với team và khách hàng — đúng filter, đúng cột, đúng swimlane sẽ biến một buổi họp hỗn loạn thành một buổi review mạch lạc.