Trong bài viết về Story Point, chúng ta đã đề cập về Velocity với nhận định là tổng số story point được hoàn thành trong mỗi Sprint. Velocity được xem là một thước đo tốc độ hoàn thành công việc trong lịch sử mà các nhóm sử dụng để hiểu năng lực của họ dựa trên hiệu suất trong quá khứ. Vậy velocity là gì, sử dụng như thế nào và hỗ trợ các nhóm Scrum ra sao, chúng ta sẽ cùng tìm hiểu kỹ trong bài viết bên dưới.
Velocity (vận tốc, tốc độ) là một phương pháp cực kỳ đơn giản để đo lường chính xác tốc độ mà Development Team hoàn thành công việc một cách nhất quán. Velocity là cơ sở cho thấy lượng Product Backlog trung bình được chuyển thành phần gia tăng tính năng sản phẩm trong Sprint, được Development team theo dõi để sử dụng. Do đó, để tính toán velocity của nhóm, chúng ta chỉ cần cộng các ước lượng của các tính năng, user stories, yêu cầu hoặc backlog items được hoàn thành trong một lần lặp, 1 Sprint.
Tìm hiểu velocity là gì trong Agile
Nói cách khác, velocity còn được định nghĩa là “thước đo năng lực làm việc mỗi lần lặp của một nhóm”. Giúp đo lường mức độ công việc mà Scrum team có thể thực hiện trong các lần lặp trong tương lai, dựa trên số lượng công việc mà họ đã hoàn thành trong các lần lặp trước. Điều này giúp nhóm theo dõi và truyền đạt những gì họ đã hoàn thành, dự đoán những gì họ sẽ có thể hoàn thành trong tương lai và dự báo khi nào dự án (hoặc release) có khả năng được hoàn thành.
Story points được sử dụng để ước lượng độ lớn, độ phức tạp cho công việc triển khai một user story nhất định. Tổng số story points được hoàn thành trong mỗi Sprint được theo dõi như velocity của dự án. Vậy mối liên quan giữa velocity với story points là gì?
- Các nhóm thường sử dụng “velocity” làm thước đo năng suất để cho người dùng/khách hàng biết chính xác tốc độ của Scrum team.
- Nếu ước lượng về story points của nhóm được duy trì trong suốt dự án thì sẽ rất hợp lý khi sử dụng story points để đại diện cho “velocity”.
- Nếu sự nhất quán không chỉ trong nhóm, mà còn giữa các nhóm với nhau, thậm chí ở cấp toàn công ty thì velocity sẽ không chỉ đo lường năng suất mà còn so sánh tình trạng của từng nhóm.
- Nếu giá trị của story points ổn định, thì nó có thể được sử dụng làm tài liệu tham khảo cho việc lập kế hoạch release, giúp nhóm có thể đánh giá các tiến độ khả thi sau đó.
Trong Scrum, velocity giúp chúng ta hiểu nhóm của mình sẽ mất bao lâu để hoàn thành Product backlog. Tuy nhiên, thông thường phải mất vài Sprint để nhóm tìm ra velocity ổn định hơn. Để ước tính velocity chính xác hơn cho nhóm, có thể tích lũy kinh nghiệm dựa trên thành tích trong quá khứ của nhóm. Nó sẽ là dự báo chính xác hơn về số lượng story point mà một nhóm có thể thực hiện trong Sprint. Đối với mục đích dự báo, nên sử dụng giá trị trung bình của ba hoặc bốn velocity của sprint gần nhất.
Giả sử một nhóm Scrum mới đã lên kế hoạch hoàn thành 39 story points trong sprint đầu tiên của họ, cuối cùng họ chỉ có thể hoàn thành 38 story points. Vậy velocity trong trường hợp này là 38 như trong hình dưới đây:
Những cách ước tính chính xác velocity là gì
Nói chung, velocity thường thay đổi nhiều nhất trong vài lần lặp đầu tiên và sau đó sẽ bắt đầu ổn định. Điều này là do nhóm phải làm quen với việc làm cùng nhau, làm quen với các công cụ của dự án và tương tác thoải mái với các bên liên quan của dự án. Khi sản phẩm lớn hơn, sẽ có nhiều thứ để bảo trì, tái cấu trúc và có thể hỗ trợ nếu các phiên bản đầu tiên của sản phẩm đã được triển khai. Nhìn chung, độ phức tạp của dự án càng ngày càng tăng, và velocity có xu hướng ổn định.
Nếu một công việc hoặc user story mới chỉ hoàn thành một phần thì không được tính vào velocity của nhóm. Chỉ user stories được đánh dấu là ‘Hoàn thành’ mới được tính, ngay cả khi chỉ còn một chút việc để làm cũng không được tính.
Dựa trên chỉ một Sprint đầu tiên, velocity chưa phải là một số liệu đáng tin cậy để đưa ra dự đoán chính xác, nhưng nó giúp nhóm hiểu được họ có thể cam kết hoàn thành bao nhiêu công việc trong một Sprint, cũng như theo dõi tiến độ của họ trong Sprint đó.
Bây giờ, nhóm mới tiếp tục phát triển tới Sprint 4 và story points của họ trong sprint đầu tiên là 38, 29 trong sprint thứ hai, 38 trong sprint thứ ba và 39 trong sprint thứ tư. Vậy velocity trung bình ước tính sau 4 lần sprint là 36 như hình dưới đây:
Vào cuối mỗi sprint, chúng ta có thể đếm tổng số story points đã được Product Owner chấp thuận hoàn thành. Nhiều nhóm biểu diễn Velocity của họ trên mỗi sprint dưới dạng biểu đồ cột, để có thể xem họ đã làm như thế nào qua nhiều sprint. Vì thang điểm ước lượng story point của mỗi nhóm là khác nhau, chúng ta không thể sử dụng velocity để so sánh các nhóm với nhau.
Dưới đây là biểu đồ cột về tổng số story points đã hoàn thành trong 4 sprint. Nếu nhóm đang sử dụng cùng một thang điểm để ước tính trong mỗi sprint, nhóm có thể sử dụng con số này để so sánh lượng công việc đã được thực hiện từ sprint này sang sprint. Để tạo biểu đồ này, nhóm chỉ cần cộng số story points trong cột Hoàn thành của Task Board (bảng công việc – sẽ tìm hiểu trong những bài viết sau) ở cuối mỗi Sprint.
Bên dưới đây là biểu đồ cột về tổng số story points mà nhóm đã đưa vào sprint có màu xám và story points mà nhóm thực sự hoàn thành có màu đen. Để tạo biểu đồ này, nhóm chỉ cần cộng story points trong sprint backlog sau buổi lập kế hoạch và đánh dấu đó là con số đã cam kết. Vào cuối sprint, họ theo dõi velocity bằng cách cộng tất cả story points trong cột Hoàn thành của task board.
Dựa trên velocity của các sprint trước đó nhóm có thể hoàn thành các mục tiêu sau:
- Theo dõi mức độ nỗ lực mà nhóm đã báo cáo là hoàn thành cho mỗi sprint.
- Ước tính mức độ nỗ lực mà nhóm có thể xử lý backlog trong các sprint ở tương lai nếu thành phần nhóm và thời gian sprint của bạn không đổi.
Mục đích của theo dõi velocity là cải thiện khả năng của nhóm trong việc ước tính mức độ công việc mà họ có thể hoàn thành một cách nhất quán và đáng tin cậy. Hi vọng qua bài chia sẻ này bạn đọc sẽ hiểu rõ hơn về velocity là gì, cũng như cách sử dụng sao cho hiệu quả, mang lại hiệu suất cao nhất trong công việc để hướng đến mục tiêu chung của nhóm.
Kiến thức tổng hợp bởi Masterskills (PMP, PMI-ATP Instructor)
References: PMI-ACP Exam Prep by Mike Griffiths, Head First Agile, Visual-paradigm
Product Backlog là gì? Có quan hệ như thế nào với WBS
Bản tuyên ngôn Agile – lịch sử hình thành Agile
12 nguyên tắc của Agile
Trong dự án Agile, công việc ước tính có thật sự cần thiết?
Quản lý dự án với Scrum
Scrum of Scrums
User stories – Công cụ lên kế hoạch của Agile
Story points – Công cụ ước lượng của Agile
Velocity là gì – Công cụ đo lường tốc độ hoàn thành công việc của nhóm Agile
Story Map – Lập kế hoạch tổng quát trong Agile
Agile Retrospectives – Nhìn lại và cải tiến hiệu quả công việc dự án
Kanban – phương pháp giúp cải tiến quy trình làm việc của dự án
PDCA – Chu trình cải tiến liên tục
Personas – Công cụ xây dựng hình tượng khách hàng trong Agile
Lean – Tinh gọn hóa quy trình một cách hiệu quả
Hướng Dẫn Scrum – The Scrum Guide
Bóng đá có 3-5-2, Scrum có 3-5-3
Bắt đầu với Scrum từ đâu đây ta?
Một số cách chạy Daily scrum hiệu quả
