Giới thiệu

Product backlog là danh sách công việc được sắp xếp theo thứ tự, bao gồm những việc có thể cần thực hiện để đạt được kết quả mong muốn cho sản phẩm. Trong Jira, backlog không chỉ là tập hợp các ticket. Một backlog hữu ích kết nối mục tiêu kinh doanh với những phần giá trị có thể bàn giao cho khách hàng, làm rõ các điểm chưa chắc chắn và cung cấp đủ thông tin để nhóm quyết định bước tiếp theo. Mục tiêu của bài học này là xây dựng backlog hỗ trợ các cuộc trao đổi lập kế hoạch, chứ không đơn thuần là tạo thật nhiều issue trong Jira.

Hãy hình dung một công ty đang ra mắt cổng thông tin đăng ký dịch vụ tự phục vụ. Mục tiêu của ban lãnh đạo là giảm số lượt liên hệ bộ phận hỗ trợ và tăng tỷ lệ chuyển đổi dùng thử. Một backlog item như “cải thiện thanh toán” quá rộng để định hướng việc triển khai. Một item tốt hơn có thể mô tả khách hàng xem hóa đơn tiếp theo trước khi thanh toán, kèm tiêu chí nghiệm thu có thể quan sát và lý do rõ ràng cho mức độ ưu tiên. Backlog cần giúp trả lời được ba câu hỏi: chúng ta đang giải quyết vấn đề nào, kết quả có giá trị nhỏ nhất là gì, và vì sao nên thực hiện công việc này trước item khác?

Cấu trúc backlog trong Jira

Hãy bắt đầu bằng các epic khi công việc hướng đến một kết quả hoặc năng lực đáng kể, cần nhiều story liên quan để hoàn thành. Epic “Tự phục vụ đăng ký dịch vụ” có thể bao gồm các story về đổi gói dịch vụ, xem lịch sử thanh toán, tải hóa đơn và cập nhật thông tin thanh toán. Epic cung cấp cho các bên liên quan góc nhìn có ý nghĩa về mặt kinh doanh, trong khi từng story tạo thành đơn vị công việc vừa sức cho nhóm triển khai. Không nên dùng epic như từ đồng nghĩa với một phòng ban, một chủ đề mơ hồ hay toàn bộ một mảng sản phẩm chưa xác định rõ kết quả.

User story cần mô tả người dùng, hành động và lợi ích. Ví dụ: “Là quản trị viên tài khoản, tôi muốn tải hóa đơn đã thanh toán để có thể cung cấp hồ sơ tài chính đầy đủ cho công ty.” Cấu trúc này hữu ích vì làm rõ giá trị dự kiến, nhưng không thể thay thế việc làm rõ yêu cầu. Trong quá trình refinement, hãy xác nhận quyền hạn của người dùng, kết quả mong đợi, các trường hợp ngoại lệ quan trọng và phiên bản nhỏ nhất của năng lực có thể phát hành.

Trong Jira, hãy duy trì cấu trúc phân cấp và các trường nhất quán trong toàn dự án. Sử dụng loại issue và mối liên kết với epic được cấu hình cho dự án, sau đó thống nhất quy ước về tiêu đề story, nhãn, component và quyền sở hữu. Tránh tạo các trường tùy chỉnh riêng cho từng mong muốn của bên liên quan. Một trường chỉ có giá trị khi hỗ trợ một quyết định được đưa ra thường xuyên, chẳng hạn như lập kế hoạch phát hành, quản lý rủi ro hoặc báo cáo.

Viết story và tiêu chí nghiệm thu có thể kiểm thử

Tiêu chí chấp nhận xác định các điều kiện để một user story được chấp nhận. Chúng nên mô tả hành vi có thể quan sát được, không phải hướng dẫn triển khai. Với một user story về tải xuống hóa đơn, các tiêu chí có thể nêu rằng quản trị viên được cấp quyền có thể chọn một hóa đơn đã thanh toán, nhận được tệp chứa đúng số hóa đơn và tổng tiền, đồng thời thấy thông báo lỗi rõ ràng khi hóa đơn không khả dụng. Những phát biểu này giúp product owner, đội ngũ triển khai và tester có cùng cách hiểu trước khi công việc bắt đầu.

Các tiêu chí tốt bao quát cả luồng thông thường và những ngoại lệ quan trọng đối với hoạt động kinh doanh. Hãy đặt câu hỏi điều gì xảy ra khi người dùng không có quyền, dữ liệu bắt buộc bị thiếu, yêu cầu được lặp lại hoặc một dịch vụ bên ngoài không khả dụng. Đừng biến mọi trường hợp biên về kỹ thuật thành một yêu cầu riêng trước khi hiểu rõ tác động kinh doanh của chúng. Mục đích là loại bỏ những điểm mơ hồ đáng kể, đồng thời giữ cho user story đủ nhỏ để thảo luận và ước tính.

Một user story sẵn sàng được ưu tiên khi kết quả, người dùng, điều kiện chấp nhận và các giả định chính của nó đủ rõ ràng để có thể so sánh có ý nghĩa với những công việc khác. Nếu đội ngũ không thể ước tính vì chưa biết một quyết định quan trọng, hãy ghi nhận rõ sự không chắc chắn đó. Một hoạt động discovery hoặc spike ngắn có thể phù hợp hơn việc giả vờ rằng một user story lớn có thể được ước tính đáng tin cậy. Product owner cũng nên xác minh rằng user story có thể được trình diễn độc lập, ngay cả khi nhiều user story cùng thuộc một epic.

Ưu tiên và ước tính công việc

Mức độ ưu tiên nên thể hiện thứ tự mà tổ chức sẵn sàng xem xét việc triển khai. Hãy sử dụng giá trị kinh doanh, tác động đến khách hàng, tính cấp bách, mức độ giảm thiểu rủi ro, nhu cầu tuân thủ quy định và các ràng buộc về phụ thuộc làm cơ sở. Ví dụ, một yêu cầu nhỏ về bảo mật thanh toán có thể được ưu tiên cao hơn một dashboard dễ thấy vì nó làm giảm rủi ro đáng kể. Một quy trình dành cho khách hàng thí điểm có thể được ưu tiên cao khi cần thiết để kiểm chứng chiến lược sản phẩm, nhưng phải ghi nhận giả định và thời hạn thay vì che giấu chúng sau nhãn “khẩn cấp” chung chung.

Hãy tách biệt mức độ ưu tiên và khối lượng công việc. Một user story lớn có thể quan trọng nhưng khó thực hiện, trong khi một user story nhỏ có thể dễ làm nhưng mang lại ít giá trị. Việc ước tính giúp so sánh chi phí triển khai và hỗ trợ dự báo; nó không đo lường hiệu suất cá nhân. Các đội ngũ có thể sử dụng story point, kích thước áo phông hoặc một phương pháp đã thống nhất khác. Phương pháp cụ thể ít quan trọng hơn tính nhất quán, các giả định được chia sẻ và sự sẵn sàng xem xét lại ước tính khi xuất hiện thông tin mới.

Một cuộc trao đổi refinement thực tế có thể so sánh giá trị kỳ vọng của một hạng mục với công sức, rủi ro và mức độ nhạy cảm về thời gian của hạng mục đó. Hãy hỏi liệu hạng mục có đóng góp trực tiếp vào kết quả hiện tại hay không, việc trì hoãn có tạo ra chi phí đáng kể hay không, và liệu một phần nhỏ hơn có thể kiểm chứng cùng giả định đó hay không. Đừng xem một điểm số dạng số là câu trả lời tự động. Thứ tự cuối cùng vẫn là một quyết định về sản phẩm, được đưa ra dựa trên bằng chứng và năng lực của đội ngũ.

Phiên bản, phụ thuộc và quyết định phát hành

Hãy sử dụng phiên bản để thể hiện một mục tiêu triển khai đã được lên kế hoạch, chẳng hạn như “Cổng thông tin khách hàng Quý 3 năm 2025” hoặc “Bản phát hành thí điểm 1”. Một phiên bản là ranh giới phục vụ lập kế hoạch, không phải lời cam kết rằng mọi hạng mục hiện được gán cho phiên bản đó sẽ được phát hành. Chỉ gán một hạng mục vào một phiên bản khi mục tiêu đó có ý nghĩa và đội ngũ hiểu kết quả mà bản phát hành hướng tới. Hãy xem xét phạm vi phiên bản khi năng lực, rủi ro và bằng chứng từ khách hàng thay đổi.

Các phụ thuộc phải được hiển thị rõ vì chúng làm thay đổi thứ tự công việc khả thi. Một user story có thể phụ thuộc vào thay đổi của identity service, một quyết định pháp lý, một hoạt động di chuyển dữ liệu hoặc một hạng mục khác trong backlog. Hãy ghi nhận mối quan hệ trong Jira bằng các loại liên kết issue được dự án hỗ trợ, đồng thời nêu rõ nội dung nào đang bị chặn, bị chặn bởi yếu tố nào và vì sao. Một phụ thuộc không có người phụ trách hoặc ngày ra quyết định chỉ là một cảnh báo; nó không tạo ra hành động quản lý.

Ví dụ, user story “hiển thị hóa đơn hằng năm tổng hợp” có thể phụ thuộc vào việc đội ngũ dữ liệu xác nhận schema của hóa đơn và việc hoàn thành một user story về quyền trước đó. Backlog có thể xử lý theo nhiều cách: triển khai khả năng phân quyền sớm hơn, chia nhỏ user story về hóa đơn xoay quanh phụ thuộc đó, tạo một hạng mục discovery có giới hạn thời gian hoặc loại tính năng này khỏi bản phát hành. Đây là những quyết định kinh doanh về trình tự và rủi ro, không chỉ là việc bảo trì ticket.

Quy trình refinement và các lỗi thường gặp

Một chu kỳ refinement đáng tin cậy bắt đầu từ mục tiêu sản phẩm và bằng chứng hiện có từ khách hàng. Product owner đề xuất các hạng mục tiềm năng, các bên liên quan làm rõ giá trị và ràng buộc, còn đội ngũ delivery xem xét tính khả thi, các dependency và ước tính. Sau cuộc thảo luận, hãy cập nhật đồng thời story, tiêu chí, mức độ ưu tiên, ước tính và phiên bản. Một buổi review backlog chỉ hoàn tất khi các quyết định đã thay đổi được thể hiện rõ trong Jira và nhóm lập kế hoạch tiếp theo có thể hiểu chúng mà không cần tái dựng cuộc họp từ trí nhớ.

Một lỗi phổ biến là tạo các story quá lớn, chẳng hạn như “xây dựng báo cáo”. Chúng che giấu phạm vi, tạo ra các ước tính không ổn định và khiến việc thể hiện tiến độ trở nên khó khăn. Hãy chia nhỏ kết quả theo quyết định của người dùng hoặc năng lực có giá trị, chẳng hạn như xem chi tiêu theo phòng ban, xuất báo cáo đã lọc và cấu hình kỳ báo cáo. Một lỗi khác là xếp mọi thứ ở mức ưu tiên cao. Nếu mọi hạng mục đều khẩn cấp, backlog sẽ không hỗ trợ ra quyết định. Hãy buộc các bên đưa ra những đánh đổi rõ ràng và ghi lại lý do của các hạng mục đứng đầu.

Lỗi thứ ba là xem acceptance criteria như một checklist kỹ thuật hoặc sản phẩm tạo ra muộn trong quá trình kiểm thử. Cần thảo luận các tiêu chí trước khi ước tính để đội ngũ ước tính đúng kết quả mong muốn. Đồng thời, hãy chú ý đến các hạng mục đã lỗi thời: mức ưu tiên cũ, phiên bản không còn phù hợp, dependency chưa được xử lý và những story không còn hỗ trợ mục tiêu hiện tại. Hãy lưu trữ, viết lại hoặc hạ mức ưu tiên của chúng thay vì để quy mô backlog bị nhầm là tiến độ sản phẩm.

Tóm tắt

Một Jira backlog vững chắc chuyển hóa các mục tiêu kinh doanh thành các epic, user story nhỏ, acceptance criteria có thể kiểm thử, mức ưu tiên rõ ràng, các ước tính nhất quán, phiên bản có ý nghĩa và dependency được thể hiện rõ. Cấu trúc này có giá trị vì cải thiện chất lượng quyết định: các bên liên quan có thể so sánh kết quả, đội ngũ có thể xác định những điểm chưa chắc chắn và kế hoạch delivery có thể phản ánh các ràng buộc thực tế.

Refinement là một quá trình liên tục. Hãy xem xét lại thứ tự khi bằng chứng từ khách hàng, rủi ro, năng lực hoặc định hướng chiến lược thay đổi. Trước khi đưa một story vào một bản release, hãy xác nhận rằng giá trị đã được hiểu rõ, acceptance criteria có thể kiểm thử, ước tính đủ đáng tin cậy cho việc lập kế hoạch và các dependency đã có người phụ trách. Kết quả cần là một backlog sẵn sàng cho việc ra quyết định, không phải một danh sách tĩnh các yêu cầu.