Product Backlog là gì?
Product Backlog là danh sách công việc đi từ Epic (những mảng việc lớn, có thể phải dành vài tháng để hoàn thiện) đến Features (các tính năng, các phần nhỏ hơn của mảng việc lớn, có thể làm theo vài tuần) đến User Stories (chi tiết hạng mục phát triển được quy về thời lượng vài ngày).
Không chỉ đội phát triển phần mềm mới sử dụng được Product backlog, tất cả các team đều sử dụng được Product Backlog như là một kho lưu trữ các hạng mục công việc.
Đọc thêm: Jira là gì? Tất tần tật về Jira Software
Nếu như Product Backlog của team phát triển sản phẩm là danh sách các tính năng, thì Product Backlog của team Marketing là danh sách các sản phẩm hướng tới mục tiêu tạo lead như 1 tài liệu website, video, landing page giới thiệu sản phẩm.
Tại sao cần Product backlog?
Product backlog là một danh sách có thứ tự các nhiệm vụ, tính năng hoặc các hạng mục cần hoàn thành trong một roadmap lớn.
Việc tạo ra sản phẩm bắt đầu từ một ý tưởng và cần một nhóm chuyên dụng để tạo ra một thứ gì đó đặc biệt. Đúng vậy, ngay cả iPhone cũng đã từng chỉ là một mẫu thử nghiệm đã trở nên phổ biến rộng rãi nhờ vào đội ngũ phù hợp. Khi quản lý một nhóm các nhà phát triển Scrum, việc duy trì tổ chức là yếu tố quan trọng để sản phẩm thành công.
Vậy làm thế nào để các nhóm phát triển luôn có tổ chức và đạt được mục tiêu của họ? Đó chính là to-do list phù hợp và đã được kiểm chứng. Một product backlog về cơ bản là một danh sách việc cần làm chuyên biệt. Nếu nhóm của bạn sử dụng phương pháp Agile, product backlog có thể giúp bạn chia nhỏ các dự án và xác định nhiệm vụ nào là quan trọng nhất.
Đôi khi, có nhiều product backlog với nhiều nhóm làm việc trên một sản phẩm lớn hơn. Ví dụ Adobe Creative Cloud. Creative Cloud là một “thương hiệu hình ô” (umbrella product), với các sản phẩm nhỏ hơn như Photoshop, Illustrator và After Effects bên trong nó. Mỗi sản phẩm nhỏ hơn này sẽ có product backlog riêng và các nhóm được chỉ định để phát triển.
Một product backlog bắt nguồn từ product roadmap, trong đó giải thích kế hoạch hành động để sản phẩm sẽ phát triển như thế nào. Các nhà phát triển sử dụng các nhiệm vụ trong product backlog để đạt được kết quả mong muốn nhanh nhất có thể.
Các nhóm Agile dành thời gian cho việc tạo ra sản phẩm và thực hiện các điều chỉnh khi dự án tiến triển. Do phương pháp Agile, các nhiệm vụ về product backlog không được thiết lập sẵn và không phải tất cả các mục trong product backlog đều sẽ được hoàn thành. Nhóm phát triển đều nên tinh chỉnh các product backlog khi họ ưu tiên các nhiệm vụ cần thiết.
Ai sở hữu Product Backlog?
Product Owner là người chịu trách nhiệm quản lý và bảo trì Product Backlog. Cụ thể họ sẽ:
- Xác định các tính năng, hạng mục cần được phát triển.
- Đánh giá độ ưu tiên của các hạng mục và sắp xếp chúng theo thứ tự ưu tiên từ cao đến thấp.
- Làm mịn các hạng mục.
- Làm rõ và đảm bảo các hạng mục này minh bạch tới tất cả các bên.
Có gì trong một product backlog?
Một product backlog thường bao gồm các tính năng (feature), bug fix, technical debt và Knowledge acquisition (thu thập kiến thức). Các hạng mục product backlog này là những phần công việc riêng biệt chưa được giao cho một sản phẩm.
Tính năng (user story)
Feature, còn được gọi là user story, là một chức năng của sản phẩm mà người dùng sản phẩm thấy có giá trị. Các tính năng có thể phức tạp – thường được gọi là epic – hoặc chúng có thể đơn giản. Tạo story map có thể giúp nhóm của bạn xác định những gì người dùng cần nhất.
Bug fix
Nhóm Scrum nên nhanh chóng giải quyết những bug này để duy trì tính toàn vẹn của sản phẩm. Một số bug có thể đủ quan trọng để làm gián đoạn sprint hiện tại của nhóm, trong khi những bug khác có thể đợi sprint tiếp theo để fix. Tuy nhiên, một quy tắc tổng thể đối với bug là giữ chúng ở đầu product backlog (ưu tiên) để nhóm của bạn không quên chúng.
Technical debt
Technical debt, giống như nợ tài chính sẽ “cộng dồn lãi suất” khi bị bỏ qua. Khi các nhà phát triển đẩy công việc kỹ thuật xuống đáy của product backlog, nó sẽ tích tụ và khó hoàn thành hơn. Nhóm của bạn có thể ngăn chặn tích tụ Technical debt bằng cách duy trì tổ chức và thực hiện công việc kỹ thuật với quy mô nhỏ hơn, hàng ngày.
Knowledge acquisition
Knowledge acquisition liên quan đến việc thu thập thông tin để hoàn thành các nhiệm vụ trong tương lai. Nếu nhóm của bạn có một tính năng mà họ không thể hoàn thành nếu không nghiên cứu thêm, thì bạn sẽ tạo một nhiệm vụ thu thập kiến thức chẳng hạn như prototype, thử nghiệm hoặc POC (proof of concept) để có được thông tin cần thiết cho tính năng đó.
Các tồn đọng sản phẩm tốt có những đặc điểm tương tự, mà Mike Cohn và Roman Pichler đã nắm bắt được với từ viết tắt DEEP: Chi tiết phù hợp, Nổi bật, Ước tính, Ưu tiên. Chúng ta hãy xem xét kỹ hơn từng đặc điểm này.
Các đặc điểm của một backlog tốt
Detailed appropriately – Đủ chi tiết hợp lý
Các product backlog sẽ khác nhau về mức độ chi tiết của chúng. Những công việc mà chúng ta sẽ giải quyết sớm hơn, những công việc ở phần đầu của product backlog, sẽ chi tiết hơn. Những thứ mà chúng ta sẽ không giải quyết trong một thời gian sẽ ít chi tiết hơn. Chúng ta sẽ cần tinh chỉnh (thêm chi tiết vào) các mục tồn đọng khi chúng tăng mức độ ưu tiên, thêm chi tiết theo cách vừa đủ, đúng lúc.
Emergent – thay đổi liên tục
Như đã thảo luận trong các chương trước, product backlog là một tài liệu “sống”, liên tục thay đổi khi sản phẩm đang được phát triển hoặc bảo trì. Khi nhóm và Product owner tìm hiểu thêm về sản phẩm và thị trường, họ có thể thêm các mặt hàng mới, loại bỏ một số và thay đổi các mặt hàng khác. Bản chất nổi bật của product backlog không chỉ được mong đợi mà còn là dấu hiệu của việc tồn đọng sản phẩm đang hoạt động và lành mạnh.
Estimated – Ước lượng
Vào thời điểm thích hợp, mỗi product backlog cần có một ước tính kích thước tương ứng với nỗ lực cần thiết để phát triển mặt hàng đó. Chủ sở hữu sản phẩm sử dụng những ước tính này để giúp xác định mức độ ưu tiên của các item trong product backlog. Lý tưởng nhất là hầu hết các mục ở đầu product backlog sẽ có kích thước vừa với sprint, đủ nhỏ để có thể xử lý trong một lần sprint. Các mục lớn, có mức độ ưu tiên cao nên được chia thành các story nhỏ hơn trước khi start sprint.
Prioritized – Ưu tiên
Một product backlog phải là danh sách các PBI được ưu tiên, nhưng không phải mọi PBI đều cần được ưu tiên. Tôi khuyên bạn nên ưu tiên về giá trị phát hành của PBI. Ưu tiên vượt quá mức đó có thể là một sự lãng phí công sức, vì quá nhiều thứ có thể thay đổi vào thời điểm bản phát hành đầu tiên được phát hành. Thay vào đó, hãy ưu tiên các mặt hàng mới khi chúng xuất hiện và để dành các item chưa giải quyết được lùi lại sau.
Cách tạo product backlog
Một product backlog không chỉ là một danh sách việc cần làm đơn giản. Bạn có thể chia các nhiệm vụ phức tạp thành một loạt các bước và phân chia (assign) chúng cho các thành viên trong nhóm tương ứng. Dưới đây là các bước để phát triển một product backlog hiệu quả.
Product Roadmap
Product Roadmap là nền tảng cho việc product backlog. Nhóm của bạn nên tạo một roadmap trước khi tạo product backlog bởi vì roadmap là một kế hoạch hành động cho việc sản phẩm của bạn sẽ thay đổi như thế nào khi nó phát triển. Roadmap là tầm nhìn để phát triển sản phẩm dài hạn, nhưng nó cũng có thể phát triển.
Liệt kê các item trong product backlog
Lưu ý đến product roadmap của bạn, nhóm của bạn có thể bắt đầu liệt kê các item trong backlog của sản phẩm. Những mục này có thể bao gồm những mục có mức độ ưu tiên cao và những ý tưởng trừu tượng hơn. Trong giai đoạn tạo product backlog này, bạn cũng cần giao tiếp với các bên liên quan và lắng nghe ý kiến của họ để cải tiến sản phẩm. Bạn có thể tham khảo các mẫu product backlog ở Jira để bắt đầu dễ dàng hơn.
Thứ tự Ưu tiên
Sau khi nhóm của bạn liệt kê tất cả các item trong product backlog đã đến lúc bạn phải sắp xếp chúng và ưu tiên những nhiệm vụ nào là quan trọng nhất. Bạn có thể xác định các item hàng đầu bằng cách đặt mình vào vị trí khách hàng và cân nhắc xem mặt hàng nào mang lại giá trị nhất cho họ.
Cập nhật thường xuyên
Khi nhóm của bạn làm việc thông qua product backlog, hãy nhớ rằng product backlog luôn luôn thay đổi. Bạn có thể liên tục thêm các mục vào product backlog và ưu tiên hoặc tinh chỉnh các mục khi bạn làm việc với chúng.
Cách ưu tiên các item trong Product backlog
Một thành phần thiết yếu của việc quản lý product backlog là ưu tiên các nhiệm vụ. Với tư cách là chuyên gia Scrum, bạn nên hiểu kỹ về những tính năng mới mà các bên liên quan muốn thấy trong sản phẩm. Dưới đây là một số chiến lược về cách ưu tiên các mục trong backlog.
Sắp xếp các công việc theo mức độ khẩn cấp và quan trọng
Khi tập trung vào việc sàng lọc product backlog, hãy thử sắp xếp các nhiệm vụ theo mức độ khẩn cấp và tầm quan trọng. Nhóm nên ưu tiên các item giúp cải thiện chức năng của sản phẩm cũng như trải nghiệm người dùng.
Giải quyết các nhiệm vụ phức tạp trước
Một số team có xu hướng hoàn thành các nhiệm vụ đơn giản trước để có thể kéo done và rút ngắn backlog, nhưng đây là hình thức quản lý dự án kém hiệu quả hơn. Việc product backlog sẽ tiếp tục phát triển, vì vậy việc giải quyết các nhiệm vụ phức tạp trước tiên có thể đem lại hiệu quả bất ngờ khi phát triển sản phẩm.
Hoàn thành nhiệm vụ trong khoảng thời gian tập trung
Các Agile team làm việc tập trung vào các sprint để hoàn thành công việc và phương pháp này mang lại hiệu quả cao về năng suất. Vào cuối mỗi sprint, Product Owner và bất kỳ bên liên quan nào có thể tham dự buổi sprint review và buổi sprint retrospective với nhóm phát triển để đảm bảo mọi thứ đều đi đúng hướng.
Giao tiếp với nhóm
Giao tiếp giữa các thành viên trong nhóm là một phần quan trọng của việc ưu tiên product backlog. Để sắp xếp thành công product backlog và hoàn thành các hạng mục trong một khung thời gian hợp lý, bạn và nhóm của mình phải làm việc cùng nhau và tuân theo hướng dẫn Scrum.
Ví dụ về product backlog
Các product backlog của mỗi dự án sẽ khác nhau nhưng một số bắt đầu bằng một epic. Epic là một vấn đề bao trùm mà bạn đang cố gắng giải quyết cho khách hàng. Dưới đây là một ví dụ bên dưới:
Epic: Một giám đốc tiếp thị muốn có một hệ thống quản lý nội dung cho phép cung cấp nội dung chất lượng cho độc giả.
Epic này có thể dẫn đến nhiều tính năng sản phẩm khác nhau, từ cách người dùng tạo nội dung trong hệ thống mới đến cách họ chỉnh sửa và chia sẻ nội dung với các nhóm. Để tiếp tục ví dụ về việc product backlog, chúng ta có thể chia Epic thành các user story cụ thể hơn.
User story 1: Content creator muốn có một hệ thống quản lý nội dung cho phép họ tạo nội dung để có thể thông báo cho khách hàng về sản phẩm.
User story 2: Editor muốn có một hệ thống quản lý nội dung cho phép họ đánh giá nội dung trước khi xuất bản để họ có thể đảm bảo nội dung đó được viết tốt và được tối ưu hóa cho tìm kiếm.
Product Owner, Scrum master và nhóm phát triển sẽ xác định các tính năng mà sản phẩm nên bao gồm từ các user story và ưu tiên chúng dựa trên mức độ quan trọng.
Các tính năng mà sản phẩm nên bao gồm cho User story 1:
- Đăng nhập vào hệ thống quản lý nội dung
- Tạo nội dung
- Chỉnh sửa một trang nội dung
- Lưu thay đổi
- Gửi nội dung cho editor để review
Với tư cách là product manager, bạn sẽ sử dụng Epic để hướng dẫn product roadmap và các mục trong backlog. Như bạn có thể thấy với ví dụ này, một Epic có thể dẫn đến nhiều user story và tính năng sản phẩm.
Product backlog có thể giúp gì cho nhóm của bạn?
Việc product backlog giúp nhóm của bạn hoạt động trơn tru hơn nhiều bằng cách cải thiện khả năng tổ chức và cộng tác. Nó trở thành công cụ trung tâm để giao tiếp và giúp mọi người phù hợp với mục tiêu và kỳ vọng.
Do tất cả các công việc cho một sản phẩm đều qua backlog, product backlog sẽ cung cấp cơ sở cho việc lập kế hoạch lặp lại. Vì nhóm của bạn sắp xếp thứ tự ưu tiên các nhiệm vụ với sự hướng dẫn từ Product Owner, họ cũng sẽ xác định mức độ công việc mà họ có thể cam kết trong một khoảng thời gian cụ thể. Các khoảng thời gian này được gọi là vòng lặp (iterations) hoặc sprints.
Product backlog cũng thúc đẩy phát triển nhóm Agile bằng cách khuyến khích một môi trường làm việc linh hoạt nhưng hiệu quả. Các nhiệm vụ đối với product backlog không được thiết lập sẵn và nhóm sắp xếp chúng theo thứ tự quan trọng trước khi chọn nhiệm vụ nào cần giải quyết trước.
So sánh Sprint backlog vs Product backlog
Các sprint backlog và product backlog rất giống nhau về thành phần của chúng. Các sprint backlog là một tập hợp con của các product backlog, nhưng chúng được sử dụng đặc biệt trong các sprint.
Product Owner có quyền kiểm soát việc product backlog vì nó có toàn bộ sản phẩm từ đầu đến cuối. Nhóm phát triển sở hữu mỗi sprint backlog bởi vì những danh sách việc cần làm nhỏ hơn này được lấy từ product backlog có nghĩa là phải hoàn thành trong một khoảng thời gian được chỉ định.
Sprint backlog phụ thuộc vào product backlog, và nó kết thúc khi sprint kết thúc. Một sprint backlog cũng sẽ có mục tiêu sprint của riêng nó được phát triển trong phiên planning của sprint trong khi Product backlog tập trung vào toàn bộ mục tiêu của sản phẩm và các nhiệm vụ được ưu tiên dựa trên mục tiêu đó.
Công việc product backlog linh hoạt hơn công việc sprint backlog và rất đa tùy theo nhu cầu của khách hàng. Các product backlog sẽ luôn được cập nhật liên tục cho đến khi sản phẩm được hoàn thiện.
Nhìn lại ví dụ product backlog ở trên, chúng ta cũng có thể tạo một ví dụ sprint backlog. Khi phát triển một phụ kiện ô tô để giúp lái xe dễ dàng hơn, một nhiệm vụ của product backlog là tạo ra một prototype của phụ kiện đó. prototype này có thể trở thành sprint goal của một sprint vì nó có thể mất một tập hợp các nhiệm vụ để phát triển.
Các hạng mục sprint backlog cho prototype phụ kiện ô tô có thể bao gồm:
- Tạo một bản phác thảo ý tưởng
- Phát triển một nguyên mẫu ảo
- Xây dựng một nguyên mẫu vật lý
- Tìm nhà sản xuất để xây dựng nguyên mẫu
- Các mục sprint backlog này cũng sẽ nằm trên product backlog, nhưng việc tách chúng thành sprint của riêng họ có thể giúp các lập trình viên thông qua quy trình Scrum khi họ hoàn thành các nhiệm vụ này và tạo prototype một cách nhanh chóng.
Những điều cần chú ý khi tạo product backlog
Chỉ dùng một trình theo dõi để quản lí
Bạn không nên sử dụng nhiều hệ thống để track bug, yêu cầu và các hạng mục công việc kỹ thuật. Nếu nó hoạt động cho nhóm phát triển, hãy giữ nó trong một backlog.
Xóa các issue không đụng tới
Một khi backlog phát triển vượt quá capacity trong dài hạn, bạn có thể close các issue mà nhóm sẽ không có thời gian để giải quyết. Gắn cờ các issue đó với một giải pháp cụ thể như “out of scope” trong trình theo dõi vấn đề của nhóm để sử dụng cho nghiên cứu sau này.
Product Owner quyết định mức độ ưu tiên
Product Owner quyết định mức độ ưu tiên của các hạng mục công việc trong backlog. Trong khi nhóm phát triển quyết định velocity thông qua backlog. Đây có thể là một mối quan hệ không mấy dễ dàng đối với các Product Owner mới, những người muốn “thúc đẩy” công việc cho nhóm.
Nếu các bạn có nhu cầu tư vấn đào tạo các công cụ Agile như Jira hãy liên hệ Biplus – Đối tác số 1 của Atlassian tại Việt Nam để được hỗ trợ tốt nhất.
