Mối quan hệ giữa Epics, User Stories và Tasks là như thế nào trong việc thực hành Scrum và đặc biệt là mối quan hệ này khác nhau như thế nào khi so sánh giữa tiếp thị và phát triển phần mềm. Những khác biệt này đưa ra một kết luận rằng người làm tiếp thị khi áp dụng mô hình Scrum cần một cấu trúc thứ tư được gọi là Deliverable (chuyển giao)
Epics, User Stories và Tasks
Agile Marketer viết User stories để đảm bảo rằng họ hiểu những gì người mua đang cố gắng để thực hiện và tại sao người mua lại làm như thế. Phương pháp Scrum truyền thống định nghĩa một Epic như một User Story kéo dài hơn một Sprint, mặc dù như trình bày dưới đây thì Agile Marketer có xu hướng sử dụng Epics theo một cách khác. Còn Task là đơn vị thấp nhất của công việc, với mỗi Task thì sẽ được ước tính, giao cho thành viên trong team làm, và nó sẽ được di chuyển trong tiến trình của Kanban board từ đang làm sang hoàn thiện. Và như đã nói ở trên thì Agile Marketer cần thêm 1 cấu trúc thứ 4 là Deliverable.
User Story
User Story thường được viết theo cấu trúc As a [role], I want to [task], so that I can [goal or benefit] Trên mặt sau của tấm card, Developer thường liệt kê các tiêu chí chấp nhận hoặc Test case cho mỗi feature. Đối với Agile Marketing, User Story cung cấp cho Agile Marketer một sự hình dung rõ nét hơn về personas kết hợp với mỗi thị trường mục tiêu của họ cũng như là hướng marketer tập trungvào quan điểm và lợi ích của khách hàng. 
Epic
Epic: thể hiện luồng những hoạt động của người dùng. Ví dụ: từ xác định nhóm người dùng (Who) - Người bán hàng -> có nhu cầu quản lý người mua hoặc hàng hoá của họ (Backbone) -> Phần quản trị - backend quản lý sản phẩm tồn đọng (Epic) dành cho người bán hàng.
Mặc dù một Epic được định nghĩa như một User Story mà kéo dài hơn một Sprint, nhưng Agile Marketer lại có xu hướng sử dụng Enpic theo một cách rất khác. Hai cách dùng phổ biến là:
- Dùng Epic như một sáng kiến: nhiều công ty có sáng kiến kinh doanh hàng quý, hàng năm. Đây là những mục tiêu chiến lược cấp cao hoặc các hoạt động được thiết kế để đạt được mục tiêu nhất định. Một số team dựa vào những sáng kiến này để nhóm User Story và Deliverables của họ.
- Dùng Epic như là chức năng tiếp thị cốt lõi: một số team sẽ nhóm User Story và Deliverables của họ dựa vào chức năng chính. Ví dụ: nhóm lãnh đạo, nhóm bán hàng…
Deliverable
Tại sao các nhà tiếp thị cần cấu trúc thứ 4 này? Bởi vì marketer không giống như các developer thỏa mãn với User Story trong một điều kiện cơ bản. Khi các Đeveloper trình bày một User Story, họ nhận ra rằng có rất nhiều cách để đáp ứng User Story, nhưng họ chỉ thực hiện một trong những cách đó. Nhìn chung, thiết kế phần mềm tốt đồng nghĩa với việc tìm ra một cách thật rõ ràng để thực hiện, chứ không phải là tìm nhiều cách khác nhau để thực hiện các công việc tương tự. Cũng có ngoại lệ, nhưng chúng không phổ biến.
Tuy nhiên Marketer thì gần như luôn luôn cần phải thực hiện nhiều cách để thỏa mãn một User Story. Ví dụ, đối với một User Story như sau:
Là trưởng nhóm đánh giá, tôi muốn hiểu một cách nhanh chóng những gì phân biệt bạn với đối thủ của bạn để tôi có thể quyết định có bao gồm bạn trong danh sách các nhà cung cấp đang được xem xét hay không.
Một marketer có thể đáp ứng User Story này trên website, có thể thông qua một hội thảo hoặc cũng có thể là thể hiện trên tài liệu in, tờ rơi. Hay truyền đạt tới đội ngũ bán hàng thông qua các bài thuyết trình hoặc các buổi nói chuyện. Họ có thể cung cấp các kênh thông tin của họ tùy chỉnh nhằm đáp ứng User Story này. Các Marketer hầu như luôn luôn tạo ra các Deliverables khác nhau để đáp ứng cùng một User Story, tùy thuộc vào kênh thông tin và điểm tương tác.
Vì lý do này, Agile Marketer nên nghĩ ra một hệ thống phân cấp: User Story bao gồm nhiều Deliverables, trong đó lại bao gồm nhiều Task. Mỗi một Deliverable riêng biệt nên được hoàn thành trong một Sprint. User Story thường có thể kéo dài trong nhiều Sprints, và trong một số trường hợp, chúng có thể không bao giờ được "hoàn thành". Marketing team có thể tăng số lượng Deliverables lên không giới hạn nhằm đáp ứng những gì người dùng đang tìm kiếm.
Gợi ý Công cụ
Nếu bạn đang sử dụng các loại Deliverable, và có sự phân cấp giữa Epics, User Stories, Deliverables và Tasks thì bạn cần một công cụ hỗ trợ phân cấp và các mối quan hệ parent-child. Nhiều Kanban board tools đơn giản như Trello không hỗ trợ phân cấp. Có một add-in trên Chrome cho Trello được gọi là Ultimello hỗ trợ tạo mối quan hệ parent-child, nhưng nó chỉ hoạt động cho trình duyệt Chrome. Các công cụ khác, như Jira hoặc Asana cũng có hỗ trợ phân cấp như thế. Hãy cân nhắc khi lựa chọn công cụ hỗ trợ này.
Nguồn: http://www.agilemarketing.net/epics-user-stories-tasks/
