Mở đầu — vì sao bài này quan trọng
Nếu bạn từng mở một dự án Jira và thấy hàng trăm "issue" nằm lộn xộn không biết đâu là việc lớn, đâu là việc nhỏ, đâu là việc con của việc nào — thì đó chính là hậu quả của việc không hiểu rõ cấu trúc phân cấp (hierarchy) trong Jira. Với vai trò Project Manager, đây không phải là kiến thức "nice to have" mà là nền tảng bắt buộc. Bởi vì mọi thứ bạn làm sau này — lập kế hoạch sprint, ước lượng story point, vẽ roadmap, báo cáo tiến độ cho sếp — đều dựa trên việc dữ liệu được tổ chức đúng tầng.
Hãy tưởng tượng bạn xây một ngôi nhà mà không có bản vẽ phân tầng: móng ở đâu, cột ở đâu, phòng ngủ nằm trên hay dưới phòng khách. Cấu trúc phân cấp Jira chính là bản vẽ đó cho dự án phần mềm. Khi bạn đặt đúng một tính năng là Epic, chia nó ra các Story hợp lý, và tách công việc kỹ thuật thành Sub-task, thì cả đội — từ dev, QA đến stakeholder — đều nhìn cùng một bức tranh và nói cùng một ngôn ngữ.
Trong bài này, chúng ta sẽ đi sâu vào bốn tầng cốt lõi: Epic → Story / Task / Bug → Sub-task, cùng tầng Initiative ở phía trên (dành cho Advanced Roadmaps). Bạn sẽ hiểu bản chất từng tầng, biết khi nào dùng cái nào, và quan trọng nhất là tránh được những lỗi tổ chức mà rất nhiều PM Việt Nam mắc phải trong 6 tháng đầu đi làm.
Khái niệm cốt lõi
Cấu trúc phân cấp chuẩn của Jira
Jira tổ chức công việc theo mô hình cây (tree), từ lớn đến nhỏ. Cấu trúc chuẩn trông như sau:
Initiative (chỉ có trong Advanced Roadmaps / Jira Premium)
└─ Epic (một tính năng lớn / một khối công việc lớn)
└─ Story / Task / Bug (đơn vị công việc giao được)
└─ Sub-task (bước nhỏ để hoàn thành Story/Task/Bug)
Điểm quan trọng cần nhớ: Jira Cloud mặc định (bản Free và Standard) chỉ cho bạn ba tầng: Epic → Story/Task/Bug → Sub-task. Tầng Initiative nằm phía trên Epic chỉ xuất hiện khi bạn dùng Advanced Roadmaps (một tính năng của gói Jira Premium — chúng ta sẽ học sâu ở Bài 17). Vì vậy trong bài này, ta tập trung vào ba tầng làm việc hằng ngày, và chỉ giới thiệu Initiative ở mức khái niệm.
Epic — khối công việc lớn
Epic là một khối công việc lớn, thường tương ứng với một tính năng hoặc một mục tiêu mà đội phải mất nhiều sprint mới hoàn thành. Epic quá lớn để làm xong trong một sprint, nên nó đóng vai trò "cái ô" gom nhóm các Story/Task nhỏ hơn.
Ví dụ, với một ứng dụng thương mại điện tử, "Thanh toán qua ví điện tử" có thể là một Epic. Nó bao trùm nhiều việc: tích hợp MoMo, tích hợp ZaloPay, xử lý hoàn tiền, hiển thị lịch sử giao dịch... Mỗi việc đó sẽ là một Story riêng.
Dấu hiệu nhận biết một thứ nên là Epic:
- Nó là một mục tiêu kinh doanh hoặc một tính năng có thể mô tả bằng một câu ngắn.
- Nó kéo dài từ vài tuần đến vài tháng.
- Nó chứa nhiều đơn vị công việc nhỏ hơn có thể giao cho các thành viên khác nhau.
Story — đơn vị giá trị cho người dùng
Story (User Story) là đơn vị công việc mang lại giá trị trực tiếp cho người dùng cuối, và đủ nhỏ để đội hoàn thành gọn trong một sprint. Story thường được viết theo mẫu: "Là một [vai trò], tôi muốn [làm gì đó] để [đạt được lợi ích gì]."
Ví dụ trong Epic "Thanh toán qua ví điện tử": "Là một khách hàng, tôi muốn thanh toán đơn hàng bằng MoMo để không phải nhập lại thông tin thẻ mỗi lần mua." Đây là một Story hoàn chỉnh — nó có giá trị rõ ràng, có thể demo được cho khách hàng thấy, và làm xong trong một sprint.
Task — công việc không hướng người dùng
Task cũng nằm cùng tầng với Story, nhưng khác ở chỗ: 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", "Viết tài liệu API", "Nâng cấp thư viện lên phiên bản mới". Đây là những việc thật, cần theo dõi, nhưng không viết được thành user story vì người dùng cuối không "thấy" chúng.
Mẹo phân biệt nhanh: nếu bạn có thể demo kết quả cho khách hàng và họ gật đầu "ồ tính năng này hay" thì đó là Story. Nếu kết quả chỉ có ý nghĩa với đội kỹ thuật, đó là Task.
Bug — lỗi cần sửa
Bug là một issue type đặc biệt cùng tầng với Story/Task, dùng để ghi nhận lỗi trong sản phẩm. Ví dụ: "Nút Thanh toán không phản hồi trên Safari iOS". Bug thường có thêm các trường như bước tái hiện (steps to reproduce), kết quả mong đợi và kết quả thực tế. Ở đây ta chỉ cần nắm: về mặt phân cấp, Bug ngang hàng với Story và Task — nó cũng có thể nằm trong một Epic và có thể chứa Sub-task. (Quy trình triage bug chi tiết sẽ học ở Bài 26.)
Sub-task — bước nhỏ để hoàn thành
Sub-task là tầng thấp nhất, dùng để chia một Story/Task/Bug thành các bước nhỏ giao cho từng người hoặc từng giai đoạn. Ví dụ, Story "Thanh toán bằng MoMo" có thể tách thành các Sub-task: "Thiết kế UI màn hình thanh toán", "Gọi API MoMo phía backend", "Viết test tự động", "Cập nhật tài liệu".
Quy tắc vàng: Sub-task không thể tồn tại độc lập — nó luôn phải thuộc về một issue cha. Và Sub-task không được có Sub-task con — Jira không cho phép lồng sâu hơn một tầng ở đây.
Initiative — tầng chiến lược (Advanced Roadmaps)
Ở phía trên Epic là Initiative, một tầng gom nhóm nhiều Epic lại thành một sáng kiến chiến lược lớn. Ví dụ, Initiative "Nâng cấp trải nghiệm thanh toán năm 2026" có thể chứa các Epic: "Thanh toán qua ví điện tử", "Thanh toán trả góp", "Ví thành viên nội bộ". Tầng này chỉ khả dụng với Advanced Roadmaps (Jira Premium) và chủ yếu phục vụ điều phối nhiều đội. Bạn chỉ cần biết nó tồn tại; chúng ta sẽ đào sâu ở Bài 17.
Tình huống thực tế
Tình huống 1 — Startup fintech Sài Gòn tổ chức tính năng ví điện tử
Công ty PayZen (giả định) là một startup fintech ở Quận 1, TP.HCM với đội 8 người. Họ nhận yêu cầu xây dựng tính năng "Ví trả sau" cho ứng dụng mua sắm. PM mới vào — bạn Linh — ban đầu tạo mỗi việc thành một issue riêng, kết quả là backlog có 47 issue phẳng lì, không ai biết việc nào liên quan việc nào.
Sau khi được mentor hướng dẫn, Linh tổ chức lại như sau:
- Epic: "Ví trả sau (Buy Now Pay Later)"
- Story: "Là khách hàng, tôi muốn đăng ký hạn mức trả sau để mua hàng không cần thẻ"; "Là khách hàng, tôi muốn xem lịch trả nợ hằng tháng"
- Task: "Tích hợp API chấm điểm tín dụng của đối tác"; "Cấu hình cron job nhắc hạn thanh toán"
- Sub-task (dưới Story đăng ký hạn mức): "Thiết kế màn hình onboarding", "API xác thực CMND/CCCD", "Test luồng đăng ký"
Tình huống 2 — Agency phần mềm ở Đà Nẵng và lỗi "Epic to như con voi"
Một agency gia công phần mềm tại Đà Nẵng làm dự án cho khách Nhật. Đội mắc lỗi ngược lại với tình huống 1: họ tạo một Epic khổng lồ tên "Toàn bộ module Quản lý kho" và nhét tất cả 30 Story vào đó. Epic này kéo dài suốt 4 tháng, thanh tiến độ gần như đứng yên, khiến khách Nhật lo lắng hỏi "dự án có đang chạy không?".
Vấn đề: Epic quá lớn nên không bao giờ "hoàn thành" để tạo cảm giác tiến bộ. PM của agency chia lại "Quản lý kho" thành ba Epic nhỏ hơn: "Nhập kho", "Xuất kho", "Kiểm kê định kỳ". Mỗi Epic gói gọn trong 3–4 sprint và có thể bàn giao độc lập.
Bài học rút ra: Epic phải đủ lớn để đáng gom nhóm, nhưng đủ nhỏ để hoàn thành được trong một khoảng thời gian hợp lý (thường 1–3 tháng). Một Epic không bao giờ "done" sẽ giết chết động lực đội và niềm tin của khách hàng.
Tình huống 3 — Lạm dụng Sub-task ở một công ty edtech Hà Nội
Một công ty edtech ở Hà Nội có PM rất "chăm", tách mọi thứ thành Sub-task cực chi tiết: một Story đơn giản "Thêm nút chia sẻ bài học" bị chẻ thành 9 Sub-task, kể cả "Đặt tên biến CSS" và "Commit code". Kết quả: dev mất nhiều thời gian tick checkbox Sub-task hơn là code, và board Sprint rối như tơ vò.
Sau khi review, đội thống nhất: chỉ tạo Sub-task khi cần chia việc cho nhiều người hoặc theo dõi các giai đoạn tách bạch (ví dụ Design → Dev → QA). Story "Thêm nút chia sẻ" chỉ cần 2 Sub-task: "Frontend làm nút" và "QA kiểm thử".
Bài học rút ra: Sub-task là công cụ điều phối, không phải to-do list cá nhân. Đừng biến Jira thành nơi ghi chú vụn vặt — điều đó tạo ra "gánh nặng quản trị" (overhead) mà không mang lại giá trị.
Hướng dẫn từng bước
Dưới đây là quy trình thực hành để tổ chức một tính năng mới theo đúng phân cấp trong Jira Cloud:
- Xác định Epic trước. Khi nhận một yêu cầu tính năng lớn, tạo một Epic đặt tên rõ ràng theo giá trị kinh doanh, ví dụ "Đăng nhập bằng sinh trắc học". Trên giao diện Backlog, bấm nút Create Epic ở panel Epic bên trái (hoặc chọn Issue type = Epic khi tạo issue).
- Chia Epic thành Story và Task. Tự hỏi: "Để hoàn thành Epic này, đội cần giao những phần việc nào?" Mỗi phần việc mang giá trị cho người dùng → tạo Story. Mỗi phần việc kỹ thuật hậu trường → tạo Task. Khi tạo, nhớ gán trường Epic Link (hoặc Parent) trỏ về Epic vừa tạo.
- Viết Story theo mẫu chuẩn. Dùng công thức "Là [ai], tôi muốn [gì], để [lợi ích]". Điều này giúp đội hiểu tại sao làm, không chỉ làm cái gì.
- Kiểm tra kích thước Story. Nếu một Story ước lượng lớn hơn một sprint, hãy chẻ nhỏ nó thành nhiều Story. Đây gọi là "story splitting". Ví dụ "Thanh toán online" quá to → chẻ thành "Thanh toán qua MoMo", "Thanh toán qua thẻ Visa".
- Tạo Sub-task khi cần điều phối. Mở một Story, cuộn xuống mục Child issues / Sub-tasks, bấm Add sub-task. Chỉ tạo Sub-task khi việc cần chia cho nhiều người hoặc nhiều giai đoạn khác nhau.
- Gán và ước lượng. Story và Task được ước lượng bằng Story Point (học ở Bài 14). Sub-task thường ước lượng bằng giờ hoặc để trống, vì chúng chỉ là bước con.
- Kiểm tra bức tranh tổng thể. Vào Backlog hoặc dùng Roadmap để xem Epic đang gom bao nhiêu Story, tiến độ ra sao. Đây là lúc bạn xác nhận cấu trúc phân cấp đã sạch sẽ và logic.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm Story với Task. Rất nhiều PM mới tạo mọi thứ thành Task cho "nhanh". Hậu quả: báo cáo không phân biệt được việc tạo giá trị và việc hậu trường. Mẹo: luôn hỏi "khách hàng có thấy được kết quả này không?" — có thì Story, không thì Task.
Lỗi 2 — Epic dùng như thùng rác. Gom mọi issue linh tinh vào một Epic "Chung chung" khiến Epic mất ý nghĩa. Mẹo: mỗi Epic phải trả lời được câu hỏi "hoàn thành Epic này thì người dùng nhận được gì?".
Lỗi 3 — Lồng Sub-task quá sâu hoặc quá nhiều. Như tình huống edtech Hà Nội. Mẹo: nếu một Story cần hơn 5–6 Sub-task, có lẽ nó đáng ra phải là một Epic, và các Sub-task đó nên là Story.
Lỗi 4 — Quên gán Epic Link / Parent. Story bị "mồ côi", không thuộc Epic nào, nên không xuất hiện trên Roadmap và bị bỏ sót khi báo cáo. Mẹo: biến việc gán Parent thành bước bắt buộc trong Definition of Ready của đội.
Lỗi 5 — Nhầm phân cấp với workflow. Phân cấp (hierarchy) trả lời câu hỏi "việc này to hay nhỏ, thuộc việc nào"; còn workflow (To Do → In Progress → Done) trả lời "việc này đang ở giai đoạn nào". Đây là hai chiều hoàn toàn khác nhau. Mẹo: đừng tạo issue type mới chỉ để thể hiện trạng thái — trạng thái là việc của workflow (Bài 7).
Mẹo nâng cao: Trước khi bắt đầu một dự án, hãy thống nhất với đội một "quy ước phân cấp" bằng văn bản: khi nào là Epic, khi nào là Story, khi nào tách Sub-task. Một trang quy ước ngắn tiết kiệm cho bạn hàng chục cuộc tranh cãi sau này.
Bài tập thực hành
Hãy thực hành với tình huống sau để nắm chắc kiến thức:
Bối cảnh: Bạn là PM cho một ứng dụng giao đồ ăn tại Việt Nam. Ban giám đốc yêu cầu xây dựng tính năng "Đánh giá món ăn và nhà hàng" trong quý tới.
Yêu cầu:
- Xác định đây nên là một Epic hay nhiều Epic. Viết tên Epic (hoặc các Epic).
- Liệt kê ít nhất 4 Story theo đúng mẫu "Là [ai], tôi muốn [gì], để [lợi ích]". Gợi ý các góc nhìn: khách hàng đánh giá, khách hàng đọc đánh giá, nhà hàng phản hồi đánh giá, chủ app kiểm duyệt đánh giá bậy.
- Liệt kê ít nhất 2 Task (việc kỹ thuật hậu trường) cần thiết cho tính năng này.
- Chọn một Story bất kỳ và chẻ nó thành 2–3 Sub-task hợp lý theo giai đoạn Design → Dev → QA.
- Giải thích trong 2–3 câu: vì sao bạn chọn một số việc là Story và một số việc là Task.
Tóm tắt
Cấu trúc phân cấp trong Jira là xương sống của mọi hoạt động quản lý dự án. Bốn tầng làm việc hằng ngày của bạn là:
- Epic — khối công việc lớn, kéo dài nhiều sprint, gom nhóm các việc nhỏ hơn theo một mục tiêu/tính năng.
- Story — đơn vị mang giá trị trực tiếp cho người dùng, làm gọn trong một sprint, viết theo mẫu "Là [ai], tôi muốn [gì], để [lợi ích]".
- Task — việc cần làm nhưng không trực tiếp tạo giá trị nhìn thấy được cho người dùng (việc kỹ thuật hậu trường). Bug cùng tầng với Story/Task, dùng ghi nhận lỗi.
- Sub-task — bước nhỏ để hoàn thành một Story/Task/Bug, dùng khi cần chia việc cho nhiều người hoặc nhiều giai đoạn. Không tồn tại độc lập, không lồng sâu thêm.
Ghi nhớ ba nguyên tắc cốt lõi: (1) Epic phải đủ lớn để đáng gom nhóm nhưng đủ nhỏ để hoàn thành được; (2) phân biệt Story và Task bằng câu hỏi "người dùng có thấy được không"; (3) Sub-task là công cụ điều phối, không phải to-do list vụn vặt. Khi bạn tổ chức đúng phân cấp ngay từ đầu, mọi việc phía sau — lập sprint, ước lượng, báo cáo, vẽ roadmap — đều trở nên trơn tru và đáng tin cậy.