Có lý do tại sao dự báo thời tiết cho biết có 70% khả năng mưa thay vì hứa hẹn rằng trời sẽ mưa chính xác vào lúc 3 giờ chiều. Họ sử dụng thông tin hiện có, tính đến yếu tố không chắc chắn và cập nhật khi có dữ liệu mới. Bạn vẫn có thể lên kế hoạch cho buổi chiều của mình dựa trên dự báo đó, miễn là bạn không nhầm lẫn dự báo với một sự đảm bảo.
Việc lập kế hoạch Sprint hoạt động theo nguyên tắc tương tự. Một Đội Scrum có danh sách công việc tồn đọng của sản phẩm, ước tính sức chứa sẵn có và mục tiêu muốn đạt được. Tuy nhiên, một số chi tiết công việc chỉ trở nên rõ ràng khi sprint tiến triển. Lập kế hoạch trước từng giờ sẽ không để lại nhiều không gian cho những phát hiện đó, trong khi bắt đầu mà không có hướng đi chung sẽ khiến việc quyết định điều gì đáng được chú ý trở nên khó khăn hơn.
Mục đích là thống nhất về một kết quả có giá trị và dự báo khối lượng công việc mà nhóm có thể hoàn thành để đạt được mục tiêu đó. Từ đó, nhóm có thể điều chỉnh kế hoạch của mình khi có thêm thông tin mà vẫn không làm mất đi tầm nhìn về mục tiêu sprint.
Hướng dẫn này bao gồm việc chuẩn bị danh sách công việc tồn đọng, chương trình làm việc có thời gian cụ thể, các tính toán sức chứa thực tế và một ví dụ minh họa chi tiết về cách điều chỉnh kế hoạch trong suốt sprint.
TL;DR Kế hoạch Sprint tập hợp Đội Scrum lại với nhau để thống nhất về một mục tiêu Sprint, lựa chọn các mục trong backlog và thiết lập kế hoạch triển khai ban đầu:
- Chuẩn bị bằng cách tinh chỉnh các công việc sắp tới và kiểm tra tình trạng sẵn sàng, các công việc chưa hoàn thành, các mối phụ thuộc và Định nghĩa Đã xong
- Dự báo phải dựa trên sức chứa thực tế và hiệu suất trong quá khứ, tính đến các yếu tố như nghỉ phép, cuộc họp, nhiệm vụ hỗ trợ và sự không chắc chắn, đồng thời không tính trùng lặp các cam kết.
- Kết thúc phiên lập kế hoạch với danh sách công việc còn lại của sprint được chia sẻ, sau đó điều chỉnh kế hoạch triển khai khi nhóm thu thập thêm thông tin, đồng thời đảm bảo mục tiêu của sprint vẫn được duy trì.
- Hãy sử dụng lịch trình mẫu kéo dài hai giờ và ví dụ minh họa về năng lực làm việc đã được tính toán sẵn làm điểm khởi đầu, sau đó điều chỉnh chúng cho phù hợp với nhu cầu của nhóm.
Lập kế hoạch sprint là gì?
Cuộc họp lập kế hoạch Sprint là một sự kiện trong quy trình Scrum được tổ chức vào đầu mỗi sprint để thống nhất về những gì nhóm muốn đạt được và cách tiếp cận công việc. Sự kiện này tập hợp toàn bộ Nhóm Scrum, bao gồm Chủ sở hữu Sản phẩm (Product Owner), Người điều phối Scrum (Scrum Master) và các nhà phát triển. Các chuyên gia khác, chẳng hạn như kỹ sư bảo mật hoặc trưởng nhóm phụ trách khách hàng, cũng có thể tham gia khi ý kiến đóng góp của họ giúp nhóm đưa ra quyết định sáng suốt.
Theo Hướng dẫn Scrum, mỗi phiên lập kế hoạch cần tạo ra ba thành quả: một mục tiêu Sprint giải thích giá trị của công việc, một lựa chọn các mục trong danh sách công việc sản phẩm (product backlog) hỗ trợ mục tiêu đó, và một kế hoạch ban đầu để triển khai chúng. Ba yếu tố này cùng nhau tạo thành danh sách công việc Sprint, mà các nhà phát triển sẽ tiếp tục cập nhật trong suốt quá trình diễn ra Sprint.
Hướng dẫn Scrum quy định thời gian tối đa là tám giờ cho một sprint kéo dài một tháng, và các sprint ngắn hơn thường cần ít thời gian hơn. Với danh sách công việc (backlog) đã được tinh chỉnh kỹ lưỡng, chương trình làm việc dưới đây có thể hoàn thành trong hai giờ.
Nếu bạn chưa quen với một số thuật ngữ này, từ điển thuật ngữ của chúng tôi sẽ giải thích những khái niệm cơ bản về Agile và Scrum.
Ba câu hỏi mà cuộc họp kế hoạch sprint trả lời
Mỗi phiên lập kế hoạch sprint đều xoay quanh ba câu hỏi:
- Tại sao sprint này lại có giá trị?
- Chúng ta có thể đạt được những gì?
- Và chúng ta sẽ hoàn thành công việc như thế nào?
Hướng dẫn Scrum tổ chức quá trình lập kế hoạch xoay quanh các câu hỏi này, bắt đầu từ giá trị mà bạn muốn mang lại. Khi mọi người đã thống nhất về điều đó, việc quyết định những mục trong danh sách công việc (backlog) nào cần được ưu tiên và khối lượng công việc mà nhóm của bạn có thể đảm nhận một cách hợp lý sẽ trở nên dễ dàng hơn.
| Câu hỏi | Ai là người dẫn dắt | Kết quả | Ví dụ về sprint 2 tuần |
|---|---|---|---|
| Tại sao sprint này lại có giá trị? | Chủ sở hữu sản phẩm đề xuất; toàn bộ nhóm đồng ý | Mục tiêu Sprint | Khách hàng mới có thể thanh toán bằng thẻ tại bước thanh toán mà không cần liên hệ với bộ phận bán hàng |
| Trong sprint này có thể hoàn thành những việc gì? | Các nhà phát triển sẽ lựa chọn, cùng với Chủ sở hữu sản phẩm | Các mục trong danh sách công việc tồn đọng đã được lựa chọn | Biểu mẫu thanh toán bằng thẻ, tích hợp nhà cung cấp dịch vụ thanh toán, email xác nhận thanh toán, xử lý lỗi |
| Công việc đã chọn sẽ được hoàn thành như thế nào? | Các nhà phát triển | Kế hoạch công việc ban đầu | Các mục được chia thành các công việc, thường mỗi công việc mất một ngày hoặc ít hơn, với trách nhiệm ban đầu đã được thống nhất |
Tại sao sprint lại quan trọng
Mục tiêu sprint giúp nhóm có định hướng để phấn đấu và giúp các bên liên quan hiểu rõ những gì sẽ xảy ra. Hãy thống nhất mục tiêu này với Đội Scrum của bạn trước khi phiên lập kế hoạch kết thúc.
Hãy mô tả một kết quả mà mọi người có thể nhận ra, chẳng hạn như “Người dùng dùng thử có thể mời đồng đội”, thay vì một mục tiêu khối lượng công việc như “Hoàn thành 34 điểm câu chuyện”. Nếu một vấn đề bất ngờ phát sinh, mục tiêu này sẽ giúp nhóm quyết định nên điều chỉnh công việc nào trong khi vẫn duy trì được kết quả mong muốn.
Những gì nhóm có thể hoàn thành trong sprint này
Sau khi đã thống nhất về mục tiêu, đã đến lúc xác định những gì nhóm có thể thực sự hoàn thành.
Các nhà phát triển lựa chọn các mục trong danh sách công việc (backlog) thông qua thảo luận với Chủ sở hữu Sản phẩm (Product Owner), đồng thời xem xét sức chứa sẵn có, hiệu suất trong quá khứ và Định nghĩa Hoàn thành (Definition of Done). Đây cũng là thời điểm thích hợp để rà soát các cam kết hiện có có thể ảnh hưởng đến lượng thời gian mà nhóm có dành cho công việc trong sprint.
Nhiều nhóm sử dụng điểm câu chuyện (story points) để so sánh mức độ nỗ lực và độ phức tạp tương đối của các mục trong danh sách công việc tồn đọng. Thang điểm Fibonacci có thể giúp cấu trúc các cuộc thảo luận này, đặc biệt khi mức độ nỗ lực cần thiết chưa rõ ràng.
Nếu bạn mới làm quen với điểm câu chuyện (story points) hoặc muốn tìm hiểu cách chúng được áp dụng trong thực tế, đây là hướng dẫn chi tiết về quy trình ước lượng.
Cách nhóm sẽ thực hiện công việc
Sau khi các mục trong danh sách công việc tồn đọng (backlog) đã được lựa chọn, các nhà phát triển sẽ lên kế hoạch để biến chúng thành một phần sản phẩm hoàn thiện (product increment) đáp ứng Định nghĩa Hoàn thành (Definition of Done). Hướng dẫn Scrum (Scrum Guide) khuyến nghị chia các mục lớn thành các phần công việc nhỏ hơn, thường có kích thước sao cho có thể hoàn thành trong một ngày hoặc ít hơn.
Điều đó không có nghĩa là bạn phải lên kế hoạch chi tiết từng giờ trong sprint. Những ngày đầu tiên có thể cần một kế hoạch chi tiết hơn, trong khi các công việc sau này có thể linh hoạt điều chỉnh khi có thông tin mới xuất hiện. Việc coi các ước tính ban đầu là cam kết cứng nhắc có thể gây áp lực cho nhóm phải đạt được các số ban đầu, ngay cả khi phạm vi công việc thay đổi giữa chừng.
Như Dave West, Giám đốc điều hành (CEO) của Scrum.org, giải thích:
Một dự báo được sử dụng để bảo vệ một mốc thời gian sẽ chính xác dẫn đến những hành vi làm xói mòn lòng tin, như thổi phồng ước tính, che giấu rủi ro hoặc âm thầm định nghĩa lại khái niệm “đã xong” để đạt được số đó.
Một dự báo được sử dụng để bảo vệ một mốc thời gian sẽ chính xác dẫn đến những hành vi làm xói mòn lòng tin, như thổi phồng ước tính, che giấu rủi ro hoặc âm thầm định nghĩa lại khái niệm “đã xong” để đạt được số đó.
Sự khác biệt giữa kế hoạch sprint và tinh chỉnh danh sách công việc (Backlog Refinement) là gì?
Việc tinh chỉnh danh sách công việc (backlog refinement) giúp nhóm của bạn hiểu rõ hơn về các công việc sắp tới trước khi quyết định những công việc nào sẽ được đưa vào sprint tiếp theo. Cuộc họp lập kế hoạch sprint dựa trên sự chuẩn bị đó để thống nhất mục tiêu, lựa chọn các mục trong danh sách công việc và thiết lập kế hoạch triển khai ban đầu.
Hai hoạt động này phục vụ các mục đích khác nhau trong Scrum:
| Chiều | Tinh chỉnh danh sách công việc tồn đọng | Kế hoạch sprint |
|---|---|---|
| Mục đích | Làm rõ, chia nhỏ và ước tính các mục công việc tồn đọng sắp tới | Đặt mục tiêu sprint, lựa chọn công việc và lập kế hoạch triển khai |
| Thời gian | Diễn ra liên tục trong suốt sprint | Vào đầu mỗi sprint |
| Trạng thái Scrum | Một hoạt động liên tục | Một sự kiện Scrum chính thức với khung thời gian cố định |
| Ai tham gia | Chủ sở hữu sản phẩm và các nhà phát triển liên quan | Toàn bộ Nhóm Scrum |
| Kết quả | Các mục trong danh sách công việc tồn đọng với thông tin chi tiết, ước tính và phạm vi rõ ràng hơn | Danh sách công việc của sprint: mục tiêu sprint, các mục đã lựa chọn và kế hoạch triển khai |
Hãy đảm bảo các mục trong danh sách công việc tồn đọng sắp tới được tinh chỉnh đủ chi tiết để nhóm có những lựa chọn rõ ràng trong buổi lập kế hoạch sprint. Mức độ chuẩn bị cần thiết phụ thuộc vào tốc độ thay đổi của các ưu tiên và mức độ không chắc chắn còn lại. Các mục nằm ở phía sau trong danh sách công việc tồn đọng có thể giữ mức độ chi tiết thấp hơn cho đến khi chúng tiến gần hơn đến giai đoạn lựa chọn.
Xem thêm: Để biết thêm hướng dẫn, hãy tham khảo các bài viết của chúng tôi về việc sắp xếp backlog và cách duy trì backlog sản phẩm được tổ chức và sắp xếp theo thứ tự ưu tiên.
Cách chuẩn bị cho cuộc họp lập kế hoạch sprint
Vài ngày trước đó, hãy kiểm tra xem danh sách công việc tồn đọng (backlog) đã được sắp xếp hợp lý chưa và mọi người đã có đầy đủ thông tin cần thiết để đưa ra quyết định hay chưa. Nhờ vậy, bạn có thể dành thời gian trong phiên họp để thảo luận về những gì cần triển khai và cách tiếp cận mà không cần phải giải quyết từng yêu cầu từ đầu.
Dưới đây là danh sách kiểm tra cần thực hiện trước khi bắt đầu sprint tiếp theo:
- Soạn thảo mục tiêu sprint: Yêu cầu Product Owner đề xuất một kết quả hỗ trợ cho Mục tiêu Sản phẩm tổng thể, từ đó cung cấp cho nhóm những điểm cụ thể để thảo luận
- Xem xét danh sách công việc cần thực hiện (Product Backlog): Đảm bảo các mục có mức độ ưu tiên cao nhất đã được sắp xếp thứ tự, hiểu rõ và ước tính thời gian thực hiện khi cần thiết
- Kiểm tra tình trạng sẵn sàng của nhóm: Yêu cầu các nhà phát triển chia sẻ kế hoạch nghỉ phép, lịch luân phiên hỗ trợ và các cam kết khác có thể ảnh hưởng đến năng lực làm việc của họ
- Xem lại các công việc chưa hoàn thành: Rà soát các công việc còn dang dở từ sprint trước và bất kỳ cải tiến nào được xác định trong buổi tổng kết
- Xác định các mối phụ thuộc: Đánh dấu các công việc cần có sự đóng góp hoặc phê duyệt từ nhóm khác và làm rõ ai sẽ chịu trách nhiệm điều phối
- Xem lại Định nghĩa về Hoàn thành: Đảm bảo mọi người đều hiểu rõ các tiêu chuẩn chất lượng mà mỗi mục trong danh sách công việc tồn đọng đã hoàn thành phải đáp ứng
Nếu bạn sắp xếp thời gian cho phiên tổng kết sprint và phiên lập kế hoạch sprint diễn ra gần nhau, hãy dành đủ thời gian để thảo luận kỹ lưỡng trong cả hai phiên. Các kết quả từ phiên tổng kết nên được phản ánh vào kế hoạch cho sprint tiếp theo, vì vậy hãy đảm bảo rằng cả hai cuộc họp đều không bị gấp gáp.
Chương trình kế hoạch cho buổi lập kế hoạch sprint: Ví dụ có thời gian cụ thể cho một sprint 2 tuần
Đối với một sprint kéo dài hai tuần, hãy bắt đầu bằng một phiên kế hoạch kéo dài hai giờ, đặc biệt khi danh sách công việc tồn đọng (backlog) đã được tinh chỉnh. Hãy dự trù thêm thời gian nếu công việc liên quan đến các mối phụ thuộc phức tạp hoặc nhiều quyết định cần thảo luận.
Bạn có thể điều chỉnh lịch trình mẫu này cho phù hợp với nhu cầu của nhóm mình.
| Thời gian | Mục chương trình làm việc | Ai là người dẫn dắt | Kết quả dự kiến |
|---|---|---|---|
| 0:00–0:10 | Xem lại kết quả của sprint trước, các công việc chưa hoàn thành và các hành động rút kinh nghiệm | Scrum Master điều phối | Sự chia sẻ về những vấn đề cần chú ý |
| 0:10–0:30 | Thảo luận về mục tiêu sprint do Product Owner đề xuất và thống nhất về kết quả mong muốn | Toàn bộ nhóm Scrum | Một bản dự thảo mục tiêu sprint mà mọi người đều hiểu rõ |
| 0:30–0:45 | Xác nhận sự sẵn sàng của nhóm và rà soát các hạn chế về sức chứa | Các nhà phát triển | Một bức tranh thực tế về sức chứa sẵn có |
| 0:45–1:15 | Lựa chọn các mục trong danh sách công việc tồn đọng hỗ trợ mục tiêu | Các nhà phát triển, cùng với Chủ sở hữu sản phẩm | Một lựa chọn các công việc mà nhóm tin rằng mình có thể hoàn thành |
| 1:15–1:45 | Phân tích chi tiết các mục đã lựa chọn và thảo luận về phương pháp triển khai | Các nhà phát triển | Kế hoạch ban đầu để hoàn thành công việc |
| 1:45–2:00 | Xem xét các mối phụ thuộc, đánh giá mức độ tự tin và hoàn thiện mục tiêu sprint | Toàn bộ nhóm Scrum | Một mục tiêu sprint đã được thống nhất và danh sách công việc sprint (sprint backlog) sẵn sàng để nhóm sử dụng |
Trước khi kết thúc, bạn có thể thực hiện một bài kiểm tra mức độ tự tin nhanh chóng như Fist of Five, trong đó mọi người đánh giá mức độ tự tin của mình vào kế hoạch từ 0 đến 5 ngón tay. Nếu ai đó cho điểm thấp, hãy hỏi nguyên nhân gây ra lo ngại. Điều này có thể tiết lộ một sự phụ thuộc chưa được giải quyết, một dự báo quá tham vọng hoặc một yêu cầu cần được thảo luận thêm.
Mục đích là để nêu ra các vấn đề cần quan tâm khi vẫn còn thời gian để điều chỉnh kế hoạch.
Cách tổ chức cuộc họp lập kế hoạch sprint trong 6 bước
Sau khi đã chuẩn bị danh sách công việc (backlog) và xác nhận danh sách người tham dự, hãy bắt đầu phiên lập kế hoạch. Mục tiêu ở đây là giúp nhóm biến các ưu tiên và năng lực sẵn có của mình thành một kế hoạch mà họ tự tin có thể triển khai thành công.
Bước 1: Rà soát công việc trước đó và thống nhất mục tiêu sprint
Bắt đầu bằng việc xem xét nhanh những gì đã hoàn thành, những gì còn dang dở và liệu có bất kỳ hành động nào từ phiên tổng kết nào cần ảnh hưởng đến sprint tiếp theo hay không. Tập trung vào bất kỳ yếu tố nào có thể thay đổi ưu tiên hoặc phương pháp làm việc của nhóm, thay vì xem lại toàn bộ phiên đánh giá sprint.
Sau đó, hãy để Chủ sở hữu Sản phẩm (Product Owner) giới thiệu mục tiêu Sprint được đề xuất và giải thích cách mục tiêu này hỗ trợ cho Mục tiêu Sản phẩm tổng thể. Tạo điều kiện cho các nhà phát triển đặt câu hỏi về phạm vi công việc, nêu ra các yếu tố phụ thuộc và đề xuất các điều chỉnh.
Ví dụ, nếu mục tiêu là cho phép khách hàng hoàn tất quy trình thanh toán mà không cần liên hệ với bộ phận bán hàng, hãy thống nhất xem quy trình thanh toán thành công trông như thế nào. Quy trình đó có bao gồm xác nhận thanh toán và xử lý lỗi không? Việc gửi hóa đơn tự động hóa có phải là yếu tố thiết yếu cho phiên bản phát hành đầu tiên không?
Các cuộc thảo luận này giúp bạn xác định một kết quả mà nhóm có thể hướng tới. Cách diễn đạt có thể thay đổi khi các mục trong danh sách công việc tồn đọng được lựa chọn, nhưng mọi người cần thống nhất về mục tiêu cuối cùng trước khi kết thúc phiên lập kế hoạch.
Bước 2: Tính toán sức chứa của nhóm
Trước khi lựa chọn công việc, hãy xác định thời gian mà các nhà phát triển của bạn có thể thực sự dành cho sprint.
Bắt đầu bằng số ngày làm việc và thời gian sẵn sàng dự kiến của từng thành viên. Sau đó, tính đến các kỳ nghỉ đã lên kế hoạch, các sự kiện Scrum, trách nhiệm hỗ trợ và các cam kết khác đã biết. Nếu một nhà phát triển dành một nửa tuần để xử lý các vấn đề sản xuất, những giờ làm việc đó đã được cam kết và không thể sử dụng cho công việc Sprint đã lên kế hoạch.
Một phép tính đơn giản là: Sức chứa sẵn có = Tổng số giờ công việc − Các cam kết đã biết
Ví dụ, một nhà phát triển có 80 giờ công việc trong hai tuần có thể có 8 giờ nghỉ phép, 10 giờ cuộc họp và 12 giờ làm nhiệm vụ hỗ trợ. Như vậy còn lại 50 giờ trước khi tính đến bất kỳ yếu tố không chắc chắn nào khác.
So sánh con số này với hiệu suất trước đây của nhóm. Velocity cho thấy khối lượng công việc mà nhóm đã hoàn thành trong các sprint trước, trong khi năng lực phản ánh thời gian có sẵn cho sprint này.
Mẹo chuyên nghiệp: Nếu bạn sử dụng đơn vị giờ để lập kế hoạch sức chứa, hãy tách biệt chúng với điểm câu chuyện. Hai đơn vị này đo lường những thứ khác nhau và không có tỷ lệ chuyển đổi chung nào giữa chúng.
Bước 3: Đánh giá lại các công việc chưa hoàn thành từ sprint trước
Các mục công việc tồn đọng chưa hoàn thành cần được xem xét lại trước khi bạn thêm chúng vào sprint mới. Một mục từng được coi là quan trọng cách đây hai tuần có thể đã thay đổi về mức độ ưu tiên, hoặc nhóm có thể đã học được điều gì đó ảnh hưởng đến khối lượng công việc còn lại.
Xem xét từng mục cùng với Chủ sở hữu sản phẩm và cân nhắc:
- Mức độ phù hợp: Công việc này có còn hỗ trợ mục tiêu sprint đã đề xuất hay một ưu tiên quan trọng khác của sản phẩm không?
- Nỗ lực còn lại: Hiện tại còn bao nhiêu công việc cần hoàn thành sau khi một phần của mục đã được hoàn thành?
- Các yếu tố phụ thuộc: Có điều gì đang cản trở nhóm về tiến độ không?
- Mức độ ưu tiên: Mục này có nên được ưu tiên hơn các mục trong danh sách công việc chưa hoàn thành đã được tinh chỉnh gần đây không?
Đối với các công việc vẫn thuộc phạm vi của sprint, hãy sử dụng lượng nỗ lực còn lại để đánh giá xem chúng sẽ cần bao nhiêu sức chứa. Một mục công việc chưa hoàn thành có thể yêu cầu ít nỗ lực hơn so với ước tính ban đầu, nhưng nó vẫn được coi là chưa hoàn thành cho đến khi đáp ứng được Định nghĩa Đã xong.
Bước 4: Lựa chọn các mục trong danh sách công việc tồn đọng (backlog) hỗ trợ mục tiêu
Khi đã nắm rõ năng lực và các công việc còn tồn đọng, các nhà phát triển có thể lựa chọn các mục trong danh sách công việc sản phẩm mà họ tin rằng mình có thể hoàn thành.
Bắt đầu với các mục hỗ trợ trực tiếp cho mục tiêu sprint. Thảo luận về các tiêu chí chấp nhận, các phụ thuộc kỹ thuật và bất kỳ yếu tố không chắc chắn nào có thể ảnh hưởng đến việc triển khai. Nếu một mục quá lớn hoặc không rõ ràng, hãy xem xét chia nhỏ nó thành các mục nhỏ hơn có thể mang lại giá trị trong phạm vi sprint.
Bạn cũng có thể dành thời gian cho việc bảo trì hoặc các ưu tiên khác của sản phẩm, nhưng hãy kiểm tra xem việc thực hiện các công việc đó có thể gây rủi ro cho mục tiêu chính hay không.
Bạn nên dự trữ bao nhiêu sức chứa?
Việc lập kế hoạch chỉ sử dụng 80% năng lực sẵn có có thể là một điểm khởi đầu hợp lý cho các nhóm thường xuyên phải xử lý các công việc hỗ trợ bất ngờ, nhưng Scrum không quy định một tỷ lệ phần trăm cố định.
Nếu nhóm của bạn thường xuyên gặp phải các sự gián đoạn, bạn có thể dành ra 10–20% sức chứa đã điều chỉnh và so sánh mức dự phòng này với nhu cầu thực tế trong các sprint trước đó. Một nhóm có công việc ổn định và ít sự gián đoạn có thể cần ít hơn. Ngược lại, một nhóm hỗ trợ dịch vụ đang hoạt động với các sự cố thường xuyên có thể cần nhiều hơn.
Tránh tính trùng lặp cùng một cam kết. Nếu số giờ hỗ trợ đã được trừ đi trong Bước 2, thì khoảng đệm bổ sung nên dùng để đối phó với những yếu tố không chắc chắn ngoài khối lượng công việc đã biết. Sử dụng năng lực làm việc kết quả làm cơ sở để thảo luận, chứ không phải là mục tiêu phải đạt được.
Lưu ý: Một sprint còn dư sức chứa không nhất thiết là do lập kế hoạch chưa đủ. Nếu bạn đã lựa chọn đủ công việc để đạt được mục tiêu sprint, việc lấp đầy số giờ còn lại bằng các công việc không liên quan có thể tạo ra các ưu tiên cạnh tranh. Đôi khi, một dự báo khiêm tốn hơn sẽ thực tế hơn, đặc biệt khi công việc được lựa chọn mang tính không chắc chắn cao.
Bước 5: Phân chia công việc và kiểm tra các mối phụ thuộc
Sau khi đã lựa chọn các mục trong danh sách công việc tồn đọng, các nhà phát triển có thể lên kế hoạch cụ thể về cách triển khai chúng. Quá trình này có thể bao gồm việc chia các mục lớn thành các công việc phát triển, kiểm thử, tích hợp và đánh giá.
Hãy xem xét kỹ thứ tự thực hiện công việc. Nếu giao diện thanh toán phụ thuộc vào việc tích hợp với nhà cung cấp dịch vụ thanh toán, nhóm cần nắm rõ thời điểm tích hợp đó phải hoàn tất. Nếu một nhóm khác phải phê duyệt thay đổi về bảo mật, hãy làm rõ cách thức và thời điểm quyết định đó sẽ được đưa ra.
Lập kế hoạch chi tiết hơn cho các công việc trước mắt, đồng thời để ngỏ các công việc sau này để thảo luận thêm. Hướng dẫn Scrum đề xuất chia nhỏ các mục đã lựa chọn thành các công việc nhỏ hơn, thường có kích thước trong vòng một ngày hoặc ít hơn, nhưng các nhà phát triển sẽ quyết định cách tổ chức và phân phối công việc.
Kiểm tra xem kế hoạch có tính đến “Định nghĩa Hoàn thành” hay không, bao gồm các công việc kiểm thử và tích hợp thiết yếu. Nếu có sự phụ thuộc nào có thể cản trở việc triển khai, hãy xem xét lại các mục đã lựa chọn hoặc điều chỉnh phương pháp triển khai trước khi hoàn thiện kế hoạch.
Bước 6: Hoàn thiện và chia sẻ danh sách công việc của sprint
Ghi lại mục tiêu sprint, các mục trong danh sách công việc sản phẩm đã được lựa chọn và kế hoạch triển khai ban đầu vào một nơi mà cả nhóm có thể truy cập và cập nhật. Tất cả những thông tin này sẽ giúp làm rõ những gì nhóm hướng tới và công việc nào cần được ưu tiên thực hiện tiếp theo.
Trước khi kết thúc cuộc họp, hãy xác nhận rằng mọi người đã thống nhất về mục tiêu và tạo cơ hội cho mọi người nêu ra bất kỳ lo ngại nào còn lại liên quan đến dự báo. Nếu có vấn đề quan trọng về sự phụ thuộc hoặc sức chứa chưa được giải quyết, hãy thảo luận về những điều cần thay đổi trước khi nhóm bắt đầu.
Trong suốt sprint, cuộc họp Daily Scrum tạo cơ hội cho các nhà phát triển kiểm tra tiến độ hướng tới mục tiêu và điều chỉnh danh sách công việc còn lại của sprint. Biểu đồ burndown hoặc burnup có thể giúp thể hiện sự thay đổi trong tiến độ, trong khi các công việc cơ bản cung cấp thông tin chi tiết. Nếu có thông tin mới ảnh hưởng đến phạm vi công việc đã lựa chọn, các nhà phát triển có thể thảo luận về các điều chỉnh với Product Owner mà không làm ảnh hưởng đến mục tiêu của sprint.
Ví dụ về cuộc họp kế hoạch sprint: Một nhóm gồm 6 nhà phát triển
Hãy cùng xem các quyết định này được áp dụng như thế nào trong thực tế.
Hãy tưởng tượng bạn đang lập kế hoạch cho một sprint kéo dài hai tuần cho một sản phẩm thanh toán B2B. Nhóm của bạn có sáu nhà phát triển và mục tiêu sprint được đề xuất là: “Khách hàng mới có thể thanh toán bằng thẻ tại bước thanh toán mà không cần liên hệ với bộ phận bán hàng.”
Trước khi lựa chọn các mục trong danh sách công việc tồn đọng, bạn cần biết nhóm có bao nhiêu thời gian sẵn có. Trong ví dụ này, giả sử mỗi nhà phát triển có sáu giờ tiềm năng để tập trung vào công việc dự án mỗi ngày, trước khi trừ đi các sự kiện Scrum đã có kế hoạch và các cam kết khác.
Dưới đây là cách tính toán sức chứa trong 10 ngày làm việc:
| Tính toán sức chứa | Số giờ |
|---|---|
| Sức chứa cơ bản: 6 nhà phát triển × 10 ngày × 6 giờ | 360 |
| Kế hoạch nghỉ phép: 1 nhà phát triển vắng mặt trong 2 ngày | −12 |
| Trực ca: 1 nhà phát triển với mức sẵn sàng 50% | −30 |
| Các sự kiện Scrum: 8 giờ cho mỗi nhà phát triển | −48 |
| Sức chứa sẵn có | 270 |
| Dự trữ 20% cho các công việc phát sinh | −54 |
| Sức chứa sẵn có cho công việc đã có kế hoạch | 216 |
Hiện tại, bạn có 216 giờ dành cho công việc đã có kế hoạch sau khi dành ra một khoản dự phòng minh họa là 20%. Trên thực tế, bạn sẽ xác định mức dự phòng này dựa trên mức độ mà các công việc không dự kiến đã làm gián đoạn các sprint trước đó.
Chọn các công việc hỗ trợ mục tiêu của sprint
Sau khi đã xác định được sức chứa, các nhà phát triển sẽ cùng Product Owner xem xét các mục trong danh sách công việc tồn đọng liên quan đến việc kiểm tra.
Dưới đây là một lựa chọn minh họa dựa trên các ước tính nỗ lực ban đầu ở cấp độ công việc của họ:
| Mục trong danh sách công việc tồn đọng | Dự kiến nỗ lực |
|---|---|
| Xây dựng biểu mẫu thanh toán bằng thẻ | 48 giờ |
| Tích hợp nhà cung cấp dịch vụ thanh toán | 88 giờ |
| Xử lý các trường hợp thanh toán thất bại và lỗi xác thực | 50 giờ |
| Thêm xác nhận thanh toán và gửi biên lai | 24 giờ |
| Tổng khối lượng công việc theo kế hoạch | 210 giờ |
Các ước tính này để lại 6 giờ trong hạn mức công việc đã lập kế hoạch, cộng với 54 giờ dự phòng cho các công việc bất ngờ. Nhóm cũng có một cải tiến về bảng điều khiển báo cáo trong danh sách công việc sản phẩm. Mặc dù điều này rất có giá trị, nhưng nó không đóng góp trực tiếp vào mục tiêu hoàn thành. Chủ sở hữu sản phẩm và các nhà phát triển đồng ý để lại việc này cho một sprint trong tương lai.
Điều chỉnh kế hoạch khi có sự thay đổi
Vào ngày thứ sáu, nhà cung cấp dịch vụ thanh toán đưa ra một thay đổi về API khiến một phần của quá trình tích hợp bị gián đoạn. Các nhà phát triển tiến hành điều tra và ước tính khối lượng công việc bổ sung cần thiết.
Thay vì tiếp tục theo thứ tự công việc ban đầu, họ thảo luận về tác động của vấn đề với Chủ sở hữu Sản phẩm. Nếu việc khắc phục nằm trong phạm vi năng lực còn lại, họ có thể ưu tiên thực hiện và hoãn việc thiết kế giao diện hóa đơn tùy chọn hoặc một công việc khác có mức độ ưu tiên thấp hơn. Việc xác nhận thanh toán và các công việc thiết yếu khác vẫn phải đáp ứng Định nghĩa Đã xong.
Nếu việc khắc phục sự cố tốn nhiều thời gian hơn dự kiến, họ sẽ cần đánh giá lại phạm vi công việc còn lại và xem liệu mục tiêu của sprint có còn khả thi hay không.
Nhóm có thể kết thúc với số lượng mục trong danh sách công việc tồn đọng đã hoàn thành ít hơn so với dự báo ban đầu. Tuy nhiên, nếu khách hàng có thể hoàn tất quy trình thanh toán như dự kiến và công việc đáp ứng Định nghĩa Hoàn thành, thì mục tiêu của sprint đã được đạt được.
Ví dụ về mục tiêu sprint cho các nhóm khác
Bạn có thể áp dụng phương pháp lập kế hoạch tương tự cho các công việc ngoài lĩnh vực phát triển phần mềm, mặc dù Scrum bản thân là một khung làm việc cụ thể với các trách nhiệm và sự kiện được định nghĩa rõ ràng.
Ví dụ, một nhóm tiếp thị có thể đặt mục tiêu như “Xuất bản trang đích của hội thảo trực tuyến và cho phép khách truy cập đăng ký mà không cần sự hỗ trợ thủ công.” Một nhóm vận hành có thể đặt mục tiêu “Đảm bảo mọi nhân viên trong đợt tuyển dụng tiếp theo đều có thiết bị và quyền truy cập hệ thống cần thiết ngay từ ngày đầu tiên.”
Cả hai mục tiêu đều mô tả các kết quả có thể định hướng cho các quyết định của nhóm trong suốt sprint. Các mục trong backlog và kế hoạch triển khai có thể khác nhau, nhưng nhóm vẫn cần xem xét sức chứa của mình và thống nhất về tiêu chí đánh giá một lần triển khai thành công.
Những sai lầm thường gặp trong kế hoạch sprint và cách khắc phục
Quá trình lập kế hoạch sprint có thể gặp vấn đề khi các nhóm sử dụng điểm câu chuyện (story points) để đánh giá hiệu suất cá nhân, đưa các mục backlog chưa rõ ràng vào cuộc họp, phân công công việc quá cứng nhắc hoặc bỏ qua các yêu cầu kiểm thử và các yếu tố phụ thuộc bên ngoài.
Một vài điều chỉnh nhỏ có thể giúp bạn phát hiện những vấn đề này trước khi chúng ảnh hưởng đến quá trình triển khai.
| Sai lầm | Tại sao điều này lại gây ra vấn đề | Cách khắc phục |
| Sử dụng điểm câu chuyện để đánh giá hiệu suất cá nhân | Việc so sánh các nhà phát triển dựa trên số điểm đã hoàn thành có thể khuyến khích việc đưa ra các ước tính quá cao hoặc né tránh các công việc phức tạp. | Hãy tập trung các điểm câu chuyện vào việc dự báo ở cấp độ nhóm. Rà soát công việc đã hoàn thành qua nhiều sprint và thảo luận về những thay đổi trong ước tính trong giai đoạn tinh chỉnh. Đánh giá hiệu suất cá nhân thông qua chất lượng mã nguồn, sự hợp tác và kết quả đạt được. |
| Đưa các mục backlog chưa rõ ràng vào quá trình lập kế hoạch | Việc thiếu tiêu chí chấp nhận hoặc các câu hỏi kỹ thuật chưa được giải đáp sẽ biến buổi kế hoạch thành một cuộc thảo luận về việc sẽ xây dựng gì, khiến thời gian dành cho việc lập kế hoạch triển khai bị thu hẹp. | Giải quyết các thắc mắc trong quá trình tinh chỉnh danh sách công việc tồn đọng để các nhà phát triển có thể đưa ra dự báo hợp lý. Nếu vẫn còn sự không chắc chắn, hãy xem xét một phần công việc nhỏ hơn và dễ hiểu hơn. Hãy hướng tới sự rõ ràng đủ để đưa ra quyết định, thay vì các thông số kỹ thuật hoàn hảo. |
| Phân công từng công việc cho một người trước khi bắt đầu công việc | Việc phân công công việc cố định sẽ khiến việc thích ứng trở nên khó khăn hơn khi ưu tiên thay đổi hoặc khi một nhà phát triển hoàn thành sớm trong khi người khác cần hỗ trợ. | Hãy để các nhà phát triển tự tổ chức công việc. Thống nhất về các trách nhiệm trước mắt và ý kiến đóng góp của các chuyên gia, sau đó cho phép các thành viên trong nhóm tiếp nhận, làm việc theo cặp hoặc phân bổ lại các công việc trong suốt sprint. Đảm bảo công việc luôn được hiển thị rõ ràng cho toàn bộ nhóm. |
| Không giải quyết các yếu tố phụ thuộc bên ngoài | Việc thiếu thông tin đăng nhập API, đánh giá bảo mật hoặc các sản phẩm đầu ra của nhóm khác có thể khiến nhóm phải chờ đợi những công việc nằm ngoài tầm kiểm soát của mình. | Trước khi hoàn thiện danh sách công việc của sprint, hãy xác định các đầu vào cần thiết, người sẽ chịu trách nhiệm điều phối và thời hạn dự kiến. Nếu một yếu tố phụ thuộc quan trọng vẫn chưa rõ ràng, hãy xem xét một mục thay thế hoặc phạm vi công việc nhỏ hơn mà nhóm có thể hoàn thành độc lập. |
Nếu cùng một vấn đề liên tục xuất hiện trong nhiều sprint, hãy đưa vấn đề đó vào phiên tổng kết sprint và thống nhất về một thay đổi mà bạn có thể thử nghiệm trong sprint tiếp theo. Các mẫu phiên tổng kết sprint này có thể giúp bạn ghi lại các quan sát và các hành động tiếp theo.
Vào cuối sprint, hãy sử dụng cuộc họp đánh giá sprint để kiểm tra phần công việc đã hoàn thành cùng các bên liên quan và thảo luận về những công việc tiếp theo mà nhóm nên thực hiện.
Cách tổ chức cuộc họp lập kế hoạch sprint trong ClickUp
Việc lập kế hoạch sprint sẽ tốn nhiều nỗ lực hơn khi các công việc, ước tính sức chứa và các quyết định lập kế hoạch bị phân tán trên nhiều công cụ khác nhau. ClickUp tập hợp tất cả thông tin đó lại với nhau, giúp nhóm có thể xem xét công việc cùng với sức chứa và điều chỉnh lại các quyết định lập kế hoạch khi kế hoạch có thay đổi.
Hãy bắt đầu với Mẫu Lập kế hoạch Sprint Agile của ClickUp. Các chế độ xem danh sách công việc tồn đọng, trạng thái phát triển và nguồn lực trong mẫu này sẽ giúp bạn xem xét các công việc sắp tới và chuẩn bị cho cuộc thảo luận lập kế hoạch.
Dưới đây là cách xử lý các quyết định quan trọng:
- Giúp việc đánh giá công việc sắp tới trở nên dễ dàng hơn: Lưu trữ các yêu cầu, tiêu chí chấp nhận, mức độ ưu tiên và các mối phụ thuộc trong danh sách công việc tồn đọng (backlog) của nhiệm vụ ClickUp. Những chi tiết này giúp các nhà phát triển thảo luận về phạm vi công việc và ước tính nỗ lực cần thiết trước khi lựa chọn công việc. Thêm các công việc đã chọn vào sprint sau khi nhóm đã thống nhất về kế hoạch
- Đặt khung thời gian lập kế hoạch nhất quán: Cấu hình thời lượng sprint và ngày bắt đầu trong ClickUp Sprints. Sử dụng Điểm Sprint hoặc Ức lượng Thời gian để đánh giá khối lượng công việc và giúp nhóm xác định được lượng công việc mà họ có thể đảm nhận
- Kiểm tra xem công việc có phù hợp không: So sánh công việc được phân công với năng lực của từng người trong Chế độ xem Khối lượng công việc (Workload View) của ClickUp. Xem xét các trường hợp khối lượng công việc không đồng đều và thảo luận về bất kỳ thay đổi nào trước khi hoàn tất dự báo
- Đảm bảo chương trình làm việc và các quyết định gắn liền với công việc: Sử dụng ClickUp Docs để lập chương trình làm việc có thời gian cụ thể, đề xuất mục tiêu sprint và các liên kết đến các công việc liên quan. Ghi lại các quyết định về phạm vi công việc và các câu hỏi chưa được giải quyết trong phiên họp để nhóm có thể xem xét lại khi tiến độ công việc tiến triển
- Ghi lại nội dung thảo luận trong phiên lập kế hoạch: ClickUp AI Notetaker có thể ghi lại các cuộc họp trên Zoom, Google Meet, Microsoft Teams hoặc SyncUps và lưu tóm tắt, các quyết định quan trọng cùng các công việc cần thực hiện vào một tài liệu Doc. Xem lại các ghi chú, sau đó cập nhật các công việc trong sprint với các bước tiếp theo đã thống nhất
- Sử dụng dữ liệu tiến độ để định hướng các cuộc thảo luận: Thêm thẻ Sprint Burndown hoặc Burnup vào Bảng điều khiển ClickUp để xem xét công việc đã hoàn thành và khối lượng công việc còn lại. Khi tiến độ khác với kế hoạch, hãy rà soát các công việc liên quan để xác định các nguyên nhân gây chậm trễ hoặc thay đổi phạm vi công việc cần được chú ý
Trước phiên kế hoạch tiếp theo, hãy hỏi Brain²: “Có những mối phụ thuộc chưa được giải quyết nào xuất hiện trong phiên lập kế hoạch sprint gần nhất của chúng ta?” Brain có thể trích xuất bối cảnh từ các ghi chú cuộc họp đã được lưu lại. Kiểm tra các chi tiết đó so với các công việc hiện tại trước khi sử dụng chúng để làm cơ sở cho dự báo tiếp theo.
Giá dịch vụ ClickUp
Phù hợp nhất với: Các nhóm Scrum quản lý nhiều sprint, các mối phụ thuộc chung và khối lượng công việc thay đổi, cần quản lý backlog, lập kế hoạch năng lực và báo cáo tiến độ trong cùng một không gian làm việc. Phương pháp này cũng rất phù hợp với các nhóm phối hợp công việc sprint với các dự án sản phẩm hoặc kinh doanh có phạm vi rộng hơn.
Bỏ qua nếu: Nhóm của bạn chỉ cần một bảng Scrum cơ bản với danh sách công việc tồn đọng (backlog) nhỏ và báo cáo tối thiểu. Tính linh hoạt của ClickUp đi kèm với các quyết định thiết lập liên quan đến cài đặt sprint, chế độ xem và trường dữ liệu. Một số tính năng báo cáo và tự động hóa sprint nâng cao cũng yêu cầu các kế hoạch cao cấp hơn, điều này có thể không cần thiết đối với một quy trình làm việc đơn giản.
Bạn nên lập kế hoạch bao nhiêu trước khi bắt đầu một sprint?
Một phiên lập kế hoạch sprint nên giúp nhóm có đủ sự rõ ràng để bắt đầu công việc.
Chương trình làm việc có thời gian cụ thể và ví dụ về sức chứa làm việc nêu trên là điểm khởi đầu. Hãy điều chỉnh chúng cho phù hợp với khối lượng công việc của nhóm, sau đó so sánh dự báo với công việc đã hoàn thành và các sự cố gián đoạn để cải thiện kế hoạch cho lần tiếp theo.
Trong ClickUp, bạn có thể liên kết các ghi chú lập kế hoạch với các công việc sprint và cập nhật danh sách công việc sprint khi công việc thay đổi. Nhóm có thể tham khảo lại kế hoạch đã thống nhất khi quyết định điều chỉnh những gì.
Các câu hỏi thường gặp về cuộc họp kế hoạch sprint
Sự khác biệt giữa kế hoạch sprint và kế hoạch phát hành là gì?
Kế hoạch Sprint tập trung vào những gì nhóm của bạn dự định hoàn thành trong một Sprint và cách thức triển khai công việc đó. Kế hoạch phát hành xem xét trong một khung thời gian dài hơn, chẳng hạn như những tính năng nào có thể được triển khai qua nhiều Sprint và khi nào người dùng có thể nhận được chúng. Dự báo phát hành có thể thay đổi khi nhóm thu thập thêm thông tin, trong khi mục tiêu của mỗi Sprint sẽ định hướng công việc trong chính Sprint đó.
Bạn có cần “Định nghĩa về sự sẵn sàng” cho cuộc họp lập kế hoạch sprint không?
Không. Scrum không yêu cầu một “Định nghĩa Sẵn sàng” chính thức. Một số nhóm sử dụng định nghĩa này để thiết lập những kỳ vọng chung cho các mục trong danh sách công việc (backlog) trước khi lựa chọn, chẳng hạn như yêu cầu rõ ràng, phạm vi công việc có thể quản lý được và các mối phụ thuộc đã biết. Hãy giữ cho các tiêu chí này đủ linh hoạt để hỗ trợ thảo luận mà không cản trở nhóm tinh chỉnh các mục khi cần thiết.
Liệu một sprint có thể bị hủy bỏ sau khi lập kế hoạch không?
Đúng vậy. Chỉ Chủ sở hữu sản phẩm (Product Owner) mới có thể hủy bỏ một sprint, và việc hủy bỏ là một lựa chọn khi mục tiêu của sprint trở nên lỗi thời, có thể do các ưu tiên kinh doanh hoặc điều kiện thị trường đã thay đổi đáng kể. Một công việc khó khăn hoặc một ước tính không chính xác đơn thuần không nhất thiết là lý do chính đáng để hủy bỏ.
Sự khác biệt giữa Sprint và Agile là gì?
Agile là một phương pháp tiếp cận rộng hơn trong việc quản lý công việc dựa trên các giá trị và nguyên tắc của Tuyên ngôn Agile. Một sprint là một kỳ cố định kéo dài tối đa một tháng trong khuôn khổ Scrum, trong đó nhóm làm việc hướng tới mục tiêu của sprint và tạo ra một phần sản phẩm có thể sử dụng được. Bạn có thể tuân theo các nguyên tắc Agile mà không cần sử dụng sprint. Ví dụ, Kanban hỗ trợ luồng công việc liên tục mà không yêu cầu các chu kỳ có độ dài cố định.
Một sprint có thể có nhiều mục tiêu sprint không?
Scrum định nghĩa mục tiêu Sprint là mục tiêu duy nhất của Sprint. Bạn có thể lựa chọn các mục trong backlog hỗ trợ các ưu tiên khác, miễn là chúng không làm ảnh hưởng đến mục tiêu đó. Nếu nhóm của bạn thường xuyên cần nhiều mục tiêu không liên quan đến nhau, hãy thảo luận xem công việc đó có hỗ trợ một kết quả chung rộng hơn hay không, hoặc liệu bạn có cần giải quyết các ưu tiên xung đột trước khi lập kế hoạch hay không.
Có nên ước tính lỗi bằng điểm câu chuyện trong buổi kế hoạch sprint không?
Điểm câu chuyện (Story points) là tùy chọn trong Scrum, kể cả đối với các lỗi. Các nhóm ước tính lỗi nên thống nhất về thời điểm và lý do thực hiện việc này. Các lỗi đã biết có thể được đánh giá trong quá trình lập kế hoạch, trong khi các lỗi được phát hiện trong quá trình phát triển có thể nằm trong phạm vi công việc đã cần thiết để đáp ứng Định nghĩa Hoàn thành. Tránh tính trùng lặp cùng một nỗ lực hai lần.