Trong các buổi huấn luyện và đào tạo Scrum, tôi thường gặp các câu hỏi như là “Một Product Backlog cần phải làm mịn bao nhiêu lần” và “Chúng ta cần phải làm mịn đến mức nào ?”
Trước tiên, hãy cùng nhìn lại các định nghĩa về Scrum
Thế nào là làm mịn Product Backlog ?
Theo định nghĩa về Scrum , Làm mịn Product Backlog chính là việc thêm vào các chi tiết, ước lượng và chuyển các items vào Product Backlog. Nhưng Scrum lại không quy định cách bạn làm thế nào và lý do tại sao
Làm mịn là 1 quá trình liên tục. Nó không bao giờ ngừng lại bởi vì requirement và các cơ hội phát không ngừng thay đổi. Việc làm rõ hết mọi thứ ngay ban đầu sẽ tạo ra sự lãng phí và cũng có thể dẫn đến sự chậm trễ trong việc chuyển giao các giá trị
Các sản phẩm khác nhau và các team khác nhau sẽ có những đòi hỏi riêng về số lần thực hiện, kỹ thuật và mức độ chi tiết khác nhau
Ngay cả khi một Scrum Team giống nhau đang làm việc trên cùng sản phẩm giống nhau thì cũng cần xây dựng cách thức để họ có thể dần làm mịn Product Backlog theo thời gian để phù hợp với những tình huống mới. Scrum Teams cần tìm ra họ cần làm gì và làm như thế nào
Tự tổ chức và kinh nghiệm
Áp dụng Nguyên tắc Goldilocks để giúp một nhóm thử nghiệm và tìm ra những gì phù hợp nhất với họ thông qua kiểm tra và điều chỉnh.
Nguyên tắc Goldilocks và Phương pháp làm mịn Product Backlog
Nguyên tắc Goldilocks là phương pháp tìm kiếm những gì là “vừa phải” cho nhóm của bạn.
Mục tiêu chính là cân bằng giữa lợi ích lấy được trong kinh doanh trong khi giảm thiểu lãng phí tiềm năng.
Trước tiên chúng ta hãy xem 6 lợi ích của việc sàng lọc Product Backlog:
- Tăng tính minh bạch
- Làm rõ giá trị
- Chia mọi thứ thành các phần có thể giải
- Giảm sự phụ thuộc
- Dự báo
- Kết hợp học tập
Bây giờ chúng ta hãy đi sâu hơn vào những điều trên để tìm ra phương pháp áp dụng được Nguyên tắc Goldilocks. Tôi sẽ cung cấp cho bạn một vài câu hỏi trong giai đoạn khởi đầu của từng lĩnh vực trên để giúp nhóm phát triển nhận ra tình hình.
#1 – Tăng tính minh bạch
Product Backlog là một công cụ giúp cung cấp tính minh bạch. Nó còn được gọi là “single source of truth” cho những kế hoạch sau này đối với sản phẩm. Thêm càng nhiều chi tiết sẽ càng làm tăng tính minh bạch cho những kế hoạch bạn đưa ra, cũng như là tiến trình của bạn.
Câu hỏi Goldilocks
- Các bên liên quan và Scrum team hiểu rõ những gì được lên kế hoạch cho sản phẩm?
- Có bao nhiêu lần các bên liên quan ngạc nhiên bởi những gì đã được giao?
#2 – Làm rõ giá trị
Khi bạn làm rõ các chi tiết xung quanh giá trị, kết quả bạn đang cố gắng đạt được cùng với Product Backlog Item (PBI) sẽ rõ ràng hơn.
Tại sao bạn muốn điều này? Lợi ích người dùng là gì? Lợi ích kinh doanh là gì?
2 câu hỏi trên giúp Nhóm phát triển xây dựng điều đúng đắn để đáp ứng nhu cầu. Điều này có thể ảnh hưởng đến những gì được yêu cầu, ước tính và đơn đặt hàng khi Product Owen và nhóm phát triển tìm ra những gì thực sự cần thiết. Những cuộc trò chuyện trả lời cho 2 câu hỏi trên sẽ tạo ra sự cảm thông khi được chia sẻ từ các bên.
Câu hỏi Goldilocks
- Bạn có thường xuyên phát hiện ra nếu trong một Sprint mà không có sự hiểu biết chung về nhu cầu kinh doanh hoặc những gì bạn đang xây dựng để đáp ứng nó?
- Bao nhiêu lần bạn phát hiện ra trong Sprint Review hoặc sau khi release các item trong Product Backlog PBI không đáp ứng nhu cầu của người dùng hoặc doanh nghiệp?
#3 – Chia mọi thứ thành các phần có thể giải quyết
Bạn muốn các PBI đủ nhỏ để Nhóm phát triển có thể hoàn thành nhiều hơn trong một Sprint. Việc có nhiều PBI trong một Sprint giúp nhóm có được sự linh hoạt để đáp ứng Sprint Goal và chyển giao được phần tăng trưởng
Câu hỏi Goldilocks
Bạn có thường xuyên chuyển giao được phần tăng trưởng hay không ? Bạn có thường xuyên không đạt được mục Spirnt Goadl hay không ?
Khi nào bạn phát hiện ra trong giai đoạn giữa spirnt, các PBI lớn hơn nhiều so với bạn nghĩ hoặc không được phân tích đủ chi tiết ?
#4 – Giảm sự phụ thuộc
Sự phụ thuộc thường trở thành chướng ngại vật và có thể khiến một đội dừng lại. Vì bạn không thể tránh được hết điều đó, bạn nên làm giảm chúng hết sức nếu có thể. . Điều này đặc biệt quan trọng khi các sự phụ thuộc đó bên ngoài Scrum Team. Bạn có thể cắt và chia PBI theo nhiều cách khác nhau. Bạn có thể order lại, hoặc hợp tác với các nhóm khác để giúp giải quyết sự phụ thuộc. Có rất nhiều sự lựa chọn, và ít nhất là bạn muốn sự phụ thuộc phải minh bạch
Câu hỏi Goldilocks
- Bạn có thường xuyên phát hiện ra sự phụ thuộc trong một Sprint gây nguy hiểm cho Sprint Goal không?
- Các PBI bị block ở một Sprint bởi sự phụ thuộc trong bao lâu?
- Khi nào bạn phải odder lại Product Backlog để tính đến các phụ thuộc? Và điều này có ảnh hưởng như thế nào đến khả năng tối ưu hóa giá trị của Product Owner?
# 5 – Dự báo
Một Product Backlog chi tiết kết hợp với thông tin về lịch sử khả năng cung cấp sản phẩm làm việc của Scrum team giúp bạn dự báo được tương lai. Một số sản phẩm cần được dự báo về một số Sprint trong tương lai để giúp truyền đạt các mong muốn về release với các bên liên quan. Các sản phẩm khác sẽ không có nhu cầu dự báo ngoài Sprint hiện tại.
Liên quan đến dự báo, bạn cũng có thể cần một Product Backlog được làm mịn để có được nhiều sự đầu tư. Scrum không cấm lập kế hoạch trước. Scrum chỉ đơn giản nói rằng hãy xem xét nỗ lực của bạn để làm như vậy. Và thực tế là bạn không thể dự đoán hoàn hảo tương lai trong một trường hợp phức tạp cho dù bạn có phân tích bao nhiêu.
Câu hỏi Goldilocks
- Cần bao nhiêu thời gian để người dùng, khách hàng và các bên liên quan khác thực hiện một tính năng hoặc chức năng mới? Sẽ có ảnh hưởng thế nào nếu các bên có ít thời gian hơn dự định?
- Người dùng, khách hàng và các bên liên quan khác cần chi tiết đến thế nào trong dự báo release ? Sẽ có ảnh hưởng thế nào nếu các bên có ít thời gian hơn dự định?
# 6 – Kết hợp học tập
Chủ nghĩa kinh nghiệm là kết hợp việc bạn học được gì khi bạn xây dựng sản phẩm, khi bạn hiểu rõ hơn về cách hiện thực hóa tầm nhìn sản phẩm, khi bạn thấy những thay đổi xảy ra trong môi trường của mình.
Câu hỏi Goldilocks
- Bạn thích ứng với Product Backlog như thế nào để chứng tỏ việc học những cái mới về khả năng phát triển của sản phẩm và cách người dùng phản ứng với các thay đổi?
- Những cơ hội nào đã bị bỏ lỡ? Điều gì ngăn cản bạn phản ứng sớm hơn?
Kéo tất cả lại với nhau
Bạn đã thảo luận các câu hỏi Goldilocks về lợi ích của việc làm mịn với Scrum team. (Retrospectives là một cơ hội tuyệt vời để thường xuyên có những cuộc trò chuyện này.) Bây giờ đã đến lúc Scrum team quyết định cách điều chỉnh quy trình của họ để làm mịn Product Backlog. Và trên hết, những câu hỏi đây Goldilocks là những câu hỏi mở và không đơn giản là chỉ trả lời có / không
Bạn đang tìm kiếm sự cân bằng , hoặc đơn giản chỉ là vừa đủ. Bạn muốn đạt được đủ các lợi ích của việc làm mịn trong khi giảm thiểu sự lãng phí của bạn.
Với thông tin thu được từ việc trả lời các câu hỏi từ 1-6, Scrum team hiện có thể phân tích các câu hỏi này với sự cân bằng giữa lợi ích và sự lãng phí.
Câu hỏi Goldilocks
- Bạn muốn làm mịn bao nhiêu lần? Và bạn muốn dành bao nhiêu thời gian để làm mịn về Product Backlog?
- Bạn muốn tham gia vào việc làm mịn với ai? Những kiến thức và quan điểm nào cần thiết? Làm thế nào bạn có thể chia sẻ được sự hiểu biết đó?
- Bạn muốn có bao nhêu iteam đã “Ready” ở Product Backlog của bạn? Theo bạn thì “Ready” có nghĩ là gì?
- Bạn muốn truyền đạt chi tiết quan trọng về các PBI như thế nào? Phương pháp nào đang hoạt động tốt và phương pháp nào không?
- Làm thế nào đảm bảo bạn có thể nhìn thấy toàn bộ và không bị sa lầy vào chi tiết?