Scrum đánh giá quá cao và bổ sung

Chúng tôi đang ở giữa Sprint đầu tiên của chúng tôi và một cái gì đó bình minh trên chúng tôi: chúng tôi đã ước tính quá mức!

Chúng tôi đã lên kế hoạch 114 giờ lý tưởng cho vòng lặp 2 tuần này và vào cuối tuần đầu tiên, chúng tôi đã hoàn thành toàn bộ Sprint. Chúng ta làm gì bây giờ? "Cuốn sách" nói rằng chúng ta nên, và chúng ta sẽ, có được các mục ưu tiên cao tiếp theo từ hồ sơ tồn đọng. Mặc dù, làm thế nào để chúng ta thêm chúng vào biểu đồ ghi xuống? Chúng ta có viết lại nó để giải thích cho những câu chuyện như thể chúng ở đó từ lúc bắt đầu không? Hoặc chỉ cần thêm ước tính của họ vào trục y trong ngày chúng ta bắt đầu làm việc với chúng (hiển thị bước nhảy 90o)?

Bất kỳ thông tin phản hồi đều được chào đón!

Một trong những mục đích của việc có một biểu đồ phát sinh là cho thấy cách thức, theo thời gian và minh bạch, giá trị đang được cung cấp.

Những câu chuyện của người dùng mới không ở giai đoạn nước rút ngay từ đầu, vì vậy có vẻ hơi khó để giả vờ rằng họ là như vậy. Bằng cách thêm chúng vào biểu đồ phát sinh tại thời điểm này, bạn đang thể hiện chính xác rằng mức độ ước tính hiện tại vẫn còn phần nào trong các giai đoạn tiến hóa sơ bộ của nó.

Điều này là tốt cho bạn và cho chủ sở hữu sản phẩm của bạn. Nó cho thấy, và sẽ cho thấy, việc sử dụng hệ thống quản lý dự án này đã và sẽ cho phép bạn trở thành người ước tính tốt hơn như thế nào.

Bạn sẽ có thể thấy ngay từ đầu rằng bạn đã ước tính quá mức, sau đó theo ước tính, sau đó ước tính hơn một chút nhưng ít hơn một chút ... và cuối cùng bạn sẽ thấy những cải thiện trong việc ước tính khi bạn đi cùng.

Tôi nghĩ rằng việc ước tính các câu chuyện của người dùng là một trong những phần khó nhất của một lần chạy nước rút và chỉ khi nhóm của bạn học cách phát triển cùng nhau, họ sẽ ngày càng trở nên hiệu quả hơn trong quá trình này. Thật tốt khi điều này được thể hiện thông qua các công cụ bạn đang sử dụng, chẳng hạn như biểu đồ phát sinh.

Sẽ không hại gì nếu bạn hủy bỏ lần chạy nước rút và lên kế hoạch cho lần chạy nước rút tiếp theo bằng cách tính đến vận tốc hiện tại của bạn.

Từ Hướng dẫn Scrum chính thức :

Sprint có thể bị hủy trước khi hộp thời gian Sprint kết thúc. Chỉ Chủ sở hữu sản phẩm mới có quyền hủy Sprint, mặc dù họ có thể làm như vậy dưới ảnh hưởng của các bên liên quan, Nhóm hoặc ScrumMaster.

Vì kế hoạch chạy nước rút nên được thực hiện trong một cuộc thảo luận với chủ sở hữu sản phẩm, chủ scrum và nhóm, nên sẽ rất hiệu quả nếu chỉ chọn những câu chuyện của người dùng tiếp theo.

Trong trường hợp bạn hơi trước, bạn có thể chọn câu chuyện ưu tiên cao nhất tiếp theo, nhưng ở đây tình huống của bạn rất khác.

Bạn có thể thêm một biểu đồ ghi lên . Chúng hiển thị, không có sự mơ hồ, khi nào và bao nhiêu công việc mới mà bạn đã thêm:

Biểu đồ này cho thấy nhóm đã thêm 20 điểm làm việc trong lần lặp 5. Hình ảnh này hiển thị các lần lặp, nhưng nó hoạt động tốt như ngày.

Có một số kỹ thuật khác nhau để hình dung điều này.

Một trong số đó là giới thiệu một phần bù cho trục y (trục hoành) vào ngày các câu chuyện mới được thêm vào, với biểu đồ phát sinh thực tế sau đó đi xuống dưới mức "0" ban đầu.

Một cách khác là giả vờ rằng họ đã ở đó ngay từ đầu (việc sử dụng đồ thị dựa trên CGI dễ dàng hơn rất nhiều).

Và bạn có thể đến với của riêng bạn.

Điều quan trọng nhất là thảo luận về vấn đề này giữa nhóm, chủ scrum và chủ sở hữu sản phẩm để đạt được thỏa thuận về những gì bạn muốn làm trong tình huống này. Không có cách hoàn toàn cố định để làm bất cứ điều gì trong scrum ngoài các quy tắc cơ bản. Scrum có nghĩa là phát triển theo thời gian để phù hợp nhất với nhu cầu của môi trường của bạn.

Tôi muốn chia nhỏ vấn đề của OP thành ba câu hỏi riêng biệt:

1. Tiếp tục hay hủy bỏ nước rút?
2. Làm gì trong tuần còn lại nếu nước rút tiếp tục?
3. Làm thế nào để lập kế hoạch nước rút tiếp theo?

Biểu đồ Burndown và burn-up được đề cập trong các câu hỏi khác, trong khi hữu ích, là thứ yếu của OP "chúng ta phải làm gì bây giờ?"

Tiếp tục hoặc hủy bỏ : Tôi với Pierre ở đây, rất thích hợp để hủy bỏ lần chạy nước rút này và bắt đầu lập kế hoạch cho lần tiếp theo ngay lập tức. Hủy bỏ Sprint không phải là một lựa chọn nếu có các đội khác và chạy nước rút cần được đồng bộ hóa (hầu hết các chuyên gia Scrum khuyên rằng họ nên được đồng bộ hóa).

Nếu nước rút tiếp tục: Hạn chế công việc đang tiến hành . Làm việc chỉ một câu chuyện tại một thời điểm, tập trung vào hoàn thiện, mà bạn có ít hơn một tuần. Hãy chắc chắn rằng không có câu chuyện nào ở trạng thái hoàn thành một phần vào cuối nước rút.

Cách lên kế hoạch cho kế tiếp : các tùy chọn ở đây là thử ước lượng kích thước tương đối hoặc sử dụng tính tương đương của câu chuyện giữa người và điểm và yếu tố trọng tâm như một xấp xỉ như được mô tả trong cuốn sách "Scrum và XP từ rãnh" của Henrik Kniberg. Chúng tôi đã thảo luận về nó đã trong một chủ đề khác nhau.

Hoàn thành trong một nửa thời gian là một biến thể rất lớn so với ước tính. Đối với tôi, điều đó sẽ chỉ ra một rủi ro đáng kể rằng những gì nhóm của bạn thực sự đã làm lệch khỏi những gì người dùng mong đợi khi bắt đầu Sprint. Ngoài ra, một Sprint cũng được cho là cung cấp đủ chức năng mà giờ là lúc có phản hồi mới từ PO.

Vì vậy, rủi ro khi chỉ lấy những thứ trên đỉnh PB và tiếp tục là những vật phẩm trên đỉnh PB đã hết hạn (cả về nội dung và mức độ ưu tiên) và Nhóm của bạn đã gặp sự cố trong Sprint cuối cùng và bạn sẽ chỉ dựa vào những sai lầm đó mà không nhận được phản hồi từ PO.

Tôi muốn nói rằng cách hành động hợp lý nhất là gọi cho Sprint được thực hiện, giữ kết thúc đánh giá Sprint thông thường của bạn, lên kế hoạch họp và hồi cứu và bắt đầu trên Sprint tiếp theo.

Đối với các công cụ biểu đồ phát sinh, câu hỏi ban đầu dường như bỏ lỡ điểm của những gì nó làm. Đây thực sự chỉ là một công cụ để xác định xem bạn có gặp vấn đề với tiến trình trong Sprint hay không. Với những gì đã được mô tả, biểu đồ phát sinh nên xuất hiện trong tình huống này vào khoảng ngày 2 hoặc 3 của Sprint, khi đó nó sẽ cho thấy Đội đã đi trước, vượt tiến độ trong các nhiệm vụ của Sprint. Sau đó, bạn đặt câu hỏi "Tại sao?", Và xác định xem liệu ước tính của bạn có bị tắt hay có thể các lập trình viên đang diễn giải sai các nhiệm vụ, hoặc nếu có gì đó không ổn.

Nhưng khi bạn bỏ qua biểu đồ phát sinh và hành trình như không có gì kỳ lạ xảy ra, thì có vẻ như bạn chỉ coi nó như một vật phẩm vô nghĩa mà bạn đang sản xuất vì "cuốn sách" nói với bạn. Theo ý kiến ​​của tôi, nếu bạn quyết định chỉ cần rút thêm một số thứ khác ra khỏi đỉnh PB và tiếp tục cho tuần thứ hai, thì hãy bắt đầu một phiên bản mới cho tuần thứ hai (và sau đó bạn có thể bỏ qua như bạn đã làm cho tuần đầu tiên).

Tôi sẽ tham khảo ý kiến ​​của chủ sở hữu sản phẩm về những việc cần làm và thêm nó vào lần chạy nước rút hiện tại vào ngày công việc được đưa vào. Người ta có thể theo dõi công việc được thêm vào trên biểu đồ ghi lại. Tôi không gặp vấn đề gì với biểu đồ ghi hình trông hơi giống tàu lượn siêu tốc. Điều này sẽ xảy ra dù sao vì các thành viên scrum ước tính thời gian còn lại trên các nhiệm vụ.