Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa được nhận vào vị trí BA tại một công ty fintech ở TP.HCM. Ngày đầu tiên, team lead mở JIRA lên, chỉ vào màn hình và nói: "Em tách cái Epic này thành các Story, rồi gắn Sub-task cho dev, còn mấy con Bug từ QA thì link vào Story tương ứng nhé." Nếu bạn không hiểu rõ Epic, Story, Task, Bug, Sub-task khác nhau ra sao, bạn sẽ gật đầu trong hoang mang — và rất có thể sẽ tạo issue sai loại, khiến cả backlog rối tung.
Issue Type (loại issue) là viên gạch nền tảng của mọi thứ bạn làm trong JIRA. Mọi báo cáo, mọi sprint, mọi dashboard, mọi câu lệnh JQL sau này đều dựa trên việc issue được phân loại đúng ngay từ đầu. Một BA giỏi không chỉ biết "viết yêu cầu", mà còn biết đặt yêu cầu đó vào đúng "ngăn kéo" để cả team — từ Product Owner, Dev, đến QA — đều hiểu cùng một ngôn ngữ.
Trong bài này, chúng ta sẽ đi sâu vào 5 loại issue cơ bản nhất mà bất kỳ BA nào cũng phải nắm vững. Đây không phải lý thuyết suông — bạn sẽ học cách phân biệt chúng qua kích thước công việc, vai trò trong quy trình, và cách chúng liên kết với nhau để tạo nên một bức tranh dự án mạch lạc.
Khái niệm cốt lõi
Trong JIRA, mọi đơn vị công việc đều được biểu diễn dưới dạng một issue (issue ở đây không có nghĩa là "vấn đề/sự cố" như tiếng Anh thông thường, mà là "mục công việc"). Mỗi issue thuộc về một issue type — quyết định nó đại diện cho loại công việc gì, có những trường thông tin nào, và đi qua quy trình (workflow) ra sao.
Hãy nhìn vào 5 loại cơ bản qua một bảng tổng quan, rồi ta sẽ mổ xẻ từng loại:
| Loại issue | Mục đích | Kích thước | Ai thường tạo |
|---|---|---|---|
| Epic | Khối công việc lớn, kéo dài nhiều sprint | Lớn (vài tuần đến vài tháng) | PO / BA |
| Story | Một tính năng/giá trị hoàn chỉnh cho người dùng | Vừa (gói gọn trong 1 sprint) | BA / PO |
| Task | Công việc kỹ thuật/hành chính không trực tiếp tạo giá trị người dùng | Vừa | Bất kỳ ai |
| Bug | Lỗi cần sửa, sai lệch giữa thực tế và mong đợi | Nhỏ đến vừa | QA / Dev / BA |
| Sub-task | Phần nhỏ của một issue cha, chia nhỏ để dễ làm | Nhỏ (vài giờ đến 1-2 ngày) | Dev / BA |
Epic — bức tranh lớn
Epic là khối công việc lớn không thể hoàn thành trong một sprint. Nó đại diện cho một mục tiêu kinh doanh lớn hoặc một sáng kiến (initiative). Ví dụ: "Xây dựng tính năng thanh toán QR code" hay "Triển khai chương trình khách hàng thân thiết". Một Epic thường gom nhiều Story bên dưới.
Vai trò của BA với Epic là rất quan trọng: bạn là người thường định nghĩa Epic dựa trên yêu cầu nghiệp vụ, viết mô tả mục tiêu, phạm vi (scope), và tiêu chí thành công ở mức cao. Epic giúp lãnh đạo và stakeholder nhìn thấy "chúng ta đang xây cái gì lớn" mà không cần lao vào chi tiết kỹ thuật.
Story (User Story) — giá trị cho người dùng
Story, hay đầy đủ là User Story, là đơn vị công việc mô tả một tính năng mang lại giá trị cho người dùng cuối. Story phải đủ nhỏ để hoàn thành gọn trong một sprint. Công thức kinh điển mà BA hay dùng để viết Story:
> Là một [vai trò], tôi muốn [hành động], để [đạt được giá trị].
Ví dụ: "Là một khách hàng, tôi muốn quét mã QR để thanh toán, để không cần nhập số tài khoản thủ công." Story là nơi BA dành nhiều thời gian nhất, vì nó gắn với Acceptance Criteria (tiêu chí chấp nhận) — định nghĩa rõ "thế nào là làm xong".
Task — công việc không hướng người dùng
Task là công việc cần làm nhưng không trực tiếp tạo ra giá trị nhìn thấy được cho người dùng cuối. Ví dụ: "Cấu hình server staging", "Chuẩn bị tài liệu hướng dẫn vận hành", "Họp với phòng pháp chế về điều khoản". Task hữu ích để theo dõi các công việc nội bộ, kỹ thuật, hoặc hành chính trong dự án.
Một lưu ý cho BA: đừng nhầm Task với Story. Nếu một việc có thể mô tả bằng "Là một người dùng… tôi muốn…" thì đó là Story. Nếu không có người dùng cuối nào hưởng lợi trực tiếp, đó là Task.
Bug — lỗi cần sửa
Bug đại diện cho một lỗi: sự sai lệch giữa hành vi thực tế của hệ thống và hành vi mong đợi. Bug thường do QA hoặc người dùng phát hiện. Một Bug tốt cần có: các bước tái hiện (steps to reproduce), kết quả mong đợi (expected result), kết quả thực tế (actual result), và mức độ nghiêm trọng (severity/priority).
BA đôi khi cũng tạo Bug — đặc biệt khi trong quá trình kiểm thử nghiệp vụ (business testing/UAT) bạn phát hiện hệ thống không khớp với yêu cầu đã viết.
Sub-task — chia nhỏ để chinh phục
Sub-task là phần con của một issue cha (thường là Story hoặc Task). Khi một Story quá lớn về mặt kỹ thuật, team chia nó thành các Sub-task nhỏ để phân công và theo dõi. Ví dụ Story "Quét QR để thanh toán" có thể có các Sub-task: "Thiết kế UI màn hình quét", "Tích hợp API ngân hàng", "Viết unit test". Điểm đặc biệt: Sub-task luôn thuộc về một issue cha, không thể tồn tại độc lập.
Phân cấp quan hệ
Một cách hình dung dễ nhớ về thứ bậc:
Epic
└── Story / Task / Bug
└── Sub-task
Epic chứa nhiều Story/Task/Bug. Mỗi Story/Task/Bug có thể chứa nhiều Sub-task. Đây là "cây gia phả" của công việc trong JIRA mà BA cần thuộc lòng.
Tình huống thực tế
Tình huống 1 — Sàn TMĐT chia nhỏ tính năng "Ví điện tử"
Công ty TMĐT "ShopViet" (giả định, mô phỏng một sàn quy mô trung bình ở Hà Nội với khoảng 40 nhân sự công nghệ) muốn ra mắt tính năng ví điện tử nội bộ cho phép khách lưu tiền hoàn (cashback). Chị Lan — BA của dự án — bắt đầu bằng cách tạo một Epic tên "Ví điện tử ShopViet", với mục tiêu: tăng tỷ lệ khách quay lại 15% trong quý.
Dưới Epic này, chị Lan tách thành các Story:
- "Là khách hàng, tôi muốn xem số dư ví, để biết mình có bao nhiêu cashback."
- "Là khách hàng, tôi muốn dùng số dư ví để thanh toán đơn hàng, để tiết kiệm chi phí."
- "Là khách hàng, tôi muốn xem lịch sử giao dịch ví, để đối chiếu."
Bài học: BA dùng Epic để giữ tầm nhìn lớn, Story để diễn đạt giá trị người dùng, Sub-task để chia nhỏ kỹ thuật, và Task cho công việc nội bộ. Phân loại đúng giúp khi ban giám đốc hỏi "Epic Ví điện tử xong bao nhiêu phần trăm?", JIRA tự tính được dựa trên các Story con.
Tình huống 2 — Startup logistics và cái bẫy "mọi thứ đều là Task"
"GiaoNhanh" là một startup logistics ở Đà Nẵng. Khi mới dùng JIRA, đội ngũ — vốn xuất thân kỹ thuật, chưa có BA chuyên trách — tạo mọi thứ thành Task cho nhanh. Sau ba tháng, backlog có hơn 300 Task xếp thành một danh sách phẳng, không phân cấp. Khi nhà đầu tư hỏi "tính năng theo dõi đơn hàng real-time đã hoàn thành chưa", không ai trả lời được, vì các Task liên quan nằm rải rác khắp nơi, không gom dưới một Epic nào.
Khi anh Tuấn — BA mới — gia nhập, việc đầu tiên anh làm là tái cấu trúc: gom các Task thành từng nhóm theo tính năng, tạo Epic cho từng nhóm lớn, chuyển những Task thực chất là tính năng người dùng thành Story, và tách các lỗi đang nằm lẫn lộn thành Bug riêng. Sau hai tuần dọn dẹp, lần đầu tiên đội ngũ có một dashboard cho thấy tiến độ theo Epic.
Bài học: Lạm dụng một loại issue duy nhất khiến dữ liệu vô dụng cho báo cáo. Phân loại đúng từ đầu rẻ hơn rất nhiều so với việc dọn dẹp về sau. Vai trò của BA chính là người gác cổng cho sự sạch sẽ của backlog.
Tình huống 3 — Ngân hàng số và sự khác biệt Bug vs Story
Tại một ngân hàng số (neobank) ở Singapore mở rộng sang thị trường Việt Nam, đội QA báo cáo: "Màn hình chuyển khoản không hiển thị phí giao dịch." Câu hỏi đặt ra trong buổi refinement: đây là Bug hay Story mới?
BA của team — chị Mai — đặt một câu hỏi quyết định: "Yêu cầu ban đầu có ghi phải hiển thị phí không?" Sau khi tra lại tài liệu, hóa ra Acceptance Criteria của Story chuyển khoản đã ghi rõ "hiển thị phí trước khi xác nhận". Vì hệ thống không làm đúng điều đã cam kết, đây là Bug. Nếu yêu cầu ban đầu hoàn toàn không nhắc đến phí, thì việc bổ sung hiển thị phí sẽ là một Story (yêu cầu mới), không phải Bug.
Bài học: Ranh giới Bug và Story phụ thuộc vào việc hệ thống có lệch khỏi yêu cầu đã thống nhất hay không. Đây là lý do Acceptance Criteria mà BA viết lại quan trọng đến vậy — nó là "hợp đồng" để phân định Bug hay tính năng mới, ảnh hưởng trực tiếp đến việc ai chịu chi phí sửa.
Hướng dẫn từng bước
Dưới đây là quy trình tạo và tổ chức issue type mà một BA nên theo khi bắt đầu một mảng tính năng mới trong JIRA:
- Tạo Epic trước. Vào project, chọn nút "Create", chọn Issue Type là Epic. Đặt tên ngắn gọn (Epic Name), viết mô tả mục tiêu nghiệp vụ và phạm vi. Đây là khung chứa cho mọi việc bên dưới.
- Phân rã thành Story. Với mỗi giá trị người dùng cụ thể, tạo một issue loại Story. Trong trường "Epic Link" (hoặc kéo thả vào Epic ở chế độ Backlog), gắn Story vào Epic vừa tạo. Viết Story theo công thức "Là một… tôi muốn… để…" và bổ sung Acceptance Criteria.
- Tách Task cho công việc nội bộ. Những việc kỹ thuật/hành chính không hướng người dùng, tạo loại Task, cũng gắn vào Epic nếu liên quan.
- Chia Sub-task khi cần. Mở một Story phức tạp, chọn "Create subtask" (biểu tượng dấu cộng hoặc menu "+"), tạo các Sub-task cụ thể. Mỗi Sub-task nên đủ nhỏ để một người làm xong trong 1-2 ngày.
- Ghi nhận Bug đúng chỗ. Khi QA phát hiện lỗi, tạo issue loại Bug với đầy đủ steps to reproduce, expected/actual result. Dùng tính năng "Link issue" để liên kết Bug với Story bị lỗi (quan hệ "relates to" hoặc "is caused by").
- Kiểm tra cây phân cấp. Vào chế độ Backlog hoặc dùng Roadmap để xác nhận: mỗi Story nằm dưới đúng Epic, mỗi Sub-task nằm dưới đúng issue cha. Một cấu trúc gọn gàng ở đây sẽ tiết kiệm cho bạn hàng giờ làm báo cáo sau này.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến mọi thứ thành Story (hoặc Task). Như tình huống GiaoNhanh, dùng một loại cho tất cả khiến phân cấp sụp đổ. Mẹo: trước khi tạo, tự hỏi "Việc này lớn cỡ nào và phục vụ ai?" để chọn đúng loại.
Lỗi 2 — Tạo Story quá lớn (nuốt cả sprint không xong). Nếu một Story không thể hoàn thành trong một sprint, nó thực ra nên là Epic, hoặc cần tách nhỏ. Mẹo: áp dụng nguyên tắc INVEST — Story tốt phải Independent, Negotiable, Valuable, Estimable, Small, Testable.
Lỗi 3 — Lẫn lộn Sub-task với Story con. Sub-task không phải là "Story nhỏ". Sub-task không xuất hiện độc lập trong sprint report và thường không được estimate riêng theo story point. Đừng dùng Sub-task để theo dõi giá trị người dùng — đó là việc của Story.
Lỗi 4 — Gọi mọi thiếu sót là Bug. Như tình huống ngân hàng số, nếu yêu cầu ban đầu không đề cập, đó là yêu cầu mới (Story), không phải Bug. Gọi sai có thể gây tranh cãi về trách nhiệm và chi phí.
Mẹo cho BA: Đừng coi cấu hình issue type là việc của riêng admin. Là BA, bạn nên chủ động đề xuất sơ đồ phân loại rõ ràng cho team. Nếu công ty có nhu cầu đặc thù (ví dụ phân biệt "Change Request" với Bug), hãy bàn với JIRA admin — nhưng hãy giữ số loại issue ở mức tối thiểu cần thiết. Càng nhiều loại, team càng dễ tạo sai.
Mẹo phân biệt nhanh: Epic = "chúng ta đang xây cái gì lớn"; Story = "người dùng được gì"; Task = "team cần làm gì (không hướng người dùng)"; Bug = "cái gì đang sai so với cam kết"; Sub-task = "bước nhỏ để hoàn thành một issue cha".
Bài tập thực hành
Hãy thực hành với bối cảnh sau: Một chuỗi cà phê ở Việt Nam (giả định "CafeGo") muốn xây dựng ứng dụng đặt món và tích điểm.
- Viết một Epic cho sáng kiến "Ứng dụng đặt món CafeGo", kèm mục tiêu nghiệp vụ rõ ràng (gợi ý: tăng đơn hàng online).
- Liệt kê ít nhất 4 Story dưới Epic đó, viết theo công thức "Là một… tôi muốn… để…". Đảm bảo mỗi Story đủ nhỏ để gọn trong một sprint.
- Chọn một Story phức tạp nhất và chia thành ít nhất 3 Sub-task.
- Xác định 2 Task không hướng người dùng cuối mà dự án vẫn cần (gợi ý: nghĩ về vận hành, tích hợp nội bộ).
- Phân loại các tình huống sau là Bug hay Story mới, kèm lý do:
Sau khi làm xong, hãy tự kiểm tra: cây phân cấp của bạn có đúng thứ bậc Epic → Story → Sub-task không? Có Story nào thực chất nên là Epic (vì quá lớn) không?
Tóm tắt
JIRA có 5 loại issue cơ bản mà mọi BA phải nắm vững: Epic (khối công việc lớn, nhiều sprint), Story (giá trị cho người dùng, gọn trong một sprint), Task (công việc không hướng người dùng), Bug (lỗi sai lệch với cam kết), và Sub-task (phần con của một issue cha). Chúng tạo thành một cây phân cấp: Epic chứa Story/Task/Bug, và mỗi issue đó có thể chứa Sub-task.
Việc phân loại đúng không phải là chuyện hình thức — nó quyết định chất lượng báo cáo, độ chính xác của sprint, và khả năng cả team hiểu nhau. Như ta đã thấy qua các tình huống ShopViet, GiaoNhanh và ngân hàng số, một backlog được phân loại tốt giúp trả lời nhanh câu hỏi "xong bao nhiêu phần trăm" và phân định rõ ràng đâu là lỗi, đâu là yêu cầu mới.
Là BA, bạn chính là người gác cổng cho sự sạch sẽ này. Hãy chọn đúng loại ngay từ khi tạo issue, giữ Story đủ nhỏ theo nguyên tắc INVEST, và luôn dựa vào Acceptance Criteria để phân định Bug hay Story. Ở bài tiếp theo, chúng ta sẽ đi sâu vào Workflow — hành trình mà mỗi issue đi qua từ lúc tạo đến lúc đóng.