Một cuộc họp lập kế hoạch nước rút nên kéo dài bao lâu?

Theo kinh nghiệm của bạn, cuộc họp Lập kế hoạch Sprint (Scrum) sẽ kéo dài bao lâu? 8 giờ? Hoặc nó nên ngắn hơn (cô đọng) và các cuộc thảo luận tiếp theo nên được lên kế hoạch như một phần của cuộc chạy nước rút? Sprint của chúng tôi dài 10 ngày.

Theo Hướng dẫn Scrum :

Cuộc họp Lập kế hoạch Sprint được sắp xếp thời gian đến tám giờ cho một tháng Sprint. Đối với Sprint ngắn hơn, sự kiện này ngắn hơn tương ứng. Ví dụ: Sprint hai tuần có các Cuộc họp Lập kế hoạch Sprint bốn giờ.

Điều đó thường làm việc cho tôi.

Miễn là nó cần kéo dài, không ít hơn và không nhiều hơn. Bất cứ điều gì khác không phải là Agile.

Nếu bạn có một nhóm gồm 2 - 3 nhà phát triển và đang thực hiện chạy nước rút 1 tuần thì bất cứ điều gì hơn một giờ có thể sẽ phản tác dụng.

Nếu bạn có một nhóm gồm 15 người và 2 tuần nước rút bạn đang tìm kiếm cả ngày, bất cứ điều gì ít hơn không đủ chi tiết.

Cần có kinh nghiệm để có được nó hầu như đúng, và đó là những gì nhìn lại được dành cho, nhóm quyết định những gì quá dài hoặc quá ngắn.

Đừng lo lắng về việc làm cho nó hoàn hảo hoặc bám sát vào những gì một số cuốn sách nói, hãy thử một cái gì đó và tinh chỉnh nó.

SCRUM là về việc tinh chỉnh quá trình trong các lần lặp cũng như về việc tinh chỉnh mã của bạn trong các lần lặp.

Đừng nhào nặn doanh nghiệp của bạn xung quanh quá trình. Quá trình hỗ trợ doanh nghiệp của bạn. Khoảnh khắc bạn đang thực hiện quy trình vì mục đích riêng của mình, đã đến lúc quá trình lấy rìu. Cuối cùng, không có cách "đúng". Các cuộc họp chỉ nên diễn ra miễn là bạn đang hoàn thành một cái gì đó trong đó. Nếu bạn mất 30 phút hoặc 4 giờ, miễn là nó hoạt động thì hãy đi với nó. Bỏ qua những gì một số cuốn sách / blog / huấn luyện viên nói với bạn và làm những gì phù hợp với bạn.

Mất chừng nào bạn cần để bạn chọn đủ để nhóm của bạn nghĩ rằng họ có thể đạt được một cách hợp lý trong giai đoạn nước rút. Nhưng bạn nên dành thời gian trong giai đoạn nước rút (trước đó) để hoàn thiện hồ sơ tồn đọng: ước tính và hoàn thiện câu chuyện.

Từ Scrum Primer ( PDF ):

Sản phẩm sàng lọc tồn đọng

Một trong những hướng dẫn ít được biết đến nhưng có giá trị trong Scrum là năm hoặc mười phần trăm của mỗi Sprint phải được Nhóm dành riêng để tinh chỉnh (hoặc chải chuốt một)) Product Backlog. Điều này bao gồm phân tích yêu cầu chi tiết, chia các mục lớn thành các mục nhỏ hơn, ước tính các mục mới và ước tính lại các mục hiện có. Scrum im lặng về cách thức thực hiện công việc này, nhưng một kỹ thuật được sử dụng thường xuyên là một hội thảo tập trung gần cuối Sprint, để Nhóm và Chủ sở hữu sản phẩm có thể cống hiến cho công việc này mà không bị gián đoạn. Đối với một Sprint hai tuần, năm phần trăm thời lượng ngụ ý rằng mỗi Sprint có một hội thảo sàng lọc sản phẩm tồn đọng nửa ngày. Hoạt động sàng lọc này không dành cho các mục được chọn cho Sprint hiện tại; nó dành cho các vật phẩm cho tương lai, rất có thể trong một hoặc hai Sprint tiếp theo. Với cách làm này, Lập kế hoạch Sprint trở nên tương đối đơn giản vì Chủ sở hữu sản phẩm và Nhóm Scrum bắt đầu lập kế hoạch với một bộ các mục rõ ràng, được phân tích kỹ lưỡng và được ước tính cẩn thận. Một dấu hiệu cho thấy hội thảo sàng lọc này không được thực hiện (hoặc không được thực hiện tốt) là Sprint Planning liên quan đến các câu hỏi quan trọng, khám phá hoặc nhầm lẫn và cảm thấy không đầy đủ; công việc lập kế hoạch sau đó thường tràn vào chính Sprint, điều mà thường không mong muốn.

Làm điều này có nghĩa là bạn có thể tập trung vào việc lập kế hoạch trong khi lập kế hoạch và không mất cả ngày và nhóm bắt đầu mất tập trung và cảm thấy buồn chán.

Trong Scrum, khi làm việc đến 2 tuần nước rút, kế hoạch chạy nước rút được đóng hộp thời gian lúc 4 giờ, biến nó thành một sự kiện nửa ngày. Một lý do cho lượng thời gian tương đối lớn là nhóm phát triển phải có thể tự tin đồng ý rằng tất cả các mục được kéo vào tồn đọng nước rút có thể được phân phối, có nghĩa là họ cần biết chi tiết. Không có gì lạ khi một phần của kế hoạch chạy nước rút cho các đội thoát ra khỏi không gian cuộc họp trong một khoảng thời gian để điều tra các mục tiếp theo và đảm bảo rằng họ "Sẵn sàng" để đi vào tồn đọng nước rút. (Nó có thể giúp nghĩ về kế hoạch chạy nước rút như một sự kiện, chứ không phải là một cuộc họp.)

Sử dụng "Định nghĩa về sự sẵn sàng" của bạn và khoảng thời gian mà sự kiện lập kế hoạch chạy nước rút cho phép để đảm bảo rằng tất cả các hạng mục tồn đọng đi vào giai đoạn nước rút đều khả thi và sẵn sàng . tức là chúng có thể được thực hiện (hoàn toàn, theo "Định nghĩa hoàn thành") trong giai đoạn nước rút, và có đủ thông tin để nhóm có thể thực hiện chúng ngay bây giờ.
Tất nhiên lưu ý rằng bạn có thể không muốn làm điều này cho TẤT CẢ các mục trong kế hoạch chạy nước rút, vì nó có thể rất tốn thời gian. Hãy thử và thường xuyên chải chuốt backlog (ngoài kế hoạch chạy nước rút), nơi bạn có thể phân tích các mục tồn đọng và ước tính các mục chưa được ước tính bằng cách sử dụng poker lập kế hoạch chẳng hạn. (Tôi đã thấy đây có thể là một hoạt động hiệu quả trong bữa tối làm việc với nhóm phát triển, nếu bạn có sự sang trọng sẵn có của nhóm bạn vào giờ ăn tối!)

Các mặt hàng ưu tiên cao thường có thể được thêm vào sản phẩm tồn đọng của chủ sở hữu sản phẩm ngay trước khi lập kế hoạch chạy nước rút, và trong khi việc chải chuốt thường xuyên có thể, và thông thường nên được thực hiện trước sự kiện lập kế hoạch nước rút, sẽ luôn có các mặt hàng mới như thế này nhóm cần dành thời gian để tìm hiểu chi tiết và ước tính độ phức tạp trong sự kiện lập kế hoạch nước rút, do đó tại sao nó có thể kéo dài đến 4 giờ trong 10 ngày / 2 tuần nước rút.

Nếu bạn cần phải thảo luận lâu hơn về sự kiện này, thì bạn có thể có một mục tồn đọng trong phần tồn đọng chạy nước rút để "có một cuộc thảo luận như vậy và như vậy để thiết lập x", nhưng bạn nên tránh bao gồm các mục chạy nước rút để làm bất cứ điều gì bạn sẽ làm xác định các nhu cầu được thực hiện trong cuộc thảo luận đó, vì những mục đó không phải là các mục tồn đọng "sẵn sàng" để đi vào nước rút.

Như mọi người đã nói, có những lý do bạn có thể muốn thay đổi cách bạn chạy Scrum nếu quy trình không hoạt động hiệu quả với bạn. Tuy nhiên, Scrum là một khung đã được suy nghĩ rất kỹ và được thử nghiệm để bắt đầu, vì vậy tôi sẽ đảm bảo lý luận của bạn là hợp lý trước khi thay đổi quy trình.

Trong Cuộc họp Lập kế hoạch Sprint, nhóm phải xác định hai nhóm điều:

A) Điều gì sẽ được nhóm phát triển trong Sprint này

B) Nó sẽ được phát triển như thế nào

Cuộc họp này phải được sắp xếp theo thời gian, tối đa hai giờ cho mỗi tuần của Sprint, chia đều cho từng phần (phần A và Phần B) của cuộc họp.

Vì vậy, đối với Sprint 4 tuần, cuộc họp này không quá 8 giờ, tối đa 4 giờ cho phần A và tối đa 4 giờ cho phần B.

Trong phần A, nhóm nhà phát triển phải ước tính vận tốc nhóm mà họ cho rằng họ sẽ có trong Sprint này. Họ cũng phải ước tính các câu chuyện người dùng ưu tiên hàng đầu và chọn đủ các câu chuyện người dùng (đã ước tính) này để hoàn thành phù hợp với vận tốc nhóm ước tính của riêng họ.

Trong phần B, nhóm nhà phát triển sẽ thảo luận về cách phát triển các câu chuyện người dùng khó khăn hơn đã được chọn để phát triển. Rất có thể, nhóm nhà phát triển sẽ không có đủ thời gian để thảo luận về cách phát triển tất cả các câu chuyện người dùng đã chọn, vì vậy, nhóm phải chọn những câu chuyện người dùng khó khăn nhất.

Trong Sprint, nhóm nhà phát triển có đủ thời gian để hoàn thành cuộc thảo luận này.

Theo Hướng dẫn Scrum :

Sự kiện Scrum

Các sự kiện được quy định được sử dụng trong Scrum để tạo sự đều đặn và để giảm thiểu nhu cầu cho các cuộc họp không được xác định trong Scrum. Tất cả các sự kiện là các sự kiện theo thời gian, sao cho mọi sự kiện đều có thời lượng tối đa. Khi Sprint bắt đầu, thời lượng của nó được cố định và không thể rút ngắn hoặc kéo dài. Các sự kiện còn lại có thể kết thúc bất cứ khi nào mục đích của sự kiện đạt được, đảm bảo một lượng thời gian thích hợp được sử dụng mà không cho phép lãng phí trong quá trình.