Trong thế giới phát triển phần mềm và quản lý sản phẩm đầy tốc độ, sự tập trung thường là nguồn lực khan hiếm nhất. Các đội phải cân bằng giữa nợ kỹ thuật, yêu cầu từ bên liên quan và phản hồi người dùng, thường dẫn đến nỗ lực bị phân mảnh. Scrum cung cấp một khung để quản lý sự phức tạp này, nhưng chính khung đó chỉ hiệu quả bằng mức độ ý định đằng sau nó. Ở trung tâm của ý định này chính là Mục tiêu Sprint.
Một Mục tiêu Sprint không chỉ đơn thuần là một mục trong danh sách công việc hay một chỗ trống cho danh sách nhiệm vụ. Đó là mục tiêu duy nhất định hướng đội Scrum trong suốt đợt Sprint. Khi được xác định rõ ràng, nó sẽ đồng bộ hóa nỗ lực của đội, trao quyền cho việc ra quyết định trong suốt Sprint và cung cấp một định nghĩa đo lường được về thành công. Không có nó, một Sprint có nguy cơ trở thành tập hợp các nhiệm vụ rời rạc thay vì nỗ lực thống nhất hướng đến việc tạo ra giá trị.
Hướng dẫn này khám phá về cơ chế, tầm quan trọng và cách thực hiện việc xác định các mục tiêu rõ ràng cho mỗi đợt Sprint Scrum. Chúng ta sẽ xem xét các vai trò tham gia, những sai lầm phổ biến cần tránh, và cách duy trì sự tập trung khi những điều bất ngờ xảy ra.
🧩 Hiểu rõ Mục tiêu Sprint
Hướng dẫn Scrum định nghĩa Mục tiêu Sprint là một mục tiêu cấp cao cho đợt Sprint. Mục tiêu này được xác định trong buổi lập kế hoạch Sprint và đóng vai trò là mục tiêu cho Danh sách công việc Sprint. Khác với kế hoạch dự án truyền thống nơi mọi nhiệm vụ đều cố định, Sprint cho phép linh hoạt về *cách* thực hiện công việc, miễn là đạt được Mục tiêu.
- Đó là một cam kết: Các nhà phát triển cam kết đạt được Mục tiêu, chứ không chỉ hoàn thành một danh sách cụ thể các nhiệm vụ.
- Nó linh hoạt: Nếu công việc thay đổi, kế hoạch thay đổi, nhưng Mục tiêu vẫn là điều bất biến.
- Nó có giá trị: Mục tiêu cần đại diện cho một bước tiến hướng đến Mục tiêu Sản phẩm, mang lại giá trị cụ thể cho khách hàng.
Hãy xem Mục tiêu Sprint như ngôi sao Bắc cực. Nếu đội bị lạc trong những chi tiết kỹ thuật hay sự mở rộng phạm vi công việc, Mục tiêu sẽ giúp họ định hướng lại. Nó trả lời câu hỏi: “Chúng ta đang cố gắng đạt được điều gì trong hai tuần này?” thay vì “Chúng ta đang đóng bao nhiêu vé công việc?”
🚀 Tại sao Mục tiêu Sprint Thúc đẩy Giá trị
Nhiều đội gặp khó khăn về năng suất không phải vì họ làm việc quá chậm, mà vì họ đang làm quá nhiều việc cùng lúc. Một Mục tiêu Sprint rõ ràng đóng vai trò như một bộ lọc. Nó giúp đội có thể nói “không” với những sự xao nhãng không đóng góp vào mục tiêu. Sự tập trung này mang lại nhiều lợi ích cụ thể:
- Hợp tác được nâng cao: Khi mọi người đều biết mục tiêu, sự hợp tác liên chức năng sẽ tăng lên. Các nhà phát triển, kiểm thử viên và nhà thiết kế hiểu rõ phần việc của mình phù hợp như thế nào vào bức tranh lớn hơn.
- Ra quyết định tốt hơn: Khi ưu tiên thay đổi giữa chừng Sprint, đội có thể đánh giá các lựa chọn dựa trên việc chúng vẫn dẫn đến Mục tiêu hay không. Điều này giảm nhu cầu can thiệp từ quản lý.
- Tinh thần làm việc được cải thiện: Hoàn thành một mục tiêu mạch lạc cảm giác mang lại sự thỏa mãn hơn là gạch bỏ một danh sách nhiệm vụ ngẫu nhiên. Nó mang lại cảm giác thành tựu.
- Tính minh bạch cho các bên liên quan: Các bên liên quan hiểu rõ giá trị họ sẽ nhận được vào cuối Sprint, giảm bớt lo lắng về quá trình phát triển “hộp đen”.
Không có mục tiêu, một Sprint thường được định nghĩa bởi khả năng đội phải tiếp nhận công việc. Có mục tiêu, một Sprint được định nghĩa bởi giá trị mà đội mong muốn tạo ra.
🛠️ Xây dựng Mục tiêu Hiệu quả
Viết một Mục tiêu Sprint là một hoạt động hợp tác. Nó đòi hỏi sự đóng góp từ Chủ sản phẩm (người hiểu rõ giá trị) và các nhà phát triển (người hiểu rõ tính khả thi). Mục tiêu cần đủ cụ thể để mang ý nghĩa, nhưng cũng cần đủ rộng để đội có thể điều chỉnh cách tiếp cận.
1. Tập trung vào Kết quả, Không phải Đầu ra
Tránh các mục tiêu đọc như danh sách nhiệm vụ. Thay vì nói “Xây dựng trang đăng nhập”, hãy đặt nó theo trải nghiệm người dùng hoặc khả năng được kích hoạt.
- Yếu: “Hoàn thành tích hợp API cho bảng điều khiển.”
- Mạnh:“Cho phép người dùng xem dữ liệu thời gian thực trên bảng điều khiển của họ.”
Phiên bản mạnh cho phép đội tự quyết định con đường kỹ thuật tốt nhất (API, dữ liệu giả, bộ nhớ đệm) để đạt được trải nghiệm người dùng, trong khi phiên bản yếu buộc họ phải tuân theo một giải pháp kỹ thuật cụ thể.
2. Giữ cho ngắn gọn
Một Mục tiêu Sprint nên vừa vặn trên một trang trình bày hoặc một miếng giấy dán. Nếu cần đến một đoạn văn để giải thích, thì có khả năng nó quá phức tạp. Sự phức tạp sẽ dẫn đến sự mơ hồ. Sự mơ hồ dẫn đến sự thiếu đồng thuận.
3. Đảm bảo nó có thể kiểm thử được
Vào cuối Sprint, đội phải có thể nhìn vào sản phẩm tăng trưởng và nói: “Vâng, Mục tiêu đã đạt được.” Điều này có nghĩa là Mục tiêu phải gắn liền với một sản phẩm tăng trưởng có thể triển khai được.
4. Phù hợp với Mục tiêu Sản phẩm
Mỗi Mục tiêu Sprint đều phải đóng góp vào Mục tiêu Sản phẩm rộng lớn hơn. Điều này đảm bảo rằng đội không làm việc trong các vùng tách biệt. Nếu một Mục tiêu Sprint không thúc đẩy sản phẩm tiến triển, có thể sẽ tốt hơn nếu đặt câu hỏi về tính cần thiết của nó.
👥 Vai trò và Trách nhiệm
Việc xác định Mục tiêu Sprint không phải là trách nhiệm duy nhất của một vai trò. Đó là sự sở hữu chung đòi hỏi sự tương tác giữa Chủ sở hữu Sản phẩm và Đội Scrum.
| Vai trò | Trách nhiệm trong việc tạo Mục tiêu Sprint | Trách nhiệm trong suốt Sprint |
|---|---|---|
| Chủ sở hữu Sản phẩm | Đề xuất Mục tiêu dựa trên nhu cầu của các bên liên quan và thứ tự ưu tiên trong Danh sách Sản phẩm. Đảm bảo Mục tiêu mang lại giá trị. | Làm rõ Mục tiêu nếu có câu hỏi nảy sinh. Bảo vệ Mục tiêu khỏi sự mở rộng phạm vi không mang lại giá trị. |
| Người Chuyển đổi Scrum | Hỗ trợ cuộc thảo luận để đảm bảo Mục tiêu được hiểu và khả thi. Loại bỏ các trở ngại đối với quá trình lập kế hoạch. | Hướng dẫn đội duy trì sự tập trung. Giúp giải quyết xung đột nếu Mục tiêu bị đe dọa. |
| Người phát triển | Ước lượng tính khả thi. Cung cấp hiểu biết kỹ thuật về cách đạt được Mục tiêu. Cam kết thực hiện Mục tiêu. | Tự quản lý công việc để đạt được Mục tiêu. Điều chỉnh kế hoạch khi cần thiết trong khi vẫn giữ Mục tiêu trong tâm trí. |
Giai đoạn đàm phán
Thời điểm quan trọng nhất đối với Mục tiêu Sprint là trong quá trình lập kế hoạch Sprint. Đây là một cuộc đàm phán, chứ không phải mệnh lệnh. Chủ sở hữu Sản phẩm trình bày “Tại sao” và “Cái gì”. Người phát triển trình bày “Làm thế nào” và “Khi nào”. Nếu người phát triển cảm thấy Mục tiêu là không thể thực hiện được với năng lực hiện tại, họ phải thông báo sớm. Một mục tiêu được đặt ra nhưng ngay lập tức được biết là không thể đạt được sẽ phá vỡ niềm tin.
Được phép điều chỉnh phạm vi Danh sách Công việc Sprint để đảm bảo đạt được Mục tiêu. Nếu một câu chuyện người dùng cụ thể không còn cần thiết để đạt được Mục tiêu, nó có thể bị loại bỏ khỏi Danh sách Công việc Sprint. Sự linh hoạt này là một lợi thế chính của Scrum so với các phương pháp luận Waterfall.
📅 Cấu trúc buổi làm việc lập kế hoạch Sprint
Để đảm bảo Mục tiêu Sprint được xác định hiệu quả, sự kiện lập kế hoạch Sprint nên được tổ chức để ưu tiên thảo luận về mục tiêu này. Nó không nên bắt đầu ngay lập tức bằng việc phân tích nhiệm vụ.
- Xác định Mục tiêu: Chủ sở hữu Sản phẩm trình bày các mục hàng đầu từ Danh sách Sản phẩm.
- Thảo luận về Mục tiêu:Đội thảo luận về giá trị mà những mục này mang lại. Cùng nhau, họ soạn thảo một mục tiêu Sprint tiềm năng.
- Đánh giá tính khả thi:Các Nhà phát triển xem xét năng lực của họ và mức độ phức tạp của công việc. Họ đặt câu hỏi: “Chúng ta có thể đạt được mục tiêu này trong thời gian có sẵn không?”
- Tinh chỉnh Mục tiêu:Nếu phạm vi quá lớn, Người sở hữu Sản phẩm và các Nhà phát triển sẽ đàm phán để giảm xuống một mục tiêu khả thi.
- Cam kết:Khi Mục tiêu rõ ràng và kế hoạch vững chắc, đội sẽ cam kết thực hiện nó.
Dãy bước này đảm bảo rằng Mục tiêu dẫn dắt kế hoạch, chứ không phải kế hoạch dẫn dắt Mục tiêu.
⚠️ Xử lý trở ngại và thay đổi
Ngay cả với kế hoạch tốt nhất, các sự cố vẫn xảy ra. Những lỗi mới được phát hiện, các bên liên quan then chốt thay đổi yêu cầu, hoặc các thách thức kỹ thuật nảy sinh. Làm thế nào để đội xử lý điều này mà không từ bỏ Sprint?
Mục tiêu là điểm tựa
Khi gặp trở ngại, đội nên quay lại Mục tiêu Sprint. Nếu một nhiệm vụ khẩn cấp mới xuất hiện, nó có giúp đạt được Mục tiêu không? Nếu không, nó nên được hoãn sang Sprint tiếp theo. Nếu có, đội cần đánh giá xem Mục tiêu ban đầu vẫn có thể đạt được hay Mục tiêu cần được điều chỉnh.
Sửa đổi Mục tiêu
Một Mục tiêu Sprint có thể thay đổi trong giữa Sprint không? Về mặt kỹ thuật là có thể, nhưng điều này nên xảy ra rất hiếm. Nếu Mục tiêu không còn khả thi do các yếu tố bên ngoài, Người sở hữu Sản phẩm có thể hủy Sprint. Đây là biện pháp cực đoan và nên tránh. Thường thì đội nên điều chỉnh cách tiếp cận trong khuôn khổ Mục tiêu hiện tại.
Ví dụ, nếu Mục tiêu là “Cải thiện tốc độ tải trang”, và đội phát hiện điểm nghẽn cơ sở dữ liệu, họ có thể chuyển từ tối ưu hóa CSS sang lập chỉ mục cơ sở dữ liệu. Mục tiêu vẫn giữ nguyên, nhưng công việc thay đổi.
🔄 Xem xét và rút kinh nghiệm
Mục tiêu Sprint được đánh giá trong hai buổi lễ quan trọng: Buổi xem xét Sprint và Buổi rút kinh nghiệm Sprint.
Buổi xem xét Sprint
Mục đích chính của buổi xem xét là kiểm tra phần tăng trưởng. Đội trình bày công việc theo Mục tiêu Sprint. Các bên liên quan đưa ra phản hồi. Nếu Mục tiêu được đạt, phần tăng trưởng có thể được phát hành. Nếu Mục tiêu không đạt, đội phải giải thích lý do và thảo luận cách khắc phục khoảng trống trong Sprint tiếp theo.
Buổi rút kinh nghiệm Sprint
Ở đây, đội phản tư về quy trình. Mục tiêu có giúp đội tập trung không? Mục tiêu có thực tế không? Đội có hiểu rõ nó không? Nếu Mục tiêu mơ hồ, đội có thể đồng ý dành nhiều thời gian hơn để tinh chỉnh mục tiêu trong buổi lập kế hoạch tiếp theo. Nếu Mục tiêu quá tham vọng, họ có thể điều chỉnh ước tính tốc độ của mình.
❌ Những sai lầm phổ biến cần tránh
Các đội thường gặp khó khăn với Mục tiêu Sprint do những thói quen lặp lại. Nhận diện những mẫu hình này giúp tự điều chỉnh.
- Quá nhiều Mục tiêu: Một số đội cố gắng có một mục tiêu cho mỗi tính năng. Một Sprint chỉ nên có một Mục tiêu rõ ràng. Nhiều mục tiêu sẽ làm giảm sự tập trung.
- Quá mang tính kỹ thuật: “Tái cấu trúc mô-đun thanh toán” không phải là một Mục tiêu tốt. Đó là một hoạt động kỹ thuật. Mục tiêu nên là “Cho phép người dùng thanh toán qua thẻ tín dụng một cách an toàn”. Điều này tập trung vào giá trị kinh doanh.
- Bỏ qua đội ngũ: Nếu Người sở hữu Sản phẩm áp đặt Mục tiêu mà không tham khảo các Nhà phát triển, đội có thể thiếu sự sở hữu. Sự sở hữu là yếu tố thiết yếu để cam kết.
- Mục tiêu cố định:Xem mục tiêu như một hợp đồng cứng nhắc. Mục tiêu nên định hướng cho đội nhóm, chứ không nên bóp nghẹt họ. Nếu thị trường thay đổi, mục tiêu cần được xem xét lại.
- Bỏ quên phần tăng trưởng:Một mục tiêu mà không có phần tăng trưởng thì chỉ là một ước mơ. Đảm bảo công việc mang lại một phần sản phẩm có thể sử dụng được.
📝 Các tình huống ví dụ
Hãy cùng xem cách các mục tiêu Sprint thay đổi trong các bối cảnh khác nhau để minh họa nguyên tắc này.
Tình huống 1: Ra mắt tính năng mới
- Bối cảnh:Đội nhóm đang làm việc trên một ứng dụng di động.
- Mục tiêu xấu:“Tạo các màn hình cho quy trình thanh toán.”
- Mục tiêu tốt:“Cho phép người dùng hoàn tất mua hàng trong ba lần chạm.”
Mục tiêu tốt cho phép đội nhóm quyết định sử dụng hộp thoại, trang mới hay thanh bottom sheet, miễn là tuân thủ giới hạn ba lần chạm.
Tình huống 2: Giảm nợ kỹ thuật
- Bối cảnh:Hệ thống đang gặp thời gian tải chậm.
- Mục tiêu xấu:“Cập nhật lược đồ cơ sở dữ liệu.”
- Mục tiêu tốt:“Giảm thời gian phản hồi trung bình của API đi 50%.”
Mục tiêu tốt tập trung vào kết quả hiệu suất. Đội nhóm có thể chọn cách làm như lưu dữ liệu tạm, tối ưu truy vấn hoặc nâng cấp hạ tầng để đạt được điều đó.
Tình huống 3: Cải thiện trải nghiệm người dùng
- Bối cảnh:Người dùng đang bỏ cuộc tại màn hình đăng ký.
- Mục tiêu xấu:“Sửa lỗi xác thực trên trường email.”
- Mục tiêu tốt:“Tăng tỷ lệ hoàn tất đăng ký bằng cách loại bỏ các trở ngại.”
Mục tiêu tốt khuyến khích tìm hiểu lý do người dùng bỏ cuộc. Có thể là lỗi xác thực, nhưng cũng có thể là yêu cầu mật khẩu gây nhầm lẫn hoặc thiếu tính năng đăng nhập qua mạng xã hội.
✅ Danh sách kiểm tra thực tế cho Mục tiêu Sprint
Trước khi xác nhận mục tiêu Sprint, hãy kiểm tra nó qua danh sách kiểm tra này để đảm bảo tính rõ ràng và khả thi.
- Mục tiêu có ngắn gọn và dễ hiểu không?
- Nó có đại diện cho giá trị đối với khách hàng hoặc người dùng không?
- Nó có thể đạt được trong khung thời gian Sprint không?
- Nó có phù hợp với Mục tiêu Sản phẩm không?
- Chúng ta có thể đo lường được mục tiêu đã đạt được hay chưa vào cuối Sprint không?
- Nó có được đồng thuận bởi Chủ sở hữu Sản phẩm và các Nhà phát triển không?
- Nó có cho phép đội linh hoạt trong cách làm việc không?
- Có phụ thuộc nào có thể làm cản trở mục tiêu không?
🔍 Đo lường Thành công
Làm sao bạn biết mục tiêu Sprint của mình có hoạt động hiệu quả không? Thành công không chỉ đơn thuần là hoàn thành các nhiệm vụ; mà còn là chất lượng hợp tác và giá trị được cung cấp.
Theo dõi các chỉ số sau theo thời gian:
- Tỷ lệ hoàn thành Mục tiêu: Phần trăm Sprint nào thực sự đạt được mục tiêu? Nếu tỷ lệ này luôn thấp, quá trình lập kế hoạch cần được điều chỉnh.
- Thời gian tập trung:Các thành viên đội có dành thời gian cho các nhiệm vụ không liên quan đến mục tiêu không? Ít bị phân tâm cho thấy sự tập trung tốt.
- Mức độ hài lòng của các bên liên quan:Các bên liên quan có cảm thấy họ hiểu được điều gì đang được cung cấp không? Mục tiêu rõ ràng giúp cải thiện giao tiếp.
- Tốc độ của Đội:Tốc độ có ổn định không? Mục tiêu rõ ràng thường dẫn đến việc giao hàng có thể dự đoán hơn.
Hãy nhớ, các chỉ số này dùng để kiểm tra, chứ không phải để phán xét. Chúng là công cụ giúp đội cải thiện, chứ không phải để trừng phạt vì không đạt mục tiêu.
🌟 Kết luận
Xác định các mục tiêu rõ ràng cho mỗi Sprint Scrum là một thực hành nền tảng cho các đội Agile hiệu suất cao. Nó biến Sprint từ một danh sách việc cần làm thành một sứ mệnh. Nó trao quyền cho đội đưa ra quyết định độc lập, giảm thiểu tiếng ồn từ công việc không cần thiết, và đảm bảo mọi nỗ lực đều đóng góp vào Mục tiêu Sản phẩm.
Thực hiện thực hành này đòi hỏi sự kỷ luật. Nó đòi hỏi Chủ sở hữu Sản phẩm phải diễn đạt giá trị một cách rõ ràng, và các Nhà phát triển phải trung thực về năng lực. Nó đòi hỏi Scrum Master phải hỗ trợ cuộc thảo luận mà không định hướng kết quả. Khi làm tốt, mục tiêu Sprint trở thành nhịp đập của Sprint, đập mạnh với mục đích và định hướng.
Bắt đầu nhỏ. Chọn một Sprint và cam kết với một mục tiêu duy nhất, rõ ràng. Đánh giá cảm giác sau khi thực hiện. Nó có giúp ích không? Có làm rõ ưu tiên không? Lặp lại quy trình. Theo thời gian, sự kỷ luật này sẽ trở nên tự nhiên, dẫn đến việc giao hàng có thể dự đoán hơn và kết quả chất lượng cao hơn.
Con đường dẫn đến sự trưởng thành của Agile được lát bằng những ý định rõ ràng. Đảm bảo mục tiêu Sprint của bạn là la bàn dẫn đường cho hành trình của bạn.