Lập kế hoạch sprint theo định hướng cam kết

Một cuộc họp lập kế hoạch sprint theo định hướng cam kết bao gồm Product Owner, Scrum master và toàn bộ thành viên của nhóm phát triển. Product Owner mang tới những backlog item có độ ưu tiên cao nhất tới buổi họp và giải thích chúng cho nhóm, thường bắt đầu với một cái nhìn tổng quan về nhóm các item độ ưu tiên cao này.

Chọn một item

Sau đó, nhóm phát triển chọn item đầu tiên để đưa vào sprint. Điều này sẽ gần như luôn là item có độ ưu tiên cao nhất đối với Product Owner, nhưng cũng có khả năng item có độ ưu tiên cao nhất tồn tại quá nhiều vẫn đề mở. Lý tưởng nhất là nhóm phát triển vẫn có thể đưa item đó vào sprint và giải quyết các vấn đề đủ sớm để hoàn thành trong sprint. Tuy nhiên, nó có thể có quá nhiều các vấn đề mà các vấn đề quá quan trọng hoặc giải quyết các vấn đề cần quá nhiều thời gian (ví dụ : cần phải tổ chức một cuộc họp với 25 đại diện người dùng) dẫn tới item có độ ưu tiên cao nhất của Product Owner được bỏ qua.

Nhiệm vụ và giờ (task and hours)

Sau khi đã lựa chọn một item có độ ưu tiên cao, thành viên của nhóm thảo luận và các công việc liên quan và xác định các nhiệm vụ cần làm để hoàn thành product backlog item. Hoặc đồng thời với việc xác định các nhiệm vụ cần làm, hoặc ngay sau khi xác định xong, các thành viên trong nhóm phát triển dự tính số giờ cần thiết để hoàn thành mỗi nhiệm vụ. Không nên đòi hỏi hoặc mong đợi một nhóm nghĩ rằng tất cả nhiệm vụ sẽ có thể hoàn thành trong sprint. Việc đó không chỉ là bất khả thi mà còn không cần thiết. Nhóm nên nghĩ vừa đủ về các nhiệm vụ mà họ cảm thấy đã nghĩ thông qua công việc. Tuy nhiên, điều quan trọng nhất là nhận ra rằng suy nghĩ thông qua công việc là mục tiêu đích thực của buổi họp này. Xác định các nhiệm vụ và thời gian thực hiện là thứ yếu.

Yêu cầu sự cam kết

Sau khi nhóm phát triển đã xác định nhiệm vự và ước tính thời gian thực hiện cho product backlog item đã chọn, thành viên trong nhóm sẽ tự hỏi " chúng ta có thể cam kết thực hiện điều đó?". Điều rất quan trọng là các thành viên của nhóm tự hỏi bản thân họ hơn là có một Scrum Master hỏi " Anh có thể cam kết thực hiện điều đó". Khi mà thành viên của nhóm hỏi "Chúng ta có thể cam kết?", họ cam kết với nhau hơn là cam kết với Scrum Master. Tôi không biết đối với bạn thì sao, nhưng đối với kinh nghiệm Scrum của tôi, thì sự cam kết với ông chủ, người thường hỏi nếu tôi có thể hoàn thành công việc nào đó, thường dẫn tới ý nghĩ tốt nhất tôi nên trả lời là có. Scrum Master không phải là một ông chủ và không nên tạo ra cảm giá tương tự như thế giữa các thành viên trong nhóm,nhưng là người được gọi là "master" - và không nên tạo ra nguy cơ bị coi là ông chủ nhấn mạnh vào một cam kết. Hơn nữa, việc nhóm phát triển tự hỏi họ "chúng ta có thể cam kết" thì câu trả lời rõ ràng là "chúng ta có thể" hoặc "chúng ta không thể ". Khi một Scrum Master hỏi "bạn có thể cam kết" thì một vài thành viên có thể trả lời với "chúng ta có thể cam kết" nhưng những người khác sẽ trả lời là "tôi có thể cam kết". Scrum đòi hỏi cự cam kết của toàn bộ nhóm, nếu bạn gặp vấn đề và bị tụt lại, chúng tôi sẽ giúp đỡ, và tôi biết rằng bạn cũng sẽ làm điều đó cho tôi. Đây không phải là "đây là nhiệm vụ của tôi" và "đó là nhiệm vụ của bạn"

Lặp lại với nhiều userstories hơn

Nếu nhóm đã đống ý rằng có thể cam kết thực hiện một product backlog item, họ sẽ lựa chọn một item khác và tiếp tục lặp lại quy trình. Và nó sẽ tiếp tục với nhiệm vụ, thời gian hoàn thành và cam kết cho tới khi một ai đó nói rằng nhóm sẽ không thể cam kết hoàn thành product backlog item được lựa chọn. Nếu một thành viên nào đó trong nhóm không thể cam kết, cả nhóm sẽ thảo luận về tình hình xem là trong nhóm có thành viên nào đó có thể giúp - có lẽ là một DBA với kỹ năng JavaScript cơ bản có thể giúp đỡ một lập trình viên với kỹ năng Javascript siêu đẳng. Nêu không, có lẽ product backlog item đó sẽ được đưa trở lại product backlog và một item khác nhỏ hơn hoặc một item khác cần ít kỹ năng của người không có khả năng cam kết.

Không có vai trò của điểm hoặc vận tốc ?

Bạn có thể nhận thấy rằng trong quá trình từ trước tới giờ, đã không có vai trò cho điểm hoặc vận tốc. Mặc dù tôi vẫn khuyên rằng các product backlog item nên được dự toán nhanh chóng ở mức cao theo điểm story, cả điểm story và vận tốc đều không đóng vai trò gì trong việc lập kế hoạch sprint theo định hướng cam kết cho tới nay. Tuy nhiên, chúng đóng một vai trò quan trọng trong bước cuối cùng của buổi họp lập kế hoạch sprint.

Kiểm tra sự cam kết

Sau khi các thành viên trong nhóm đã điền thời gian có thể của mình trong sprint, Scrum Master có thể nhìn vào các product backlog item, tính tổng số điểm story point được gán cho mỗi item và chia sẻ kết quả đó cho nhóm phát triển. Các thành viên trong nhóm có thể so sánh tổng số điểm đó với vận tốc trung bình hoặc vận tốc gần đây. Giả sử một nhóm có vận tốc trung bình là 20 điểm tiến hành một buổi lập kế hoạch theo định hướng cam kết và lựa chọn khối lượng công việc 19 điểm. Họ có thể hoàn thành cam kết đó mà không cần biết về giá trị theo điểm của từng product backlog item. Khi Scum Master nói với họ rằng họ đã lựa chọn 19 điểm công việc và có vận tốc trung bình là 19 thì nhóm có thể cảm thấy họ rất tự tin rằng đã lựa chọn khối lượng công việc thích hợp cho sprint. Giả sử thay vào đó,Scrum Master nói với team rằng họ chỉ lựa chọn có 11 điểm công việc. Trong trường hợp đó nhóm có thể tự hỏi tại sao họ đã làm việc rất chăm chỉ trong việc lập kế hoạch print so với khi họ ước tính các item đó theo điểm story. Dù bằng cách nào, biết họ đã chọn 11 nhưng tốc độ trung bình là 20 có thể giúp nhóm biết rằng họ đã chọn lượng công việc thích hợp hoặc có thể lựa chọn thêm các product backlog item. Tương tự như vậy, nếu Scrum Master thông báo rằng team đã lựa chọn 30 điểm, cao hơn 10 điểm so với vận tốc trung bình, nhóm có thể tự hỏi có những gì họ đã quên chưa xem xét. "Tại sao", họ có thể thảo luận, " việc này có dễ dàng hơn sau khi lập kế hoạch sprint so với khi dự toán theo story point?" Vì vậy: các điểm story và vận tốc có thể không đóng vai trò trong phần chính của một buổi họp lập kế hoạch sprint theo định hướng cam kết nhưng chúng đóng vai trò rất quan trọng như một sự kiểm tra và xác nhận kế hoạch

Đó là sự cam kết, không phải là sự đảm bảo

Đó là một điều quan trọng rằng sự cam kết của nhóm sẽ không được coi là một sự đảm bảo. Như Clint Eastwood đã nói trong một bộ phim của mình, "Nếu bạn muốn có một sự đảm bảo, mua một cái lò nướng bánh". Cam kết của nhóm là làm tốt nhất khả năng của họ. Tôi muốn thấy họ thực hiện cam kết trong khoảng 80% thời gian. Đó nên là những gì họ coi là quan trọng và thực hiện trong phần lớn thời gian đó. Điều đó là cần thiết cho doanh nghiệp để đạt sự tin tưởng về những gì nhóm cam kết họ có thể thực hiện. Tuy nhiên, hoàn thành tất cả những gì họ nói dường như 100% không nên là mục tiêu. Một nhóm bị ép buộc hoàn thành tất cả, họ sẽ làm điều đó nhưng bằng cách giảm những gì họ cam kết.