Epic
Khối công việc lớn, thường mất nhiều sprint, được chẻ dần thành feature rồi user story. Là cách gom nhóm để nhìn tổng thể, không phải một cấu phần của Scrum Guide.
Định nghĩa
Bạn có một khối việc quá to để nhét vừa một sprint, và cũng chưa đủ rõ để viết ra thành từng story cụ thể. Đó là lúc người ta gọi nó là epic. Ví dụ "cho phép khách trả góp qua thẻ tín dụng" — nghe thì một câu, nhưng bên trong có tích hợp ngân hàng, tính lãi, hiển thị kỳ hạn, đối soát, hoàn tiền, và cả phần chăm sóc khách hàng.
Một chi tiết nên biết sớm: epic không nằm trong Scrum Guide. Scrum chỉ nói tới Product Backlog Item. Epic, feature, story, task là cách các công cụ như Jira và các khung mở rộng như SAFe tổ chức backlog. Mỗi nơi định nghĩa hơi khác nhau, nên đừng cãi nhau về định nghĩa chuẩn, hãy thống nhất quy ước trong nội bộ team và ghi nó ra.
Epic là cái nhãn để nhóm việc lại cho dễ nhìn và dễ báo cáo, chứ bản thân nó không bao giờ được đem đi code trực tiếp.
Epic to cỡ nào là vừa
Không có luật cứng, nhưng vài mốc thực dụng:
- Chẻ ra được từ 5 đến 30 story. Ít hơn 5 thì có lẽ nó chỉ là một feature. Nhiều hơn 30 thì nên tách thành hai epic.
- Làm xong trong khoảng 1 đến 3 tháng. Epic kéo cả năm sẽ chẳng bao giờ đóng và mất luôn tác dụng theo dõi.
- Trả lời được câu "làm xong cái này thì người dùng làm được gì mà trước đây không làm được".
Phân biệt Epic, Feature, User Story và Task
| Cấp | Ai quan tâm | Kích cỡ | Ai viết |
|---|---|---|---|
| Epic | Stakeholder, ban lãnh đạo | Nhiều sprint | PO, có BA hỗ trợ |
| Feature | PO, BA, khách hàng | 1 đến vài sprint | PO, BA |
| User Story | Team, người dùng cuối | Vừa 1 sprint, thường vài ngày | BA, PO, cả team ở buổi refinement |
| Task | Chỉ Developers | Vài giờ đến 1 ngày | Chính người làm |
Ranh giới giữa epic và feature là chỗ mờ nhất. Nhiều team Việt Nam bỏ hẳn tầng feature, chỉ dùng Epic rồi Story — hoàn toàn ổn nếu sản phẩm không quá lớn. Thêm một tầng chỉ để cho giống SAFe thì mỗi lần đổi trạng thái phải cập nhật thêm một chỗ, đổi lại chẳng được gì.
Ví dụ thực tế: chẻ một epic thanh toán
Sàn thương mại điện tử ngành thời trang. Cứ 100 người bấm vào giỏ hàng thì 38 người bỏ ngang ở đúng bước thanh toán — trên nền 8.400 đơn mỗi ngày, đó là khoản tiền ai cũng hình dung được.
Epic: Mở rộng phương thức thanh toán để giảm bỏ giỏ ở bước cuối.
Chẻ thành feature:
- Thanh toán bằng ví điện tử
- Trả góp qua thẻ tín dụng
- Lưu thẻ cho lần mua sau
Lấy riêng feature "Thanh toán bằng ví điện tử", chẻ tiếp thành story:
- Là người mua, tôi muốn chọn ví điện tử ở bước thanh toán để trả tiền mà không cần nhập thẻ.
- Là người mua, tôi muốn thấy thông báo rõ ràng khi thanh toán thất bại để biết mình nên làm gì tiếp.
- Là nhân viên vận hành, tôi muốn xem trạng thái đối soát theo ngày để phát hiện giao dịch treo.
- Là người mua, tôi muốn được hoàn tiền về ví trong 24 giờ khi hủy đơn chưa giao.
Story số 1 chẻ tiếp thành task của dev: gọi API tạo giao dịch, xử lý callback, lưu log đối soát, dựng màn hình chọn ví, viết unit test. Task là chuyện nội bộ của Developers, PO không cần duyệt từng cái.
Để ý story 3: nó không phục vụ người mua mà phục vụ vận hành. Epic nào đụng tới tiền thì gần như luôn có một nhánh story cho đội vận hành, và đây là chỗ BA mới đi làm hay quên nhất.
Lỗi hay gặp
- Đặt tên epic theo module kỹ thuật: "Epic: Module Payment", "Epic: Refactor service". Nhìn vào không biết đem lại giá trị gì cho ai.
- Epic sống mãi. Mở từ tháng 1, tháng 12 vẫn còn 3 story lửng lơ vì không ai dám đóng.
- Chẻ epic ra thành story theo tầng kỹ thuật: story làm database, story làm API, story làm giao diện. Kiểu này không story nào giao được giá trị độc lập, và tới cuối mới biết mình sai.
- Ước lượng story point cho epic rồi đem cộng vào velocity. Epic nên ước lượng thô bằng cỡ áo (S, M, L) hoặc bằng khoảng thời gian, để dành story point cho story.
Nếu đang bí chỗ chẻ, thử vẽ user story map cho epic đó. Nhìn theo trình tự người dùng làm việc thì đường cắt thường tự hiện ra.
