Scrum - cách chuyển Câu chuyện người dùng đã hoàn thành một phần sang Sprint tiếp theo mà không làm sai lệch hồ sơ tồn đọng

Chúng tôi đang sử dụng Scrum và đôi khi thấy rằng chúng tôi hoàn toàn không thể hoàn thành Câu chuyện người dùng trong giai đoạn nước rút mà nó đã được lên kế hoạch. Theo kiểu Scrum thực sự, dù sao chúng tôi cũng gửi phần mềm và xem xét bao gồm Câu chuyện người dùng trong lần chạy nước rút tiếp theo trong phiên Lập kế hoạch Sprint tiếp theo. Cho rằng Câu chuyện người dùng mà chúng tôi đang thực hiện đã hoàn tất một phần, làm thế nào để chúng tôi ước tính chính xác cho nó trong phiên Lập kế hoạch Sprint tiếp theo? Chúng tôi đã xem xét:

a) Điều chỉnh số lượng Điểm câu chuyện xuống để phản ánh chỉ công việc còn lại để hoàn thành Câu chuyện của người dùng. Thật không may, điều này sẽ gây rối khi báo cáo Product Backlog.

b) Đóng Câu chuyện người dùng đã hoàn thành một phần và nâng cao câu chuyện mới để triển khai phần còn lại của tính năng đó, sẽ có ít Điểm câu chuyện hơn. Điều này sẽ ảnh hưởng đến khả năng của chúng tôi khi nhìn lại những gì chúng tôi đã không hoàn thành trong lần chạy nước rút đó và có vẻ hơi tốn thời gian.

c) Không bận tâm với a hoặc b và tiếp tục đoán trong Sprint Planning nói những câu như "Chà câu chuyện của người dùng có thể là điểm X, nhưng tôi biết nó đã hoàn thành 95% nên tôi chắc chắn chúng tôi có thể phù hợp với nó."

Trong đội hiện tại của tôi, chúng tôi làm c).

Vận tốc sẽ chiếm những thứ mà đội thực sự hoàn thành trong giai đoạn nước rút. Một cái gì đó không được cung cấp không có giá trị cho khách hàng, vì vậy chúng tôi không tính bất kỳ điểm nào cho nó, đó là tất cả hoặc không có gì.

Vì vậy, chúng tôi chuyển toàn bộ câu chuyện còn dang dở sang lần chạy nước rút tiếp theo và tất cả các điểm câu chuyện của nó sẽ được thêm vào vận tốc của lần chạy nước rút tiếp theo. Vận tốc thậm chí hết theo thời gian và chúng tôi lấy trung bình một vài lần chạy nước rút trước đó làm tài liệu tham khảo để xác định vận tốc trong tương lai.

Tùy chọn A là một quá trình hành động thường được đề nghị. Bạn không được thưởng điểm khi hoàn thành câu chuyện cho lần chạy nước rút trước đó và để chuyển câu chuyện trở lại vào hồ sơ tồn đọng của sản phẩm, nơi nó được sắp xếp lại. Bạn tính toán vận tốc của mình (và các số liệu khác) dựa trên các câu chuyện người dùng đã hoàn thành và giá trị gia tăng. Khi bạn bắt đầu lập kế hoạch cho lần chạy nước rút tiếp theo, bạn sẽ lấy những câu chuyện ưu tiên cao nhất dựa trên giá trị của chúng (có thể bao gồm hoặc không bao gồm câu chuyện còn dang dở, nếu các ưu tiên kinh doanh đã thay đổi). Khi bạn ước tính câu chuyện, hãy bao gồm các công việc đã được thực hiện khi bao thanh toán trong số điểm mới cho câu chuyện.

Tất nhiên, một lựa chọn thay thế (và sở thích của tôi) sẽ là sử dụng số điểm câu chuyện ước tính ban đầu, đây là điều mà tôi đã làm trong quá khứ. Điều này đưa ra giả định rằng ước tính của bạn là tốt và có cơ sở, nhưng bạn đã giảm quá nhiều công việc cho lần chạy nước rút (ví dụ: câu chuyện thực sự đáng giá 3 điểm, nhưng vấn đề nằm ở chỗ bạn đã rút xuống 15 điểm câu chuyện khi bạn chỉ nên kéo xuống 13). Đó là một giả định nguy hiểm tiềm tàng nếu bạn không tự tin vào khả năng thực hiện các ước tính của mình, nhưng nó có thể hoạt động dựa trên nhóm và quy trình của bạn.

Tuy nhiên, bạn đề cập rằng điều này sẽ "làm rối tung báo cáo của Product Backlog". Product Backlog dù sao cũng phải năng động, với thứ tự và ước tính của từng câu chuyện thay đổi khi được hiểu nhiều hơn về công nghệ, hệ thống, các yêu cầu và khách hàng. Thông thường, những gì được báo cáo từ Product Backlog là số lượng câu chuyện của người dùng và tổng số điểm câu chuyện. Chúng nên được thay đổi khi các ưu tiên thay đổi, các yêu cầu mới được thêm vào, các yêu cầu không hợp lệ được loại bỏ và nhiều thông tin hơn được học.

Suy nghĩ quá nhiều về điều này làm cho nó có vẻ phức tạp hơn nó ... Nó thực sự khá đơn giản:

Tùy chọn C

Câu chuyện không đầy đủ quay trở lại tồn đọng sản phẩm, mà không có điểm được thay đổi. Khi lập kế hoạch cho lần chạy nước rút tiếp theo và những gì có thể hoàn thành, cuộc thảo luận nên bao gồm thực tế là phần lớn công việc đã được hoàn thành. Nếu nhóm quyết định họ có thể đưa nó vào giai đoạn nước rút, thì nó sẽ đi vào, với số điểm ban đầu. Nếu không, nó vẫn ở trong tồn đọng. Làm xong. Các điểm được trao cho nước rút trong đó câu chuyện đã được hoàn thành.

Nếu nó hữu ích, bạn có thể theo dõi một số liệu "công việc còn lại" riêng cho mỗi câu chuyện của người dùng, để nếu đến cuối giai đoạn nước rút, câu chuyện không hoàn thành, công việc ước tính còn lại có thể được ghi chú vào câu chuyện và được thực hiện khi lập kế hoạch đưa nó vào một lần chạy nước rút tiếp theo. Nhưng ngay cả sau đó, đừng thay đổi giá trị điểm của câu chuyện gốc.

Nếu công cụ báo cáo của bạn không thể xử lý chính xác tùy chọn A thì tôi sẽ sử dụng tùy chọn B trừ khi bạn không có hy vọng sử dụng số liệu của mình.

Trong một số trường hợp, bạn có thể thực hiện tùy chọn B VÀ không làm lệch nghĩa là đóng bằng cách thu hẹp phạm vi của tác vụ cũ mà bạn sắp đóng và chỉ tạo một tác vụ mới cho phạm vi còn lại. Điều này làm cho lịch sử có ý nghĩa hơn về mặt ngữ nghĩa và thường chỉ ra những nơi mà bạn nên xem xét phá vỡ nhiệm vụ hơn nữa. Đôi khi điều này là không thể hoặc logic và bạn chỉ đơn giản là có một nhiệm vụ lớn hoặc chạy vào cấp độ vấn đề đó.

chỉnh sửa: Điều này giả định (như tôi tin rằng OP đã giả định) rằng công việc gần như hoàn thành đã không bị đánh sập trong ưu tiên và việc đạt được kết quả cho nỗ lực trước đó giữ cho nó đủ cao trong danh sách để tiếp tục hoạt động. Tôi biết một số cửa hàng không làm điều này, nhưng hầu hết các nơi tôi đã làm việc đều cân nhắc việc hoàn thành một nhiệm vụ còn sót lại gần như hoàn toàn đủ giá trị để tiếp tục đơn giản trừ khi có gì đó thay đổi đáng kể. Hình phạt của việc thay đổi bối cảnh thường không đáng để thay đổi thứ tự.

Cho rằng Câu chuyện người dùng mà chúng tôi đang thực hiện đã hoàn tất một phần, làm thế nào để chúng tôi ước tính chính xác cho nó trong phiên Lập kế hoạch Sprint tiếp theo?

Tôi không nghĩ các lựa chọn từ A đến C là tốt, chủ yếu bởi vì điều (tôi nghĩ) nên quan trọng nhất đối với vận tốc của một đội là vận tốc trung bình và không phải là vận tốc của bất kỳ lần chạy nước rút nào tăng hay giảm.

Khi một câu chuyện người dùng được xác định, nó sẽ có tiêu chí chấp nhận. Nếu bất cứ điều gì trong tiêu chí chấp nhận không được thực hiện, thì nhóm chỉ đơn giản là không kiếm được bất kỳ điểm nào. Nếu câu chuyện được thực hiện - được thực hiện (tức là được mã hóa, thử nghiệm và được PO chấp nhận) thì nhóm sẽ nhận được tất cả các điểm.

Điều này hoạt động tốt khi nhóm nghiên cứu tập trung vào vận tốc trung bình của nó chứ không phải là vận tốc nước rút nhất định.

Giống như M. Cohn trong cuốn sách của mình, tôi có xu hướng thích một kịch bản hoàn toàn hoặc không có gì. Rốt cuộc, cố gắng ước tính xem bạn đã hoàn thành 5 điểm trong câu chuyện 8 điểm hay có thể chỉ 6 hoặc 7 sẽ kết thúc bằng một trò chơi đoán khác ... và đừng quên rằng bạn đã có bản gốc ước tính cách tắt. Có lẽ tốt hơn là chỉ nên làm theo phương pháp đơn giản nhất và khi đạt được tất cả các điểm sau khi nó thực sự được hoàn thành.

Trích dẫn M. Cohn từ cuốn sách của mình¹ (nhấn mạnh của tôi):

Tôi thường ủng hộ lập trường tất cả hoặc không có gì trong việc đếm vận tốc: nếu một câu chuyện được thực hiện (được mã hóa, thử nghiệm và được chấp nhận bởi chủ sở hữu sản phẩm), nhóm sẽ kiếm được tất cả các điểm, nhưng nếu bất cứ điều gì trong câu chuyện không xảy ra Làm xong, họ chẳng kiếm được gì. Khi kết thúc một lần lặp, đây là trường hợp dễ nhất để đánh giá: Nếu mọi thứ được thực hiện, họ sẽ nhận được tất cả các điểm; nếu thiếu bất cứ thứ gì, họ không nhận được điểm nào. Nếu nhóm có khả năng đảm nhận phần còn lại của câu chuyện trong lần lặp lại tiếp theo, thì điều này hoạt động tốt. Vận tốc của họ trong lần lặp đầu tiên thấp hơn một chút so với dự kiến ​​vì họ không có tín dụng cho việc hoàn thành một phần câu chuyện. Tuy nhiên, trong lần lặp thứ hai, vận tốc của chúng sẽ cao hơn mong đợi vì chúng sẽ nhận được tất cả các điểm, mặc dù một số công việc đã được hoàn thành trước khi bắt đầu lần lặp.Điều này hoạt động tốt miễn là mọi người đều nhớ rằng chúng ta chủ yếu quan tâm đến vận tốc trung bình của đội theo thời gian, không phải là liệu vận tốc có nhảy lên hay xuống trong một lần lặp nhất định.

¹ Agile Ước và Kế hoạch , Re dự toán một phần Hoàn Stories, p.66

Nhóm của tôi trước đây đã cố gắng chỉ định một phần điểm, mặc dù có một số phản đối và tôi không nghĩ rằng nó hoạt động tốt cả. (Chúng tôi không làm điều đó nữa ... đi con số) Điều này đặc biệt các trường hợp vì những câu chuyện có nghĩa vụ phải được ước tính như một đội bóng , nhưng nếu chỉ có một người đang làm việc trên nó, nó sẽ khó khăn hơn cho các nhóm để biết bao nhiêu một cá nhân đã thực sự hoàn thành. Agile quan tâm nhiều hơn đến vận tốc trung bình của một đội hơn là về mức độ "đẹp" của một lần chạy nước rút cụ thể.

Điều đó đang được nói, tác giả có đề cập đến việc gán điểm một phần có thể được xem xét nếu nhóm không có khả năng giải quyết công việc còn lại trong lần lặp tiếp theo. Trong trường hợp này, nhóm sẽ ước tính công việc còn lại và chia nó thành các câu chuyện người dùng mới với bất kỳ kích thước nào họ cảm thấy nên có. Như tác giả đề cập²:

Các ước tính kết hợp sẽ không cần bằng với ước tính ban đầu ...

² Ditto, tr.66

Đề xuất tốt hơn cho nhóm là chia nhỏ các câu chuyện xuống kích thước đủ nhỏ để tránh loại vấn đề này:

Tuy nhiên, hai giải pháp tốt nhất để phân bổ điểm cho các câu chuyện chưa hoàn chỉnh là không có bất kỳ câu chuyện chưa hoàn chỉnh nào và sử dụng các câu chuyện đủ nhỏ mà tín dụng một phần không phải là vấn đề.

Ditto, tr.67

Hi vọng điêu nay co ich.

Tôi ngạc nhiên dường như không có câu trả lời thẳng cho vấn đề này. Tôi đã mong đợi một điệp khúc của "tùy chọn D, giả"!

Vì chúng tôi dường như không thiếu bất cứ điều gì rõ ràng, chúng tôi nghĩ rằng đây là một trong những quyết định mà mỗi đội cần tự đưa ra dựa trên cách họ muốn làm việc và những số liệu nào là quan trọng nhất đối với họ.

Chúng tôi đã quyết định rằng việc lưu giữ các hồ sơ chính xác về các câu chuyện của người dùng mà chúng tôi đã triển khai là điều cần thiết, vì đây là cơ sở để thử nghiệm, tài liệu hỗ trợ và ghi chú phát hành - loại trừ tùy chọn B.

Tiếp theo, chúng tôi đã tìm ra rằng việc có thể thực hiện kế hoạch chạy nước rút một cách chính xác là điều cần thiết - loại trừ tùy chọn C.

Do đó, chúng tôi đã kết luận rằng tùy chọn A phù hợp với chúng tôi. Chúng tôi sẽ ước tính lại các điểm câu chuyện cho bất kỳ câu chuyện nào chúng tôi hoàn thành một phần trong lần chạy nước rút để chúng tôi có thể lập kế hoạch cho chúng đúng cách trong các lần chạy nước rút tiếp theo. Theo thời gian, việc tồn đọng sản phẩm sẽ hơi báo cáo số lượng điểm câu chuyện chúng tôi đã triển khai, nhưng điều này sẽ ít gây ra sự cố hơn bất kỳ tùy chọn nào khác và có thể được giải quyết bằng cách thay đổi lưu trữ và báo cáo hồ sơ của chúng tôi.

Chúng tôi theo dõi thời gian dành cho lần chạy nước rút cho mục đích viết hoa, (hàng giờ bị cháy trong các nhiệm vụ liên quan đến câu chuyện của người dùng) và chuyển câu chuyện người dùng nhọn theo nếu mục tiêu của PO là tiếp tục lái xe trong lần chạy nước rút tiếp theo, rời đi điểm giống nhau.

Nếu mục tiêu của PO là đưa một thứ khác lên vị trí của nó, thì chúng ta chỉ cần đưa câu chuyện còn dang dở vào tồn đọng và làm bất cứ điều gì họ muốn. Bỏ ước tính ban đầu về điểm là khuyến nghị của tôi, bởi vì nếu bạn có thói quen cắn nhiều hơn bạn có thể nhai, mỗi lần chạy nước rút, bạn sẽ "hoàn thành" các điểm câu chuyện trong một lần chạy nước rút chưa hoàn thành và sạch sẽ- các mặt hàng thử nghiệm.

Nếu bạn muốn để lại một cái gì đó trong nước rút, chỉ hoặc bạn phải giao hàng, tôi nghĩ bạn sẽ xác định một điểm cắt trong câu chuyện gốc, mà bạn đã đạt đến điểm đã hoàn thành và cam kết mảnh nhỏ hơn đó cho lần lặp của bạn. Sau đó, phần còn lại có thể được chỉ ra lại, và rơi vào tồn đọng. Đó sẽ là một cơ hội để ước tính lại bởi vì bạn đã đồng ý với nhóm của mình để chia câu chuyện thành các lát.

Câu hỏi đầu tiên cần đặt ra là Story Point có ý nghĩa gì? Nếu bạn xác định một điểm câu chuyện là "Bao nhiêu công việc kỹ thuật được thực hiện", thì bất kỳ câu trả lời sẽ làm. Tuy nhiên, nếu bạn xác định một điểm câu chuyện là "Bao nhiêu giá trị được phân phối cho doanh nghiệp", thì điều quan trọng là không cung cấp tín dụng cho đến khi câu chuyện được hoàn thành 100%, được chấp nhận và giao 100%. Sửa đổi điểm câu chuyện sau khi chạy nước rút dựa trên những gì đã hoàn thành sẽ chỉ che giấu vấn đề thực sự: a) không hiểu rõ về câu chuyện, b) câu chuyện được định nghĩa quá thô thiển, c) câu chuyện thiếu tiêu chí chấp nhận có thể đo lường được, d ) không đủ hiểu biết sâu sắc về các nhiệm vụ hoặc sự phụ thuộc để hoàn thành câu chuyện, e) nhấn mạnh nỗ lực kiểm tra câu chuyện, f) kéo xuống quá nhiều điểm câu chuyện, hoặc g) ... chèn lý do của bạn vào đây ...

Mục tiêu của nhanh nhẹn là linh hoạt trong khi có thể dự đoán được. Theo tôi, cách tốt nhất để thống nhất là tìm ra những gì đã sai mà không sửa đổi ước tính câu chuyện gốc.