Mục tiêu lập kế hoạch sprint

Lập kế hoạch sprint chuyển một ưu tiên của sản phẩm thành kế hoạch bàn giao thực tế trong một khoảng thời gian ngắn và cố định. Sau cuộc họp, nhóm cần có một Sprint Goal thống nhất, dự báo về các công việc có giá trị và hiểu rõ các rủi ro cũng như phụ thuộc. Mục tiêu không phải là lấp đầy mọi giờ làm việc khả dụng hoặc cam kết thực hiện mọi hạng mục trong backlog. Mục tiêu là tạo ra một kế hoạch tập trung, giúp các bên liên quan có cái nhìn đáng tin cậy về những gì nhóm dự định bàn giao.

Một Sprint Goal hữu ích mô tả kết quả kinh doanh mà nhóm đang cố gắng đạt được. Ví dụ, mục tiêu như Cải thiện quy trình onboarding cho khách hàng lần đầu hữu ích hơn Hoàn thành tám ticket, vì mục tiêu đó giúp nhóm đưa ra quyết định khi có thông tin mới. Nếu một ticket có mức ưu tiên thấp hơn không đóng góp vào mục tiêu, nhóm có thể xem xét lại việc đưa ticket đó vào sprint, ngay cả khi về mặt kỹ thuật ticket đã sẵn sàng. Product Owner vẫn chịu trách nhiệm sắp xếp thứ tự backlog, còn Developers quyết định khối lượng công việc có thể dự báo một cách hợp lý.

Trước khi lập kế hoạch, hãy xác nhận thời lượng sprint, mức ưu tiên của sản phẩm, trạng thái của backlog và mọi công việc đang được thực hiện. Trong Jira, hãy xem lại backlog và đảm bảo các issue ứng viên có mô tả dễ hiểu, tiêu chí chấp nhận, mức độ ưu tiên phù hợp và các ước tính nhất quán với thỏa thuận làm việc của nhóm. Lập kế hoạch không nên trở thành phương án thay thế cho refinement. Nếu một số issue có mức ưu tiên cao chưa rõ ràng, nhóm nên ghi nhận sự không chắc chắn đó và tránh trình bày các issue này như những cam kết bàn giao chắc chắn.

Năng lực và lựa chọn công việc

Năng lực là lượng thời gian thực tế của nhóm có thể sử dụng trong sprint. Bắt đầu với số ngày làm việc thông thường, sau đó tính đến ngày nghỉ lễ, nghỉ phép đã lên kế hoạch, đào tạo, nhiệm vụ hỗ trợ, các cuộc họp và những trách nhiệm khác. Một nhóm có sáu thành viên có thể có số người thực sự dành toàn thời gian cho việc bàn giao ít hơn nhiều so với sáu người. Năng lực cũng chịu ảnh hưởng bởi các ràng buộc về chuyên môn. Ví dụ, điểm nghẽn trong kiểm thử hoặc khả năng tiếp cận hạn chế với người đánh giá bảo mật có thể hạn chế throughput ngay cả khi các thành viên khác trong nhóm còn thời gian rảnh.

Hãy sử dụng dữ liệu bàn giao gần đây để kiểm tra tính hợp lý, không xem đó là mục tiêu mặc định. Nếu nhóm thường hoàn thành từ hai mươi lăm đến ba mươi story point nhưng có hai người nghỉ phép, việc chọn ba mươi point chỉ vì nhóm đã đạt con số đó ở sprint trước là cách lập kế hoạch thiếu thuyết phục. Dự báo phải phản ánh cả bằng chứng lịch sử lẫn điều kiện hiện tại. Nhóm cũng có thể chủ động để lại một khoảng đệm nhỏ cho các gián đoạn vận hành, đặc biệt khi sản phẩm đang phục vụ khách hàng hoặc có khối lượng hỗ trợ cao.

Hãy chọn các hạng mục có mức ưu tiên cao nhất, đã sẵn sàng và đóng góp vào Sprint Goal. Kiểm tra các phụ thuộc trước khi chốt dự báo. Một tính năng phụ thuộc vào phê duyệt từ bên ngoài, quá trình di chuyển dữ liệu hoặc một nhóm khác có thể nhỏ về mặt kỹ thuật nhưng lại tiềm ẩn rủi ro về vận hành. Trong Jira, hãy đưa các issue đã chọn vào sprint, xác minh thứ tự của chúng và đảm bảo mối quan hệ giữa các issue cũng như ghi chú về phụ thuộc hiển thị với những người cần xem. Hãy phân biệt giữa dự báo và lời hứa: nhóm dự báo những gì họ tin rằng có thể hoàn thành, còn Product Owner và các bên liên quan cần hiểu những giả định đứng sau dự báo đó.

Thực hiện Sprint trong Jira

Trong quá trình thực hiện, Jira nên giúp dễ dàng nắm bắt tình hình hiện tại mà không thay thế việc trao đổi trong nhóm. Sử dụng Scrum board để thể hiện quy trình đã thống nhất, chẳng hạn như Cần làm, Đang thực hiện, Đang xem xét và Hoàn tất. Các cột cụ thể phải phù hợp với quy trình bàn giao của nhóm. Một ticket chỉ nên được chuyển khi công việc liên quan thực sự đã đạt đến trạng thái tiếp theo. Ví dụ, không nên chuyển một issue sang Hoàn tất chỉ vì phần phát triển đã hoàn thành nếu vẫn còn yêu cầu kiểm thử hoặc nghiệm thu.

Duy trì sự rõ ràng về người phụ trách issue. Mỗi issue đang hoạt động phải có một assignee chịu trách nhiệm hoặc một trách nhiệm rõ ràng đã được nhóm thống nhất. Thêm các bình luận hữu ích khi một quyết định, yêu cầu làm rõ hoặc giả định về khách hàng có thể ảnh hưởng đến công việc sau này. Tránh biến Jira thành bản ghi đầy đủ của mọi cuộc trao đổi. Chỉ ghi lại những thông tin giúp thành viên khác trong nhóm hiểu được trạng thái hiện tại, hành động tiếp theo hoặc tác động của một quyết định.

Quản lý công việc đang thực hiện một cách có chủ đích. Nếu bắt đầu quá nhiều issue cùng lúc, board có thể trông rất bận rộn trong khi thực tế hoàn thành được rất ít việc. Nhóm nên hoàn tất các công việc có giá trị cao trước khi kéo thêm item mới, tùy theo workflow và các ràng buộc về chuyên môn. Nếu một issue bị chặn, hãy làm cho tình trạng đó hiển thị rõ ràng bằng quy ước Jira đã thống nhất của nhóm, chẳng hạn như đánh dấu issue, thêm nhãn blocker, liên kết dependency hoặc ghi rõ trạng thái kèm tài liệu giải thích. Quy ước cụ thể không quan trọng bằng việc sử dụng nhất quán và theo dõi xử lý nhanh chóng.

Một issue bị chặn nên nêu rõ nguyên nhân, người phụ trách hành động tiếp theo và thời điểm dự kiến xem xét lại. Ví dụ, Chờ nhà cung cấp dịch vụ thanh toán xác nhận có tính hành động cụ thể hơn so với Bị chặn. Nếu blocker đe dọa Sprint Goal, hãy nêu vấn đề trong daily Scrum và chuyển cấp cho Product Owner hoặc stakeholder phù hợp. Daily Scrum nhằm kiểm tra tiến độ hướng tới mục tiêu và điều chỉnh kế hoạch, không phải để từng người lần lượt báo cáo trạng thái cho một quản lý.

Quản lý Thay đổi và Rủi ro

Một sprint không tách rời khỏi thực tế kinh doanh. Sự cố từ khách hàng, yêu cầu pháp lý, phát hiện kỹ thuật và lỗi dependency có thể đòi hỏi phản hồi. Trước tiên, nhóm nên đánh giá liệu thay đổi đó có hỗ trợ Sprint Goal hay không, liệu có thể thực hiện trong capacity còn lại hay không và công việc hiện tại nào sẽ bị thay thế. Bổ sung công việc mà không loại bỏ hoặc ước tính lại một nội dung khác sẽ tạo ra một dự báo thiếu tin cậy.

Product Owner và Developers nên làm rõ các đánh đổi. Nếu một vấn đề khẩn cấp từ khách hàng phải được đưa vào sprint, hãy loại bỏ một item có giá trị thấp hơn hoặc nêu rõ rằng dự báo đã thay đổi. Không được âm thầm giữ nguyên phạm vi ban đầu trong Jira rồi bổ sung thêm công việc. Hãy cập nhật độ ưu tiên của issue, các nội dung trong sprint và những bình luận liên quan để board phản ánh kế hoạch hiện tại. Nếu Sprint Goal không còn thực tế, hãy thảo luận xem có thể duy trì mục tiêu bằng cách điều chỉnh phạm vi hay sprint cần được can thiệp chính thức theo thực hành Scrum của nhóm.

Hãy sử dụng rủi ro như các tín hiệu để ra quyết định thay vì chỉ coi chúng là một danh sách tĩnh. Một rủi ro nên có đánh giá về xác suất hoặc tác động, người phụ trách và phương án ứng phó đã lên kế hoạch. Ví dụ, nếu một tích hợp bên thứ ba vẫn chưa xác nhận môi trường kiểm thử vào giữa sprint, nhóm có thể chuyển sang hướng kiểm thử bằng mock, chuyển cấp dependency hoặc loại item tích hợp khỏi dự báo. Điểm quan trọng là đưa ra quyết định trước khi rủi ro trở thành một bất ngờ vào phút chót.

Trao đổi với Stakeholder và Chỉ số

Stakeholder cần một góc nhìn cô đọng về tiến độ, mức độ tin cậy, rủi ro và các quyết định cần được đưa ra. Một bản cập nhật hữu ích sẽ nêu Sprint Goal, những gì đã hoàn thành, những gì đang thực hiện, những gì có nguy cơ gặp vấn đề và liệu dự báo có thay đổi hay không. Bản cập nhật nên giải thích tác động kinh doanh thay vì chỉ báo cáo rằng các ticket đã được chuyển giữa các cột. Ví dụ, nói rằng Tính năng khôi phục tài khoản khách hàng đã sẵn sàng để nghiệm thu sẽ hữu ích hơn so với nói rằng có ba issue đang ở trạng thái Hoàn tất.

Jira có thể hỗ trợ việc trao đổi này thông qua sprint view, board, report, dashboard và lịch sử issue, tùy thuộc vào cấu hình dự án. Hãy sử dụng các report như biểu đồ burndown một cách thận trọng. Burndown có thể cho thấy khối lượng công việc còn lại thay đổi theo thời gian như thế nào, nhưng không chứng minh rằng nhóm đang tạo ra giá trị cho khách hàng. Một đường biểu diễn đi ngang có thể cho thấy đang bị chặn, cập nhật muộn, các item lớn được hoàn thành theo từng đợt hoặc việc ước tính không chính xác. Hãy tìm hiểu ý nghĩa của xu hướng đó trước khi phản ứng.

Theo dõi một nhóm nhỏ các chỉ số hỗ trợ việc ra quyết định. Các thước đo hữu ích bao gồm khối lượng công việc đã hoàn thành so với dự báo, số lượng và thời gian tồn tại của các vấn đề bị chặn, thời gian chu kỳ từ lúc bắt đầu đến khi hoàn thành, các lỗi lọt ra ngoài, và tiến độ hướng tới Sprint Goal. Tránh sử dụng story point để so sánh từng cá nhân hoặc các đội nhóm. Chỉ số nên làm rõ những điều kiện cần được chú ý, không khuyến khích các đội thổi phồng ước tính hoặc tối ưu hóa theo số lượng ticket.

Rà soát và Cải tiến

Vào cuối sprint, hãy kiểm tra increment cùng khách hàng, người dùng hoặc các bên liên quan phù hợp. Trình bày những kết quả đã hoàn thành và ghi nhận phản hồi có ảnh hưởng đến việc sắp xếp thứ tự backlog trong tương lai. Một hạng mục không trở nên có giá trị chỉ vì đã đạt trạng thái Done; đội cần xác minh rằng hạng mục đó đáp ứng các tiêu chí chấp nhận đã thống nhất và kết quả có thể sử dụng được trong bối cảnh kinh doanh dự kiến.

Trong buổi retrospective, hãy đánh giá cả kế hoạch lẫn quá trình thực thi. So sánh dự báo với khối lượng hoàn thành thực tế, sau đó xem xét nguyên nhân của sự khác biệt. Các nguyên nhân phổ biến bao gồm refinement chưa rõ ràng, công việc phụ thuộc bị che khuất, có quá nhiều công việc đang thực hiện, thay đổi vào phút chót hoặc các giả định về năng lực không phù hợp với thực tế. Tránh xem sai lệch là một phán xét về hiệu suất khi chưa hiểu hệ thống đã tạo ra sai lệch đó.

Chọn một hoặc hai cải tiến cụ thể cho sprint tiếp theo. Một cải tiến có thể là xác nhận các phụ thuộc bên ngoài trước khi planning, giới hạn số lượng vấn đề đang được review, bổ sung bước kiểm tra mức độ sẵn sàng cho các story rủi ro cao hoặc xác định quy trình escalation nhanh hơn cho công việc bị chặn. Ghi lại hành động ở một nơi dễ nhìn thấy và phân công người chịu trách nhiệm. Retrospective chỉ có giá trị thực tiễn khi đội thay đổi một hành vi, quy trình làm việc hoặc quy tắc ra quyết định trong sprint sau đó.

Kỷ luật cốt lõi rất đơn giản: lập kế hoạch xoay quanh một kết quả, kiểm chứng dự báo dựa trên năng lực thực tế, làm cho công việc và các yếu tố cản trở hiển thị trong Jira, trao đổi sớm về các thay đổi, và kiểm tra xem increment đã bàn giao có tạo ra giá trị dự kiến hay không. Cách tiếp cận này mang lại cho đội sự linh hoạt trong quá trình thực thi mà không làm giảm trách nhiệm giải trình với khách hàng và các bên liên quan.