Mở đầu — vì sao bài này quan trọng
Nếu bạn đã từng bước vào một dự án Jira đang chạy và thấy trong đó có đủ loại "issue" trộn lẫn — chỗ thì gọi là "Task", chỗ gọi là "Ticket", chỗ lại gọi là "Requirement", "Change Request", "Support" — thì bạn đang chứng kiến hậu quả trực tiếp của việc không hiểu rõ Issue Type. Trong Jira, mọi thứ công việc — dù là một tính năng mới, một lỗi cần sửa, hay một yêu cầu hỗ trợ nội bộ — đều được biểu diễn dưới dạng một issue (đơn vị công việc). Và mỗi issue phải thuộc về một Issue Type (loại công việc) nhất định.
Issue Type không chỉ là cái nhãn cho đẹp. Nó là "xương sống" quyết định: issue đó chạy qua workflow nào, hiển thị những trường (field) gì, được lọc và báo cáo ra sao, ai được phép làm gì với nó. Chọn sai issue type hoặc tạo bừa hàng chục issue type "cho tiện" là một trong những nguyên nhân phổ biến nhất khiến một Jira project đang gọn gàng dần trở thành mớ hỗn độn mà không ai muốn đụng vào.
Ở Bài 5 bạn đã nắm được hệ thống phân cấp Epic → Story → Task → Sub-task. Bài 6 này đi sâu vào bản chất từng loại issue type chuẩn, khi nào dùng loại nào, và quan trọng nhất: khi nào bạn thực sự cần tạo Custom Issue Type (loại tùy chỉnh) — và khi nào đó chỉ là cái bẫy làm phức tạp hệ thống. Đây là kỹ năng nền tảng của một PM biết "trị" Jira thay vì bị Jira "trị" ngược lại.
Khái niệm cốt lõi
Issue Type là gì và nó chi phối những gì
Một issue type trong Jira gắn liền với bốn thứ:
- Workflow — chuỗi trạng thái (status) mà issue đi qua, ví dụ To Do → In Progress → Done. Mỗi issue type có thể dùng một workflow riêng.
- Field configuration — các trường thông tin xuất hiện trên issue (ví dụ Bug thì cần trường "Steps to reproduce", Story thì cần "Acceptance Criteria").
- Screen scheme — màn hình nào hiển thị khi tạo, xem, chỉnh sửa issue.
- Hierarchy level — issue thuộc cấp nào trong phân cấp (Epic ở trên, Story/Task/Bug ở giữa, Sub-task ở dưới).
Các Standard Issue Type
Jira Cloud cung cấp sẵn một tập hợp issue type chuẩn. Hiểu đúng "linh hồn" của từng loại quan trọng hơn nhiều so với thuộc lòng tên.
Story — công việc mang lại giá trị cho người dùng. Story mô tả một phần chức năng nhìn từ góc độ người dùng cuối, thường viết theo mẫu "Là một [ai đó], tôi muốn [làm gì], để [đạt được gì]". Ví dụ: "Là khách hàng, tôi muốn thanh toán bằng ví MoMo để không phải nhập thẻ mỗi lần." Story là đơn vị chính mà team giao hàng trong mỗi sprint. Điểm mấu chốt: nếu người dùng cuối cảm nhận được kết quả, thì đó là Story.
Task — công việc cần làm nhưng không trực tiếp hướng tới người dùng. Task là những việc kỹ thuật hoặc vận hành cần thiết nhưng người dùng cuối không nhìn thấy trực tiếp. Ví dụ: "Nâng cấp phiên bản PostgreSQL từ 13 lên 15", "Cấu hình CI/CD cho môi trường staging", "Chuẩn bị tài liệu bàn giao". Task vẫn có thể nằm trong sprint và tốn effort, nhưng nó không phải là giá trị người dùng trực tiếp.
Bug — một khiếm khuyết (defect). Bug đại diện cho việc hệ thống đang hoạt động sai so với kỳ vọng. Điểm khác biệt lớn nhất của Bug so với Story/Task là nó thường cần các trường đặc thù: "Steps to reproduce" (các bước tái hiện lỗi), "Expected vs Actual result" (kết quả mong đợi so với thực tế), "Severity/Priority" (mức nghiêm trọng). Bug cũng thường có workflow riêng để phục vụ quy trình triage.
Epic — vật chứa (container) cho một khối công việc lớn. Epic gom nhiều Story/Task/Bug lại thành một mục tiêu lớn, thường kéo dài nhiều sprint. Ví dụ: Epic "Tích hợp thanh toán nội địa" có thể chứa các Story về MoMo, ZaloPay, VNPay. Epic nằm ở cấp cao hơn trong phân cấp và là điểm neo để theo dõi tiến độ theo mục tiêu chứ không theo từng việc nhỏ.
Sub-task — mảnh việc nhỏ chia ra từ một issue cha. Sub-task là cách bổ nhỏ một Story hoặc Task để nhiều người cùng làm hoặc để theo dõi chi tiết. Ví dụ Story "Thanh toán qua MoMo" có thể chia thành Sub-task "Thiết kế UI màn hình thanh toán", "Tích hợp API MoMo", "Viết test tự động". Sub-task luôn thuộc về một issue cha, không tồn tại độc lập, và không xuất hiện riêng trên backlog như một hạng mục lên kế hoạch — đây là điểm khiến nhiều team dùng sai.
Cấp bậc của issue type (Hierarchy)
Điều nhiều người mới hay nhầm: không phải issue type nào cũng ngang hàng. Jira có ba tầng:
- Tầng trên Epic (Epic level và cao hơn) — Epic, và với Advanced Roadmaps còn có Initiative/Theme (nhưng đó là chuyện của Bài 17).
- Tầng Standard — Story, Task, Bug và các custom type cùng cấp. Đây là tầng "chủ lực" của công việc thường ngày.
- Tầng Sub-task — Sub-task và các custom sub-task type, luôn nằm dưới một issue tầng Standard.
Custom Issue Type — khi nào thực sự cần
Custom Issue Type là issue type do bạn tự tạo ngoài bộ chuẩn. Nghe hấp dẫn, nhưng đây là nơi các PM hay "vung tay quá trán". Nguyên tắc vàng: chỉ tạo custom issue type khi loại công việc đó cần một workflow khác, một bộ field khác, hoặc cần được báo cáo/lọc tách biệt rõ ràng. Nếu bạn chỉ muốn phân loại, hãy dùng Label, Component, hoặc một custom field dạng dropdown — chứ đừng đẻ ra issue type mới.
Những trường hợp custom issue type thực sự hợp lý:
- Spike / Research — công việc khám phá, tìm hiểu, không giao hàng trực tiếp (sẽ học kỹ ở Bài 50), thường cần theo dõi tách biệt để không tính vào velocity.
- Change Request — trong bối cảnh có quy trình phê duyệt thay đổi, cần workflow có bước approval.
- Incident / Service Request — trong ngữ cảnh Service Desk/ITSM (Bài 45), nơi loại công việc này có SLA và workflow rất khác.
Tình huống thực tế
Tình huống 1 — Startup Fintech TP.HCM và cái bẫy "issue type cho mọi thứ"
Một startup fintech ở Quận 4, TP.HCM (khoảng 25 kỹ sư, 4 team) khi mới dùng Jira đã để mỗi team tự tạo issue type theo ý mình. Sau 8 tháng, project có tới 17 issue type: Story, Task, Bug, Epic, Sub-task, cộng thêm "Frontend", "Backend", "API Task", "DB Change", "Hotfix", "Improvement", "Tech Debt", "Investigation", "Documentation", "Ops", "Meeting".
Hậu quả: khi PM muốn báo cáo "sprint này team giao được bao nhiêu giá trị người dùng", họ không thể lọc gọn được vì công việc bị rải khắp 17 loại. Velocity không đáng tin. Người mới vào hoang mang không biết nên tạo "Task" hay "Improvement" cho cùng một việc.
Diễn giải: phần lớn 12 issue type thừa thực chất chỉ là thuộc tính. "Frontend/Backend/API" là Component. "Hotfix" là mức Priority. "Tech Debt/Documentation" là Label. Đội PM đã tổ chức lại: gộp về 5 loại chuẩn + 1 custom "Spike", chuyển phần còn lại thành Component và Label. Sau chuẩn hóa, báo cáo velocity trở lại đáng tin, và thời gian tạo issue của mỗi kỹ sư giảm rõ vì không còn phải phân vân.
Bài học: trước khi tạo issue type mới, hãy hỏi "cái này có cần workflow hoặc field riêng không?". Nếu không, nó là thuộc tính — dùng Label/Component/field, đừng dùng issue type.
Tình huống 2 — Công ty gia công phần mềm ở Đà Nẵng và Change Request có approval
Một công ty outsourcing ở Đà Nẵng làm dự án cho khách hàng Nhật. Khách hàng yêu cầu: mọi thay đổi phạm vi (scope change) phải qua bước phê duyệt của Project Owner phía khách trước khi team bắt tay làm. Nếu dùng Story thông thường, workflow chỉ có To Do → In Progress → Done, không có chỗ cho bước "Chờ khách duyệt".
Diễn giải: đây là trường hợp custom issue type hoàn toàn chính đáng. Team tạo issue type "Change Request" với workflow riêng: Submitted → Under Review → Approved / Rejected → In Progress → Done. Họ cũng thêm field "Impact on timeline" và "Estimated extra cost" chỉ xuất hiện trên Change Request. Nhờ tách riêng, PM có thể lọc issuetype = "Change Request" AND status = "Under Review" để báo cáo với khách những gì đang chờ duyệt — điều bất khả thi nếu trộn chung vào Story.
Bài học: khi một loại công việc cần một dòng chảy trạng thái khác biệt và dữ liệu đặc thù, đó chính là tín hiệu rõ ràng để tạo custom issue type.
Tình huống 3 — Team thương mại điện tử và ranh giới Sub-task vs Story
Một team làm sàn TMĐT (giả định tên "ChợViệt", khoảng 12 người) hay tranh cãi: khi chia nhỏ Story "Trang chi tiết sản phẩm", nên dùng Sub-task hay tạo thêm Story con? Ban đầu họ tạo mỗi mảnh nhỏ thành một Story riêng, khiến backlog phình ra hàng trăm Story vụn, sprint planning thành cơn ác mộng.
Diễn giải: sau khi rà lại, họ áp dụng nguyên tắc: nếu mảnh việc chỉ có ý nghĩa bên trong một Story và không giao độc lập được cho người dùng, dùng Sub-task. Nếu mảnh việc tự nó mang giá trị và có thể ưu tiên độc lập trên backlog, tách thành Story riêng. Với "Trang chi tiết sản phẩm", các phần như "Hiển thị ảnh", "Nút thêm giỏ hàng", "Đánh giá sản phẩm" — trong đó "Đánh giá sản phẩm" đủ lớn và độc lập nên tách thành Story riêng, còn "Hiển thị ảnh" và "Nút thêm giỏ hàng" để làm Sub-task. Backlog gọn lại rõ rệt.
Bài học: Sub-task là để phân rã thực thi, không phải để lập kế hoạch sản phẩm. Đừng dùng Sub-task thay cho Story và ngược lại.
Hướng dẫn từng bước
Dưới đây là quy trình chuẩn hóa và tùy chỉnh issue type cho một project (áp dụng cho Jira Cloud, team-managed hoặc company-managed đều có logic tương tự):
- Kiểm kê hiện trạng. Vào project, lọc theo
project = ABCrồi nhóm theo Issue Type để xem thực tế có bao nhiêu loại và mỗi loại được dùng bao nhiêu lần. Loại nào gần như không dùng là ứng viên để loại bỏ.
- Phân loại "issue type thật" vs "thuộc tính". Với mỗi issue type đang có, đặt câu hỏi: nó có cần workflow riêng không? Có cần field riêng không? Có cần báo cáo tách biệt không? Nếu cả ba đều "không", nó nên trở thành Label/Component/field.
- Chốt bộ issue type tối thiểu. Với đa số team làm phần mềm, bắt đầu bằng đúng 5 loại chuẩn: Epic, Story, Task, Bug, Sub-task. Chỉ thêm custom khi có lý do thật.
- Tạo custom issue type (nếu cần). Trong Jira Cloud company-managed: vào Settings → Issues → Issue types → Add issue type, đặt tên rõ ràng, chọn đúng tầng (Standard hay Sub-task), gán icon dễ phân biệt. Với team-managed project: vào Project settings → Issue types → thêm loại và tùy biến field ngay trong giao diện kéo-thả.
- Gắn issue type vào Issue Type Scheme của project (với company-managed). Chỉ đưa vào scheme những loại project thực sự dùng, để danh sách khi tạo issue gọn gàng.
- Cấu hình workflow và field cho custom type. Đảm bảo custom issue type ánh xạ tới đúng workflow (ví dụ Change Request → workflow có bước Approval) và đúng field configuration (thêm/bớt trường cho phù hợp). Đây mới là phần "có giá trị thật" của việc tùy chỉnh.
- Viết hướng dẫn ngắn cho team. Một bảng đơn giản: "Khi nào dùng Story / Task / Bug / Spike" dán vào Confluence hoặc mô tả project. Chuẩn hóa cách hiểu quan trọng ngang với chuẩn hóa cấu hình.
- Rà soát định kỳ. Mỗi quý, kiểm kê lại. Nếu thấy một custom type gần như không được dùng, mạnh dạn loại bỏ (sau khi chuyển các issue cũ sang loại phù hợp).
Lỗi thường gặp & mẹo
Lỗi 1 — Tạo issue type để phân loại thay vì dùng field. Đây là lỗi số một. "Frontend Task", "QA Task", "Design Task" nên là Component hoặc Label. Mẹo: nếu bạn thấy mình muốn tạo issue type mà workflow của nó giống hệt một loại đã có, đó là dấu hiệu nên dùng thuộc tính.
Lỗi 2 — Nhầm Sub-task với Story. Sub-task không lên backlog, không estimate độc lập theo cách Story được estimate, và biến mất nếu issue cha bị đóng. Đừng đặt công việc quan trọng, độc lập vào Sub-task.
Lỗi 3 — Đặt tên issue type mơ hồ. "Ticket", "Item", "Request" khiến mọi người hiểu khác nhau. Tên phải phản ánh đúng bản chất công việc và workflow đi kèm.
Lỗi 4 — Quên rằng đổi issue type có thể phá workflow. Khi bạn chuyển một issue từ type này sang type khác, nếu hai type dùng workflow khác nhau, Jira sẽ phải ánh xạ lại status — dễ gây trạng thái "lệch". Kiểm tra kỹ trước khi bulk-change.
Mẹo — Ít nhưng đúng. Một bộ issue type gọn (5–7 loại) mà cả team hiểu thống nhất luôn tốt hơn một bộ 15 loại "đầy đủ" mà không ai dùng nhất quán. Sự đơn giản là tính năng, không phải khuyết điểm.
Mẹo — Icon và màu. Gán icon dễ phân biệt cho từng issue type giúp team nhận diện nhanh trên board mà không cần đọc chữ — một chi tiết nhỏ nhưng cải thiện tốc độ làm việc đáng kể.
Bài tập thực hành
- Kiểm kê: Lấy một project Jira bạn đang có quyền truy cập (hoặc tạo một project thử miễn phí). Liệt kê tất cả issue type đang tồn tại và đếm số lần mỗi loại được dùng.
- Phân loại: Với mỗi issue type, tự trả lời ba câu hỏi (workflow riêng? field riêng? báo cáo tách biệt?). Đánh dấu loại nào là "issue type thật", loại nào nên chuyển thành Label/Component.
- Thiết kế custom type: Giả sử team bạn cần theo dõi công việc nghiên cứu tách biệt. Hãy phác thảo một issue type "Spike": nó thuộc tầng nào, cần workflow gì (gợi ý: To Do → In Progress → Done, có thể thêm "Timeboxed"), cần field đặc thù nào (ví dụ "Câu hỏi cần trả lời", "Deadline timebox").
- Ra quyết định: Với 5 công việc sau, hãy gán issue type phù hợp và giải thích: (a) "Người dùng không đăng nhập được bằng Google", (b) "Nâng cấp thư viện React lên bản mới", (c) "Là khách, tôi muốn lọc sản phẩm theo giá", (d) "Tìm hiểu xem nên dùng Stripe hay cổng nội địa", (e) "Viết unit test cho module thanh toán".
Tóm tắt
Issue Type là nền tảng chi phối cách công việc vận hành trong Jira: nó quyết định workflow, field, màn hình và cấp bậc của mỗi issue. Bộ chuẩn gồm Story (giá trị người dùng), Task (việc kỹ thuật/vận hành không hướng người dùng), Bug (khiếm khuyết), Epic (vật chứa cho khối lớn) và Sub-task (mảnh phân rã thực thi của một issue cha). Custom Issue Type chỉ nên tạo khi loại công việc thực sự cần workflow riêng, field riêng hoặc báo cáo tách biệt — như Spike, Change Request, hay Incident trong ngữ cảnh Service Desk. Sai lầm lớn nhất là dùng issue type để phân loại những thứ vốn là thuộc tính (nên dùng Label, Component, custom field). Nguyên tắc dẫn đường: ít nhưng đúng — một bộ issue type gọn, được cả team hiểu thống nhất, luôn giá trị hơn một bộ đồ sộ mà không ai dùng nhất quán. Nắm chắc điều này, bạn đã sẵn sàng bước sang Bài 7 để thiết kế chính các workflow mà những issue type này chạy qua.