Yêu cầu thay đổi giữa sprint: PO nên xử lý thế nào?

Đang giữa sprint thì có yêu cầu mới

Đây là tình huống minh họa. Bạn là PO của một hiệu sách online. Sprint hai tuần đang đi được nửa đường, Sprint Goal là: “Khách thanh toán được bằng ví điện tử ngay trong app.” Team đang tích hợp cổng thanh toán, kiểm thử đang viết kịch bản, mọi thứ theo đúng kế hoạch.

Rồi trưởng nhóm marketing nhắn: “Em thêm giúp chị đồng hồ đếm ngược và tự áp mã giảm giá cho đợt sale cuối tháng nhé. Chiến dịch chạy trước khi sprint của em kết thúc đấy.” Ngay sau đó, một kỹ sư báo trong nhóm chat: “Trang chi tiết sách đang lỗi ảnh trên một số điện thoại, khách phàn nàn.”

Hai yêu cầu, cùng một buổi, cả hai đều nghe gấp. Bạn không muốn làm marketing thất vọng, cũng không muốn team bỏ dở việc thanh toán. Bài này đi qua cách quyết định: thay đổi nào nên vào sprint, thay đổi nào nên chờ, nói với người yêu cầu thế nào và nói với team thế nào.

Vì sao thay đổi giữa sprint lại khó với PO mới?

Yêu cầu thay đổi giữa sprint khó không phải vì thiếu quy trình. Nó khó vì bạn đứng giữa hai nhóm người đều có lý.

• Người yêu cầu có lý do thật: một chiến dịch, một khách hàng, một con số sếp cần. Từ phía họ, “thêm một chút” trông rất nhỏ.
• Team cũng có lý do thật: họ đã cam kết một mục tiêu trong sprint planning, đang làm dở nhiều việc, và mỗi lần đổi hướng là mất thời gian quay lại nhịp làm.
• Bạn chưa có gì để so. Khi mới vào vai, rất khó biết yêu cầu nào đáng làm đổi kế hoạch và yêu cầu nào chỉ là gấp do cảm giác.
• Bạn có thể hiểu nhầm quyền của mình. Nhiều người mới nghĩ PO được tự đẩy việc vào sprint. Thực ra Scrum Guide 2020 gọi Sprint Backlog là kế hoạch “by and for the Developers”. Developers ở đây là những người làm ra sản phẩm trong team, không chỉ kỹ sư. PO thương lượng phạm vi với Developers, không ra lệnh thêm việc.

Ở chiều ngược lại cũng có một hiểu nhầm: sprint đã chốt thì không được đụng vào. Nếu bạn từ chối mọi thay đổi, team có thể làm đúng kế hoạch nhưng giao ra thứ không còn hợp với tình hình. Cách làm hợp lý nằm giữa hai cực đó, và nó xoay quanh một câu hỏi: Sprint Goal có bị ảnh hưởng không?

Scrum Guide nói gì về thay đổi trong sprint?

Scrum Guide 2020 có vài câu ngắn đáng nhớ trong phần nói về sprint. Tóm lại theo ý:

• Không có thay đổi nào được làm nếu nó đe dọa Sprint Goal.
• Chất lượng không được giảm.
• Phạm vi có thể được làm rõ và thương lượng lại với Product Owner khi team biết thêm.
• Sprint có thể bị hủy nếu Sprint Goal trở nên lỗi thời, và chỉ Product Owner có quyền hủy.

Điều này có nghĩa là Sprint Goal mới là thứ cần giữ, còn danh sách việc cụ thể để đạt goal thì được phép thay đổi. Bài viết của Scrum.org về hiểu lầm “Sprint Backlog không được thay đổi” cũng nói theo hướng này: Sprint Backlog linh hoạt, miễn là thay đổi không làm team mất tập trung khỏi Sprint Goal.

Mountain Goat Software tách thêm một ý hữu ích: thêm một đầu việc nhỏ để hoàn thành story đã có là cập nhật kế hoạch, còn thêm một item mới từ product backlog vào sprint là chuyện khác. Với chức năng mới, chỗ của nó thường là product backlog, và nếu nó ảnh hưởng tới sprint thì PO và Developers nên bàn rõ đánh đổi.

Phần còn lại của bài là cách làm của bài viết này, dựa trên ba ý trên, không phải quy định của Scrum Guide.

Xử lý yêu cầu thay đổi giữa sprint: bốn bước

Trước hết, tách riêng một loại: câu hỏi làm rõ story đang làm, ví dụ kỹ sư hỏi một nút nằm ở đâu hay một trường hợp lỗi xử lý thế nào. Đó là làm rõ phạm vi, không phải yêu cầu mới. Bạn trả lời luôn, không cần đi qua các bước dưới đây.

Với yêu cầu mới thật sự, một cách làm đơn giản là đi qua cùng một đường cho mọi trường hợp, kể cả yêu cầu nhỏ. Không cần họp. Nhiều khi chỉ là vài tin nhắn và năm phút với team.

Bước 1 giống với cách xử lý một yêu cầu tính năng thông thường: tìm vấn đề phía sau giải pháp được đề xuất. Câu hỏi quan trọng nhất ở đây là “Nếu việc này lên vào sprint sau thì chuyện gì xảy ra?”. Câu trả lời cho bạn biết hạn chót là thật hay chỉ là mong muốn.

Bước 2 là chỗ người mới dễ bỏ qua. Bạn không tự ước lượng thay team. Hỏi một hoặc hai người trong team: việc này cỡ bao lớn, có đụng vào phần đang làm cho Sprint Goal không, có rủi ro gì cho chất lượng không. Năm phút hỏi đúng người giúp bạn tránh hứa một điều team không làm được.

Để chọn cách xử lý ở bước 3, có thể dùng bộ lọc dưới đây. Trả lời “có” thì đi tiếp, trả lời “không” thì làm việc ghi bên cạnh. Câu đầu tiên dành cho sự cố nặng. Cách xử lý ở nhánh đó là quan điểm của bài viết, Scrum Guide không quy định riêng về sự cố.

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

Đổi chỗ hay thêm vào: khác nhau thế nào?

Thêm vào nghĩa là sprint giữ nguyên mọi việc cũ và nhận thêm việc mới. Đổi chỗ nghĩa là việc mới vào thì một phần việc có kích thước tương đương phải ra.

Thêm vào nghe dễ chịu hơn với người yêu cầu, nhưng nó giả định team còn thời gian thừa. Khi sprint planning đã chọn đủ việc theo sức của team, thêm vào dễ dẫn tới việc một thứ khác sẽ không xong, chỉ là chưa ai nói ra đó là thứ gì. Đổi chỗ buộc mọi người nói ra điều đó ngay từ đầu.

Hủy sprint là lựa chọn nặng, nên để dành cho lúc Sprint Goal thật sự lỗi thời, ví dụ công ty quyết định bỏ hẳn tính năng mà sprint đang xây. Một yêu cầu gấp nhưng nhỏ không phải lý do để hủy sprint.

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

Các loại thay đổi thường gặp và cách phản hồi

Không phải thay đổi nào cũng giống nhau. Bảng dưới gom các loại thay đổi PO có thể gặp giữa sprint, kèm cách phản hồi gợi ý. Đây là gợi ý của bài viết, team bạn có thể có quy ước riêng.

Dòng “Làm rõ story đang làm” đáng nhớ nhất. Nhiều câu hỏi giữa sprint chỉ là làm rõ phạm vi của story đã có. Đó là việc bình thường và Scrum Guide cho phép rõ ràng. Đừng coi mỗi câu hỏi của người trong team là một thay đổi cần xử lý như yêu cầu mới.

• Acceptance criteria: viết sao cho kiểm thử được

Ví dụ: đợt sale cuối tháng giữa sprint thanh toán

Quay lại hiệu sách online ở đầu bài. Đây là cuộc trao đổi minh họa, đi theo đúng bốn bước ở trên.

Bước 2, PO hỏi team. Kỹ sư cho biết đồng hồ đếm ngược chỉ nằm ở trang chủ, khoảng một ngày làm, không đụng phần thanh toán. Còn tự áp mã thì phải sửa luồng giỏ hàng và thanh toán, đúng chỗ team đang tích hợp ví điện tử. Làm cùng lúc sẽ tăng rủi ro cho Sprint Goal.

Bước 3, PO đi qua bộ lọc với từng phần. Cả hai phần đều chờ được để hỏi rõ, và vấn đề đã rõ.

• Đồng hồ đếm ngược có hạn thật trong sprint. Team xác nhận làm được mà Sprint Goal vẫn đạt. Team đồng ý đưa story “trang sách mới phát hành”, có kích thước tương đương và không thuộc Sprint Goal, về product backlog. Kết quả: đổi chỗ.
• Tự áp mã dừng ở câu thứ ba. Khách vẫn nhập mã tay được, nên không có hạn thật buộc phải làm trong sprint này. Nó vào product backlog cho sprint planning tới, kèm cách tạm là banner ghi rõ mã. Dù có hạn thật, nó cũng sẽ dừng ở câu thứ tư, vì đụng vào phần thanh toán đang làm cho Sprint Goal.

Bước 4, PO báo lại marketing: đồng hồ đếm ngược có trước ngày chiến dịch, tự áp mã được xem ở sprint planning tới, trong lúc chờ thì banner ghi rõ mã để khách dễ nhập. PO cũng báo người đã đề xuất trang sách mới phát hành rằng việc của họ lùi một sprint, kèm lý do.

Còn lỗi ảnh trên điện thoại? Kỹ sư kiểm tra và thấy lỗi chỉ xảy ra trên một dòng máy cũ, ảnh vẫn tải được sau khi kéo trang. Lỗi chờ được, không có hạn thật trong sprint, nên vào product backlog với mức ưu tiên cao cho sprint sau. Nếu lỗi làm khách không đặt được hàng, nó sẽ rẽ ngay ở câu đầu tiên: cả team cùng quyết xử lý ngay, và nếu việc sửa đe dọa Sprint Goal thì cùng team thương lượng lại phạm vi.

Nói với người yêu cầu và với team thế nào?

Với người yêu cầu, điều họ cần nghe nhất không phải là “có” hay “không”, mà là cái giá và mốc thời gian. Một câu trả lời tốt có thể gồm bốn phần: nhắc lại vấn đề theo lời của họ, nói phần nào làm được trong sprint này, nói việc gì sẽ bị lùi để đổi lấy nó, và hẹn mốc cho phần còn lại.

Khi người yêu cầu là sếp hoặc người có quyền lớn hơn bạn, hãy hỏi team trước, rồi chỉ đưa ra những phương án team đã xác nhận làm được mà Sprint Goal vẫn đạt. Để sếp chọn giữa các phương án đó, thay vì tự từ chối. Ví dụ: “Team làm được đồng hồ đếm ngược trong sprint này nếu lùi trang sách mới phát hành sang sprint sau. Tự áp mã đụng vào phần thanh toán đang làm, nên team đề xuất xem ở sprint sau. Anh muốn đổi chỗ như vậy, hay giữ nguyên sprint và làm đồng hồ ở sprint sau, chấp nhận đồng hồ không kịp ngày đầu chiến dịch?”

Với team, đừng mang tới một quyết định đã chốt. Mang tới vấn đề, hạn chót thật và câu hỏi: “Có cách nào làm phần gấp nhất mà Sprint Goal vẫn đạt không?”. Người trong team có thể thấy những cách thu nhỏ mà PO không nghĩ tới. Sau khi đổi chỗ, cập nhật bảng sprint ngay để không ai làm tiếp việc đã được đưa ra.

Nếu một thay đổi phải vào sprint, hãy nói rõ với team ai yêu cầu và vì sao. Team dễ chấp nhận đổi kế hoạch hơn khi hiểu lý do, và khó chấp nhận hơn khi việc mới cứ xuất hiện trên bảng mà không ai giải thích.

• Nói không với stakeholder mà không mất lòng

Thay đổi giữa sprint thường xuyên tốn gì?

Một thay đổi đơn lẻ có thể rất hợp lý. Vấn đề xuất hiện khi thay đổi trở thành thói quen. Cái giá không chỉ nằm ở việc được thêm vào, mà còn ở những thứ khó thấy hơn:

• Việc làm dở. Mỗi lần đổi hướng, một phần việc đang làm bị bỏ lại. Cuối sprint có thể còn nhiều việc làm được một nửa và không việc nào giao được.
• Thời gian quay lại nhịp làm. Người trong team phải dừng việc đang nghĩ, đọc yêu cầu mới, rồi sau đó quay lại việc cũ.
• Niềm tin vào kế hoạch. Nếu sprint planning nào cũng bị đổi giữa chừng, stakeholder sẽ thôi tin vào kế hoạch, còn team sẽ thôi cố cam kết.
• Chất lượng. Khi bị ép đưa việc mới vào, phần dễ bị cắt là kiểm thử và xử lý lỗi, đúng thứ Scrum Guide nói không được giảm.

Cách đo đơn giản là change log. Mỗi thay đổi giữa sprint ghi một dòng. Cuối sprint, mang change log tới buổi retrospective và hỏi: thay đổi nào thật sự không thể chờ, thay đổi nào lẽ ra đã thấy trước ở sprint planning. Nếu cùng một bộ phận liên tục gửi yêu cầu gấp, có thể họ cần được mời vào backlog refinement hoặc sprint planning sớm hơn.

Nếu thay đổi gấp nhiều tới mức sprint nào cũng bị phá, đó là tín hiệu để nói chuyện với team về độ dài sprint hoặc về cách nhận việc gấp. Bài viết này không đưa ra ngưỡng cụ thể, vì nó phụ thuộc vào từng team. Change log giúp bạn có số liệu thật của chính team mình để bàn.

Mẫu tin nhắn và change log dùng ngay

Hai mẫu dưới đây dùng cho bước 4. Bạn copy rồi sửa lại theo cách xưng hô trong team.

Dạ em đã trao đổi với team về yêu cầu [tên yêu cầu].
Em hiểu vấn đề là [nhắc lại vấn đề theo lời anh/chị].
Trong sprint này, team làm được [phần làm được], xong trước [ngày].
Để có chỗ cho việc này, team đưa [việc bị lùi] sang sprint sau.
Phần [phần chưa làm] sẽ được xem ở sprint planning ngày [ngày].
Trong lúc chờ, anh/chị có thể [cách tạm].
Nếu [điều kiện thay đổi] thì anh/chị báo em để mình xem lại sớm hơn nhé.

Sprint: [tên hoặc số sprint]
Sprint Goal: [mục tiêu]

Ngày: [ngày]
Người yêu cầu: [tên, bộ phận]
Yêu cầu: [mô tả một câu]
Lý do không chờ được: [sự cố / hạn pháp lý / cam kết có ngày / khác]
Ảnh hưởng tới Sprint Goal: [không / có, ghi rõ]
Quyết định: [chờ sprint sau / đổi chỗ / xử lý sự cố ngay / hủy sprint]
Việc được đưa ra khỏi sprint: [tên việc hoặc không có]
Người quyết: [PO và team]
Đã báo người yêu cầu: [có / chưa, ngày]

Change log không cần công cụ riêng. Một trang ghi chú chung hoặc một cột bình luận trên bảng sprint là đủ, miễn là cả team đọc được và nó được mang tới retrospective.

Lỗi thường gặp khi xử lý thay đổi giữa sprint

• Nhận ngay rồi mới hỏi team. Bạn hứa một mốc mà team chưa biết, sau đó phải quay lại xin lỗi người yêu cầu hoặc ép team làm thêm giờ.
• Thêm vào mà không đưa gì ra. Sprint đã đủ việc, thêm vào chỉ khiến một việc khác lặng lẽ không xong vào cuối sprint.
• Tự chọn việc bị đưa ra. Người trong team biết việc nào đang làm dở, việc nào dễ dừng. Hãy chọn cùng team.
• Coi mọi câu hỏi làm rõ là thay đổi. Làm rõ phạm vi story đang làm là việc bình thường trong sprint, cứ trả lời nhanh.
• Từ chối mọi thay đổi để giữ kế hoạch. Sprint Goal mới là thứ cần giữ. Danh sách việc để đạt goal có thể đổi khi team biết thêm.
• Hủy sprint vì một yêu cầu gấp nhưng nhỏ. Hủy sprint dành cho lúc goal đã lỗi thời, không phải cho một việc có thể đổi chỗ.
• Không báo lại người có việc bị lùi. Người có việc bị đưa ra khỏi sprint cũng cần biết lý do và mốc mới.

Tóm tắt

• Trừ sự cố cần xử lý ngay, câu hỏi then chốt với mọi thay đổi giữa sprint là: nó có đe dọa Sprint Goal không. Scrum Guide 2020 không cho phép thay đổi làm hỏng goal, nhưng cho phép làm rõ và thương lượng lại phạm vi với PO.
• Câu hỏi làm rõ story đang làm thì trả lời luôn. Yêu cầu mới thì đi qua bốn bước: ghi nhận và hỏi rõ, đo tác động cùng team, chọn cách xử lý, báo lại và ghi log.
• Không có hạn thật thì đưa vào product backlog cho sprint sau. Gấp thật và không đụng goal thì đổi chỗ, không thêm vào.
• Chỉ PO có quyền hủy sprint, và chỉ nên dùng khi Sprint Goal đã lỗi thời.
• Ghi change log mỗi sprint và mang tới retrospective để thấy cái giá của thay đổi thường xuyê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

Có được thay đổi phạm vi của sprint đang chạy không?

Có, phạm vi có thể được làm rõ và thương lượng lại với PO khi team biết thêm. Nhưng Scrum Guide 2020 không cho phép thay đổi nào đe dọa Sprint Goal.

Ai có quyền hủy một sprint?

Theo Scrum Guide 2020, chỉ Product Owner có quyền hủy sprint, và trường hợp Scrum Guide nêu là khi Sprint Goal trở nên lỗi thời, ví dụ hướng kinh doanh đổi khiến mục tiêu không còn ý nghĩa.

Khi sếp yêu cầu gấp giữa sprint thì PO nên trả lời gì?

Hỏi team trước, rồi chỉ đưa ra những phương án team đã xác nhận làm được mà Sprint Goal vẫn đạt, kèm việc nào sẽ phải lùi. Để sếp chọn giữa đổi chỗ như vậy hoặc làm ở sprint sau.

Nguồn kiểm tra

• Scrum Guide 2020: The Sprint
• Scrum.org: Myth 2, The Sprint Backlog can't change during the Sprint
• Mountain Goat Software: Sprint Backlog

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.