Velocity trong Scrum là gì?

Velocity là một cách rất đơn giản nhưng mạnh mẽ để đo lường chính xác tốc độ mà một đội phát triển Scrum tạo ra giá trị kinh doanh theo thời gian. Nó cung cấp một chỉ dấu về lượng trung bình củaProduct Backlog được chuyển đổi thành một phần tăng trưởng sản phẩm trong mỗiSprint bởi mộtđội Scrum, với đội phát triển sử dụng theo dõi. Do đó, để tính toánAgilevelocity của đội, chỉ cần cộng tổng các ước tính về tính năng, truyện người dùng, yêu cầu hoặc các mục trong danh sách công việc đã được hoàn thành thành công trong một lần lặp. Đội nên:

• Dự đoán phạm vi có thể được giao vào một ngày cụ thể.
• Dự đoán ngày mà một số lượng cố định các phạm vi sẽ được giao.
• Hiểu rõ giới hạn của chúng ta khi xác định mức độ phạm vi mà chúng ta cam kết giao trong một Sprint.

Ví dụ về Velocity trong Scrum

Trước khi hoàn thành vài lần lặp, có một số hướng dẫn đơn giản để ước tính velocity ban đầu của đội Scrum, nhưng sau đó, đội của bạn có thể sử dụng các phương pháp ước tính velocity dựa trên lịch sử đã được xác thực choLập kế hoạch Sprint. Dựa trên một loạt các Sprint trước đó, các ước tính velocity thường ổn định và cung cấp nền tảng đáng tin cậy hơn để cải thiện độ chính xác trong lập kế hoạch ngắn hạn và dài hạn cho các dự án Scrum.

Velocity đo lường lượng công việc mà một đội có thể hoàn thành trong một Sprint duy nhất và là một chỉ số quan trọng trong Scrum. Nó được tính bằng cách cộng tổng điểm của tất cả các truyện người dùng đã hoàn thành hoàn toàn tại cuối một Sprint. Các điểm cho các truyện người dùng chưa hoàn thành hoặc chưa hoàn thành đầy đủ không nên được tính vào phép tính.

Bước 1 – Tính velocity của lần lặp đầu tiên (Sprint)

Vào cuối mỗi lần lặp, đội sẽ cộng tổng các ước tính nỗ lực liên quan đến các truyện người dùng đã hoàn thành trong lần lặp đó. Tổng này được gọi là velocity.

Một đội Agile đã bắt đầu một lần lặp, dự định hoàn thành Story A và Story B, ước tính 2 điểm, và Story C, ước tính 3 điểm. Vào cuối lần lặp, Story A và Story B đã hoàn thành 100%, nhưng Story C chỉ hoàn thành 80%. Các đội Agile thường chỉ công nhận hai mức độ hoàn thành: 0% hoặc 100%. Do đó, Story C không được tính vào velocity, và velocity cho lần lặp này là 4 điểm.

Bước 2 – Sử dụng Velocity để ước tính số lần lặp cần thiết

Sau khi hiểu được velocity từ Bước 1, đội có thể tính toán (hoặc điều chỉnh) ước tính thời gian cần để hoàn thành dự án dựa trên ước tính của các truyện người dùng còn lại, với giả định velocity trong các lần lặp tương lai vẫn giữ ở mức tương đối ổn định. Đây thường là một dự đoán chính xác, dù hiếm khi là chính xác tuyệt đối.

Giả sử các truyện người dùng còn lại đại diện cho tổng cộng 40 điểm; dự báo của đội về công việc còn lại là 10 lần lặp.

Mối quan hệ giữa Velocity và Story Points trong Scrum

Story pointsđược sử dụng để đo kích thước và độ phức tạp—nói cách khác, thời gian cần để hoàn thành một nhiệm vụ. Story points là một thước đo tương đối về thời gian cần để hoàn thành một truyện người dùng. Khái niệm này được mượn từ XP. Chúng được dùng để đánh giá độ khó của một truyện, chứ không phải để cam kết về thời gian cần để hoàn thành. Điều này cho phép bạn sử dụng story points bất kể quy mô đội hay loại công việc.

Làm thế nào để liên kết tốc độ với điểm truyện?

1. Các đội thường sử dụng “tốc độ” như một chỉ số năng suất để nói rõ với bên ngoài chính xác đội Scrum đang nhanh đến mức nào.
2. Nếu các ước tính điểm truyện duy trì nhất quán trong suốt dự án, thì việc sử dụng điểm truyện để đại diện cho “tốc độ” là hợp lý.
3. Nếu sự nhất quán được duy trì không chỉ trong từng đội mà còn giữa các đội và thậm chí trên toàn công ty, điều này cho phép đo lường năng suất và so sánh hiệu suất của các đội.
4. Nếu giá trị điểm truyện duy trì ổn định, chúng có thể được sử dụng làm tham chiếu cho lập kế hoạch phát hành. Bạn có thể đánh giá các mốc thời gian khả thi sau này.

Làm thế nào để gán điểm truyện cho một truyện người dùng?

Điểm truyện là một đơn vị đo lường tương đối. Bước đầu tiên mà đội nên thực hiện là xác định một truyện làm chuẩn để có thể ước tính các truyện khác dựa trên tham chiếu này. Theo tài liệu, đội nên xác định truyện đơn giản nhất trong danh sách công việc và gán cho nó 1 điểm truyện, sau đó sử dụng truyện này làm chuẩn để ước tính các truyện khác.

Có hai loại thang đo được sử dụng để tạo ước tính điểm truyện:

• Thang đo tuyến tính (1, 2, 3, 4, 5, 6, 7, …)
• Dãy Fibonacci (0.5, 1, 2, 3, 5, 8, 13, …)

Đây là một ý tưởng tốt để ước tính truyện người dùng đầu tiên mà đội đã quen thuộc và biết mất bao lâu để hoàn thành. Sau đó ước tính truyện người dùng tiếp theo. Nếu đội cho rằng nó mất ít thời gian hơn truyện chuẩn, hãy đặt nó bên trái truyện chuẩn. Sau đó ước tính một truyện người dùng khác. Nếu đội quyết định nó mất ít thời gian hơn truyện chuẩn nhưng nhiều hơn truyện thứ hai, hãy đặt nó giữa truyện chuẩn và truyện thứ hai. Trong ví dụ này, chúng tôi sử dụng dãy Fibonacci để ước tính truyện:

Truyện người dùng Điểm truyện

Làm thế nào để ước tính tốc độ chính xác hơn?

Trong Scrum, tốc độ giúp bạn hiểu được thời gian cần thiết để một đội hoàn thành danh sách công việc sản phẩm. Tuy nhiên, thường mất vài Sprint trước khi đội tìm được tốc độ ổn định hơn. Để ước tính tốc độ của đội chính xác hơn, chúng ta có thể dựa vào các ghi chép theo dõi quá khứ của đội. Điều này sẽ dự đoán chính xác hơn số truyện mà đội có thể hoàn thành trong một Sprint. Để mục đích dự báo, nên sử dụng trung bình của tốc độ ba hoặc bốn Sprint gần nhất.

Giả sử một đội Scrum mới dự định hoàn thành 41 điểm truyện trong Sprint đầu tiên. Họ chỉ hoàn thành được 38 điểm truyện và chuyển 6 điểm truyện sang Sprint tiếp theo. Vì vậy, tốc độ của họ là 38, như được hiển thị bên dưới:

Tốc độ Scrum

Tốc độ trung bình dựa trên theo dõi Sprint trước

Như đã đề cập trước đó, các đội không nên bao gồm bất kỳ công việc chưa hoàn thành hoàn toàn nào vào tốc độ. Chỉ các truyện người dùng được đánh dấu là “Hoàn thành” mới được tính, ngay cả khi chỉ còn một phần nhỏ công việc.

Tốc độ dựa trên một Sprint duy nhất không phải là một chỉ số đáng tin cậy cho mục đích dự báo. (Nhưng nó giúp đội hiểu được họ có thể cam kết bao nhiêu công việc trong một Sprint.) Hãy theo dõi tiến độ của họ qua các Sprint tiếp theo.

Bây giờ, đội mới tiếp tục phát triển từ Sprint 1 đến Sprint 4. Số điểm truyện hoàn thành trong mỗi Sprint là: 38, 29, 38 và 39. Tốc độ trung bình sau bốn Sprint là 36, như được hiển thị bên dưới:

Tốc độ Scrum qua các Sprint

Trung bình này, dựa trên bốn Sprint, hữu ích hơn rất nhiều so với một bức ảnh chụp nhanh sau chỉ một Sprint. Dễ dàng hình dung rằng nếu danh sách công việc đã có các truyện người dùng được ước tính, chúng ta có thể sử dụng tốc độ này để dự báo. Chúng ta có thể dự đoán tốc độ mà đội sẽ hoàn thành toàn bộ công việc. Chúng ta có thể đưa ra những phỏng đoán có cơ sở về những tính năng nào chúng ta có thể cung cấp trong bản phát hành sắp tới.

Biểu đồ tốc độ

Nếu một đội Scrum đã hoàn thành nhiều Sprint, đội có thể sử dụng báo cáo tốc độ để dự báo ngày phát hành và ngày hoàn thành sản phẩm, và lập kế hoạch cho các dự án tương lai tốt hơn. Dựa trên tốc độ từ các Sprint trước được hiển thị trong báo cáo, bạn có thể đạt được những điều sau:

• Theo dõi lượng công việc mà đội của bạn hoàn thành trong mỗi Sprint.
• Nếu thành phần đội và thời lượng Sprint không thay đổi, hãy ước tính lượng công việc danh sách công việc mà đội có thể xử lý trong các Sprint tương lai.

Dựa trên ví dụ trên, biểu đồ tốc độ cho thấy lượng công việc hoàn thành trong mỗi trong 4 Sprint bởi đội Scrum:

Biểu đồ tốc độ Scrum