Backlog refinement là gì? Cách làm để không tốn thời gian

Gần hai tiếng refinement, ba mục được ước lượng

Bạn làm PO cho ứng dụng đặt trà của một cửa hàng trà online. Chiều nay team có buổi refinement. Bạn chiếu backlog lên màn hình và đi từ trên xuống: mười hai mục, có mục cho sprint tới, có mục chỉ là ý tưởng “một ngày nào đó”.

Mục đầu tiên là “Làm lại giỏ hàng”. Team bàn gần bốn mươi phút: làm lại phần nào, giao diện ra sao, có cần lưu giỏ khi khách đăng xuất không. Mục thứ hai là “Tích điểm thành viên”. Một bạn dev hỏi mười điểm đổi được gì, điểm có hết hạn không. Bạn không biết. Ba người bắt đầu đoán. Cuối buổi, team chỉ ước lượng được ba mục, ai cũng mệt, và tuần sau sprint planning vẫn có những mục chưa rõ.

Đây là tình huống minh họa. Buổi họp không tệ vì team lười hay vì bạn kém. Nó tốn thời gian vì thiếu ba thứ: phạm vi hẹp, phần đọc trước, và một cách dừng tranh luận khi không ai trong phòng có câu trả lời. Bài này đi qua từng thứ, kèm mẫu để bạn dùng cho buổi tới.

Backlog refinement là gì?

Backlog là danh sách có thứ tự những việc team có thể làm cho sản phẩm. Mỗi dòng trong đó gọi là một mục backlog (Product Backlog item), có thể là một user story, một lỗi cần sửa, hay một việc kỹ thuật.

Scrum Guide 2020 định nghĩa refinement là việc chia nhỏ và làm rõ thêm các mục backlog, để chúng nhỏ hơn và chính xác hơn. Đây là một hoạt động diễn ra liên tục, nhằm thêm chi tiết như mô tả, thứ tự và kích thước (size, tức ước lượng công sức).

Hai điểm trong Scrum Guide đáng nhớ với PO mới:

• Developers là người ước lượng. Developers ở đây là những người trong Scrum Team trực tiếp làm ra sản phẩm, có thể gồm dev, QA, designer. Scrum Guide viết rằng những Developers sẽ làm việc đó chịu trách nhiệm về sizing. PO có thể giúp họ hiểu và chọn các đánh đổi, nhưng không đưa ra con số thay họ.
• PO chịu trách nhiệm quản lý backlog hiệu quả: viết và truyền đạt các mục backlog, sắp thứ tự, và giữ backlog minh bạch, dễ hiểu. PO có thể nhờ người khác làm một phần, nhưng vẫn là người chịu trách nhiệm.

Scrum Guide cũng nói các mục mà Scrum Team có thể làm xong trong một sprint được xem là sẵn sàng để chọn ở Sprint Planning, và chúng thường đạt độ rõ đó sau các hoạt động refinement. Nói cách khác, refinement tốt là thứ làm cho sprint planning nhẹ đi.

Refinement có phải là buổi họp bắt buộc không?

Không. Scrum có năm sự kiện: Sprint, Sprint Planning, Daily Scrum, Sprint Review và Sprint Retrospective. Refinement không nằm trong danh sách đó. Scrum.org cũng nói rõ refinement không phải là một sự kiện Scrum, mà là một hoạt động liên tục được nhắc tới trong Scrum Guide.

Vì vậy Scrum Guide không quy định refinement kéo dài bao lâu, ai bắt buộc phải có mặt, hay họp mấy lần mỗi sprint. Nhiều team chọn một buổi refinement định kỳ vì dễ sắp lịch. Đó là lựa chọn của team, không phải luật của Scrum. Refinement cũng có thể diễn ra qua một cuộc trao đổi mười phút giữa PO và một dev, hay qua bình luận trong ticket.

Nếu team cần một con số để bắt đầu, Mountain Goat Software đưa ra quy tắc kinh nghiệm: khoảng 5 đến 10 phần trăm công sức mỗi sprint dành cho refinement. Hãy xem đây là điểm xuất phát để điều chỉnh, không phải chuẩn bắt buộc. Cùng nguồn đó cũng nói không có đồng thuận về việc ai nên tham dự, và khuyên giữ buổi họp ngắn nhất có thể.

Vì sao buổi refinement dễ tốn thời gian?

Một buổi refinement dài mà ít kết quả có thể đến từ nhiều nguyên nhân. Với PO mới, sáu nguyên nhân dưới đây đáng kiểm tra trước.

• Mang quá nhiều mục. Khi mọi thứ trong backlog đều được đem ra bàn, team tốn sức cho những việc còn nhiều tháng nữa mới làm, và những việc gần nhất lại không đủ thời gian.
• Team thấy mục lần đầu trong phòng họp. Mọi người phải vừa đọc, vừa hiểu, vừa nghĩ cách làm cùng lúc. Câu hỏi đáng lẽ hỏi trước lại xuất hiện giữa buổi.
• Bàn giải pháp trước khi rõ vấn đề. Mục “Làm lại giỏ hàng” không nói khách đang gặp khó ở đâu, nên mỗi người tự tưởng tượng một phiên bản khác nhau.
• Tranh luận về điều không ai biết. Khi câu trả lời nằm ở bộ phận khác hoặc cần thử kỹ thuật, bàn thêm trong phòng không làm nó rõ hơn.
• Mục quá lớn. Một mục cần nhiều sprint mới xong thì khó ước lượng, và team dễ bàn vòng quanh.
• PO trình bày như báo cáo. Nếu chỉ PO nói, team không kịp đặt câu hỏi, và những rủi ro kỹ thuật chỉ lộ ra khi sprint đã bắt đầu.

Gốc chung là buổi họp đang làm thay phần việc lẽ ra nên xong trước buổi họp. Cách sửa không phải là họp lâu hơn, mà là chuyển bớt việc ra ngoài phòng họp.

Cách chạy refinement gọn: bốn bước

Dưới đây là một cách làm bạn có thể áp dụng cho buổi refinement tiếp theo. Các mốc thời gian là gợi ý của bài viết, team nên điều chỉnh theo độ dài sprint và nhịp làm việc của mình.

Bước 1 và bước 2 làm ngắn bước 3. Khi team đã đọc trước và đặt câu hỏi, PO có thời gian tìm câu trả lời thay vì đoán tại chỗ. Trong buổi họp, team chỉ cần bàn những chỗ thật sự cần nhiều người cùng nghĩ.

Bước 4 là chỗ nhiều buổi refinement bỏ quên. Mỗi mục rời khỏi buổi họp nên ở một trong bốn trạng thái: đã đủ rõ để mang vào sprint planning, đã được tách thành mục nhỏ hơn, có một câu hỏi cụ thể kèm người phụ trách và hạn trả lời, hoặc được đưa xuống sâu hơn trong backlog vì chưa cần trong 1 đến 2 sprint tới. Không mục nào nên rời phòng với trạng thái “bàn tiếp sau”.

PO cần chuẩn bị gì trước buổi refinement?

Phần chuẩn bị không cần dài. Mục tiêu là để team bước vào buổi họp đã biết sẽ bàn gì và vì sao.

• Sắp thứ tự phần đầu backlog. Biết mục nào quan trọng nhất và lý do. Nếu bạn chưa có cách sắp thứ tự rõ ràng, bài về ưu tiên backlog có các bước cụ thể.
• Viết vấn đề trước giải pháp. Mỗi mục nói được trong một câu: giúp ai, thay đổi điều gì. Đính kèm bằng chứng nếu có, như số lượt khách phản ánh hay ảnh chụp lỗi.
• Có bản nháp acceptance criteria (AC, tiêu chí chấp nhận). Bản nháp chưa cần hoàn hảo. Nó cho team một điểm để góp ý thay vì bắt đầu từ trang trắng.
• Ghi sẵn câu hỏi bạn chưa trả lời được. Nói rõ “mình chưa biết điều này” trong pre-read tốt hơn để team tự phát hiện giữa buổi.
• Hỏi trước người ngoài team nếu cần. Nếu một mục phụ thuộc quy tắc của marketing hay kế toán, hỏi họ trước buổi họp, hoặc mời họ vào đúng phần đó.
• Xem lại câu hỏi còn mở từ buổi trước. Câu nào đã có câu trả lời thì cập nhật vào ticket.

Một điều không nằm trong danh sách: PO không cần tự ước lượng trước hay đề xuất mỗi mục mất bao nhiêu ngày. Ước lượng là việc của Developers.

• Ưu tiên backlog khi việc nào cũng gấp

Nên refine bao nhiêu mục là đủ?

Gợi ý của bài viết: tập trung vào các mục team có thể làm trong 1 đến 2 sprint tới. Mountain Goat Software mô tả buổi refinement là để đảm bảo backlog sẵn sàng cho sprint tiếp theo. Thêm một sprint nữa cho bạn khoảng đệm khi kế hoạch thay đổi.

Những mục xa hơn vẫn có thể nằm trong backlog với một dòng mô tả ngắn. Làm chi tiết quá sớm dễ thành lãng phí: đến lúc làm thật, nhu cầu có thể đã đổi, và phần chi tiết đó phải viết lại.

Cũng đừng đòi mọi mục phải rõ hoàn toàn. Mountain Goat Software nhấn mạnh rằng các câu hỏi không cần được giải quyết trọn vẹn trong buổi refinement, chỉ cần đủ để team tự tin bàn tiếp ở sprint planning. Chi tiết nhỏ có thể làm rõ trong sprint. Phần chuẩn bị cho sprint planning được nói kỹ hơn trong bài riêng.

• Sprint planning: PO chuẩn bị gì

Mục quá lớn thì tách thế nào?

Scrum Guide xem các mục team có thể làm xong trong một sprint là sẵn sàng để chọn. Vì vậy, khi Developers nói một mục không vừa một sprint, đó là tín hiệu cần tách, không phải lý do để bàn tiếp về cách làm.

Ba hướng tách dễ dùng trong buổi refinement:

• Theo đường đi của người dùng. “Làm lại giỏ hàng” có thể tách thành: sửa số lượng ngay trong giỏ, lưu giỏ khi khách đăng xuất, gợi ý món thêm. Mỗi phần đều có ích cho khách.
• Theo dữ liệu. Làm cho một phần dữ liệu trước, ví dụ chỉ đơn trong ba mươi ngày gần nhất.
• Theo quy tắc. Tạm bỏ một quy tắc phức tạp, thêm lại ở mục sau.

Mỗi phần sau khi tách vẫn phải mang lại điều có ích cho người dùng. Tránh tách theo lớp kỹ thuật như “làm phần giao diện” và “làm phần backend”, vì từng phần riêng lẻ không ai dùng được. Cách tách chi tiết hơn có trong bài về user story.

Nếu cả phòng chưa nghĩ ra cách tách trong vài phút, đừng ép. Giao một người, có thể là PO cùng một dev, đề xuất cách tách trước buổi sau.

• Cách viết user story cho người mới

Mục không ai hiểu thì xử lý ra sao?

Đây là chỗ buổi refinement dễ mất nhiều thời gian. Nguyên tắc của bài viết: khi không ai trong phòng có câu trả lời, đừng tranh luận, hãy chọn một hành động. Một cách đơn giản là đặt giới hạn thời gian cho mỗi mục, ví dụ năm đến mười phút, do team tự chọn. Hết giờ mà chưa rõ hơn thì chuyển sang chọn hành động.

Khi ghi hành động, viết đủ ba ý: câu hỏi cụ thể là gì, ai đi tìm câu trả lời, và hạn khi nào. “Tìm hiểu thêm về tích điểm” chưa phải là một hành động. “Hỏi marketing: mười điểm đổi được gì, điểm có hết hạn không, đơn đã hủy có được tính điểm không. PO phụ trách, có câu trả lời trước buổi refinement tới” mới là một hành động.

Pre-read không đồng bộ giúp gì?

Pre-read là ghi chú PO gửi trước buổi họp, để team đọc và góp ý không đồng bộ, tức mỗi người làm vào lúc tiện nhất thay vì cùng lúc. Nó giúp ở ba điểm:

• Câu hỏi đến sớm. PO có thời gian tìm câu trả lời, thay vì hứa “để mình hỏi lại” giữa buổi.
• Người ít nói cũng góp ý được. Có người nghĩ chậm và chắc, hoặc ngại lên tiếng trong cuộc họp đông người. Một bình luận trong ticket cho họ cơ hội đó.
• Một số mục không cần họp. Nếu một lỗi nhỏ đã rõ và Developers đã ước lượng qua bình luận, buổi họp có thể bỏ qua nó.

Pre-read chỉ có ích khi ngắn. Một trang với danh sách mục, đường dẫn tới từng ticket và điều bạn cần từ team là đủ. Mẫu ở phần dưới có thể dùng ngay.

Ví dụ: cùng một backlog, buổi refinement sau khi sửa

Quay lại ứng dụng đặt trà ở đầu bài. Đây là ví dụ minh họa cho buổi refinement kế tiếp, khi PO áp dụng bốn bước ở trên.

Hai ngày trước buổi họp, PO chọn sáu mục cho hai sprint tới và gửi pre-read: làm lại giỏ hàng, tích điểm thành viên, sửa lỗi hiển thị sai phí giao hàng, đặt lại đơn cũ, thông báo khi đơn đổi trạng thái, thanh toán bằng ví điện tử. Team để câu hỏi trong ticket. Câu hỏi về tích điểm đã xuất hiện từ trước buổi họp, nhưng marketing chưa kịp trả lời.

Cả đoạn trao đổi mất vài phút. Team không tranh luận về quy tắc mà không ai trong phòng quyết được. Câu hỏi được viết rõ, có người phụ trách và có hạn.

Năm mục được ước lượng gồm hai mục tách từ giỏ hàng, lỗi phí giao hàng, đặt lại đơn cũ và thông báo trạng thái đơn. Buổi họp không cần dài hơn. Phần việc đã được chuyển ra trước và sau buổi họp.

Mẫu pre-read và checklist cho từng mục

Hai mẫu dưới đây dùng cùng nhau. Pre-read gửi cho cả team trước buổi họp. Checklist dùng cho từng mục, trong lúc chuẩn bị và trong buổi họp. Hãy copy và sửa theo cách team bạn đang làm.

REFINEMENT [ngày]: PRE-READ

Mục tiêu buổi: làm rõ các mục cho [sprint tới / hai sprint tới], hướng tới [mục tiêu sản phẩm gần nhất].
Thời lượng dự kiến: [số phút]

Nhờ mọi người trước buổi họp:
- Đọc các mục dưới đây
- Để câu hỏi ngay trong ticket trước [giờ, ngày]

Các mục sẽ bàn (theo thứ tự ưu tiên):
1. [Tên mục] · [đường dẫn] · Cần từ team: [ước lượng / góp ý cách tách / câu hỏi kỹ thuật]
2. [Tên mục] · [đường dẫn] · Cần từ team: [...]
3. [Tên mục] · [đường dẫn] · Cần từ team: [...]

Câu hỏi còn mở từ buổi trước:
- [Câu hỏi] · Người phụ trách: [tên] · Trạng thái: [đã có câu trả lời / chưa có]

Không bàn trong buổi này: [các mục ngoài phạm vi]

Sau buổi họp: PO cập nhật ticket và gửi danh sách hành động trước [ngày].

Mục: [tên và đường dẫn]

[ ] Nói được trong một câu: giúp ai, thay đổi điều gì
[ ] Có AC đủ để kiểm thử, hoặc bản nháp để team góp ý
[ ] Developers thấy làm xong được trong một sprint
    (nếu chưa: tách theo đường đi người dùng, dữ liệu hoặc quy tắc)
[ ] Developers đã ước lượng, hoặc đã ghi rõ cần biết gì trước khi ước lượng
[ ] Phụ thuộc ngoài team đã có người theo dõi

Câu hỏi còn mở:
- Câu hỏi: [...] · Người phụ trách: [...] · Hạn: [...]

Kết quả của mục này:
[ ] Đủ rõ để mang vào sprint planning
[ ] Đã tách thành: [tên các mục mới]
[ ] Chờ câu trả lời (xem câu hỏi còn mở)
[ ] Đưa xuống sâu hơn trong backlog

Checklist này là câu hỏi gợi ý khi refine, không phải cổng duyệt. Một ô chưa đánh dấu dẫn tới một việc cần làm, không phải lý do để loại mục. Nếu team muốn có một checklist sẵn sàng chung, bài về Definition of Ready và Definition of Done giải thích cách giữ nó nhẹ.

• Definition of Ready và Definition of Done

Dấu hiệu refinement đang tốn thời gian và cách sửa

Bảng dưới giúp bạn nhận ra vấn đề từ dấu hiệu thấy được. Nguyên nhân chỉ là khả năng, hãy hỏi team trong buổi retrospective để biết đúng nguyên nhân ở team mình.

Ngoài bảng trên, có bốn lỗi PO mới dễ mắc:

• Tự ước lượng thay team. Đưa ra con số trước để “cho nhanh” dễ khiến team neo theo số đó. Hãy để Developers ước lượng, bạn giải thích giá trị và phạm vi.
• Biến refinement thành buổi duyệt. Nếu mỗi mục phải “qua cửa” đủ mọi điều kiện, team sẽ chậm hơn. Mục tiêu là đủ rõ để bắt đầu, không phải rõ tuyệt đối.
• Bỏ refinement khi bận. Sprint bận là lúc dễ bỏ qua, và sprint planning tiếp theo sẽ trả giá. Nếu không họp được, ít nhất gửi pre-read và xin ước lượng qua bình luận.
• Không gửi lại kết quả sau buổi họp. Hành động không được ghi lại sẽ bị quên. Gửi danh sách hành động ngay sau buổi, kèm người phụ trách và hạn.

Tóm tắt

• Theo Scrum Guide 2020, refinement là hoạt động liên tục chia nhỏ và làm rõ mục backlog, thêm mô tả, thứ tự và ước lượng. Nó không phải là một sự kiện Scrum, và Scrum Guide không quy định thời lượng.
• Developers là người ước lượng. PO chịu trách nhiệm về backlog: viết mục, sắp thứ tự, giữ backlog dễ hiểu.
• Bốn bước cho buổi refinement gọn: chọn phạm vi 1 đến 2 sprint tới, gửi pre-read trước, làm rõ và tách trong buổi, chốt hành động cho mục chưa rõ.
• Mục quá lớn thì tách theo đường đi người dùng, dữ liệu hoặc quy tắc, mỗi phần vẫn có ích cho người dùng.
• Mục không ai hiểu thì đừng tranh luận: chọn một hành động, ghi câu hỏi, người phụ trách và hạn.

Mình đang soạn thêm các tình huống PO khác theo cùng khung này, kèm mẫu dùng ngay. Nếu bạn muốn nhận khi có bài mới, đăng ký bản tin bên dưới.

• Nhận bài mới qua email

Câu hỏi thường gặp

Backlog refinement có phải là một sự kiện trong Scrum không?

Không. Scrum Guide 2020 gọi refinement là một hoạt động diễn ra liên tục, không nằm trong năm sự kiện của Scrum. Team tự chọn cách làm: một buổi định kỳ, vài cuộc trao đổi ngắn, hoặc đọc trước và góp ý không đồng bộ.

Buổi backlog refinement nên kéo dài bao lâu?

Scrum Guide 2020 không quy định thời lượng cho refinement. Mountain Goat Software đưa ra một quy tắc kinh nghiệm là khoảng 5 đến 10 phần trăm công sức mỗi sprint dành cho refinement, và khuyên giữ buổi họp ngắn nhất có thể.

Ai ước lượng các mục backlog khi refinement?

Developers, tức những người sẽ trực tiếp làm việc đó. PO giải thích giá trị, trả lời câu hỏi và giúp team thấy các đánh đổi, nhưng không áp số ước lượng.

Nguồn kiểm tra

• Scrum Guide 2020: Product Backlog
• Scrum.org: What is Product Backlog Refinement?
• Mountain Goat Software: Product Backlog Refinement

Bài liên quan

• User story là gì? Cách viết cho người mới, kèm mẫu và ví dụ: Mẫu “Là…, tôi muốn…, để…” là phần dễ. Bài này chỉ cách chọn đúng người dùng, đúng vấn đề và cắt story đủ nhỏ, kèm ví dụ trước và sau.
• Acceptance criteria là gì? Cách viết để QA kiểm thử được: Cách viết acceptance criteria rõ đến mức QA đọc xong là biết phải thử gì, kèm ví dụ mã giảm giá và mẫu dùng ngay.
• Ưu tiên backlog khi việc nào cũng gấp: chọn cách nào?: Cách chọn giữa value vs effort, MoSCoW và RICE, tách hạn chót thật khỏi cảm giác gấp, và gửi stakeholder một ghi chú ưu tiên một trang.
• Cách nói không với sếp và stakeholder mà không mất lòng: Ba cách nói không thay cho một chữ “không”, cách xử lý khi người yêu cầu là sếp hoặc CEO, lúc nào nên escalate, kèm hội thoại mẫu và tin nhắn theo từng cấp.