Story points là một thuật ngữ được sử dụng trong quản trị và tăng trưởng dự án Bất Động Sản để ước đạt độ lớn, độ khó, độ phức tạp cho việc làm tiến hành một user story nhất định, là một thước đo trừu tượng về nỗ lực thiết yếu để triển khai nó. Nói một cách dễ hiểu, story points là một số lượng, một đơn vị chức năng thống kê giám sát cho cả nhóm biết về độ khó của story, khó khăn vất vả hoàn toàn có thể tương quan đến khối lượng việc làm phải làm, mức độ phức tạp của việc làm, rủi ro đáng tiếc hoặc sự không chắc như đinh của việc làm để triển khai khá đầy đủ một khuôn khổ trong Product Backlog [ backlog item ] hoặc bất kể phần việc làm nào khác .
Như đã chia sẻ trong bài viết “User stories – Công cụ lên kế hoạch của Agile”, chúng ta đã đề cập đến User stories – một trong những công cụ được các nhóm Agile sử dụng để lập kế hoạch làm việc và thể hiện các hạng mục cần thực hiện một cách hiệu quả. Tiếp tục với chuỗi những công cụ, kỹ thuật này, chúng ta sẽ cùng tìm hiểu công cụ thứ 2 không kém phần quan trọng đó chính là Story Points.
Theo tự nhiên thì chúng ta khó có thể đưa ra các ước lượng tuyệt đối một cách chính xác, nhưng sẽ dễ dàng và thoải mái hơn trong việc đưa ra các ước lượng bằng cách so sánh với một yếu tố khác [ước lượng tương đối]. Các nhóm Agile cũng vậy, họ đề cao việc ước lượng tương đối. Họ thực hiện hầu hết các ước lượng của họ không phải theo giờ/ngày/tuần, mà bằng một đơn vị tương đối được gọi là “Story points“.
Một lý do khác để sử dụng ước lượng tương đối đó là mỗi thành viên trong nhóm làm việc ở tốc độ khác nhau. Ví dụ một user story có ước lượng là 3 points [3 điểm] có thể được hoàn thành bởi một nhân viên có kinh nghiệm trong một buổi sáng nhưng một nhân viên mới có thể phải mất suốt một ngày mới hoàn thành. Nên story point chỉ tập trung vào ước lượng độ lớn, độ phức tạp của story.
Bạn đang đọc: Story points – Công cụ ước lượng của Agile
Story points là gì ?
Story points là một thuật ngữ được sử dụng trong quản trị và tăng trưởng dự án Bất Động Sản để ước đạt độ lớn, độ khó, độ phức tạp cho việc làm tiến hành một user story nhất định, là một thước đo trừu tượng về nỗ lực thiết yếu để thực thi nó. Nói một cách dễ hiểu, story points là một số lượng, một đơn vị chức năng đo lường và thống kê cho cả nhóm biết về độ khó của story, khó khăn vất vả hoàn toàn có thể tương quan đến khối lượng việc làm phải làm, mức độ phức tạp của việc làm, rủi ro đáng tiếc hoặc sự không chắc như đinh của việc làm để thực thi rất đầy đủ một khuôn khổ trong Product Backlog [ backlog item ] hoặc bất kể phần việc làm nào khác .Ước lượng bằng story points, một loại ước đạt tương đối, thường được thực thi tại cuộc tranh luận về Product Backlog .
Tại sao nên sử dụng story points ?
Khi lập kế hoạch cho một dự án Bất Động Sản Agile, thường thì nhóm sẽ không hề Dự kiến được những tính năng của loại sản phẩm / ứng dụng sẽ thực thi trong bao lâu hoặc ngày hoàn thành xong đúng chuẩn của chúng. Khi ước tính theo giờ / ngày / tuần, bạn phải đưa ra cam kết thời hạn đúng chuẩn. Thay vào đó, khi sử dụng story point, nhóm chỉ định một giá trị điểm [ point ] cho mỗi story dựa trên độ lớn của nó. Đó là nguyên do tại sao hầu hết nhóm Scrum sử dụng story points để lập kế hoạch dự án Bất Động Sản của họ, được cho phép họ so sánh những stories với nhau. Bằng cách tập trung chuyên sâu vào độ phức tạp của những tính năng thay vì thời hạn đúng chuẩn để tăng trưởng chúng, nhóm tham gia lập kế hoạch cùng nhau và đưa ra Dự kiến những tính năng ngày càng tăng nào hoàn toàn có thể được thêm vào ứng dụng / mẫu sản phẩm sau mỗi vòng lặp .[ Xem thêm : Khoá huấn luyện và đào tạo thực hành thực tế Quản lý dự án Bất Động Sản theo quy mô Agile ]
Làm thế nào để ước đạt story point trong Agile ?
Story points rất đơn thuần : nhóm chỉ cần chọn một số ít điểm bộc lộ độ lớn, độ khó, độ phức tạp, khối lượng việc làm thiết yếu cho mỗi story và gán số đó cho mỗi user story trong backlog. Thay vì cố gắng nỗ lực Dự kiến đúng chuẩn sẽ mất bao lâu để thiết kế xây dựng một tính năng, nhóm chỉ định một giá trị điểm cho mỗi story dựa trên độ phức tạp của nó, sau khi đem đi so sánh với những tính năng khác mà nhóm đã thiết kế xây dựng trước đó. Ban đầu, những ước đạt sẽ đổi khác rất nhiều từ story này sang story khác, nhưng sau một thời hạn nhóm đã quen với quy mô mà nhóm sử dụng để ước đạt thì sẽ thuận tiện hơn để tìm ra độ lớn của mỗi story .Khi tất cả chúng ta ước đạt bằng story points, tất cả chúng ta sẽ chỉ định một giá trị điểm cho mỗi mục. Các giá trị thô mà những nhóm sử dụng là không quan trọng. Điều quan trọng là những giá trị đó phải có quan hệ tương đối với nhau. Ví dụ như story được gán điểm 2 nên lớn gấp đôi story được gán điểm 1. Nó cũng phải bằng 2/3 story được ước đạt là 3 story points. Thay vì chỉ định 1, 2 và 3, nhóm đó hoàn toàn có thể chỉ định 100, 200 và 300. Hoặc 1 triệu, 2 triệu và 3 triệu. Điều quan trọng là tỷ suất, không phải là số lượng thực sự về thời hạn [ giờ / ngày / tuần ] .Trong Scrum, để triển khai Sprint Planning hiệu suất cao hơn, Product Owner và Development Team sẽ đưa ra một ước đạt sơ bộ khi triển khai Product Backlog Refinement, trước khi diễn ra Sprint Planning và kiểm tra xem :- Đã sẵn sàng chuẩn bị để thực thi Sprint Plan một cách hiệu suất cao chưa ?- Có đủ thông tin để hoàn thành xong những yếu tố này không ?- User story đã được phân loại hài hòa và hợp lý chưa ?Có rất nhiều cách để ước tính story points trong Agile và tùy theo từng nhóm sẽ thống nhất với nhau về cách tính. Trong hầu hết những trường hợp, story points sử dụng một trong số những thang đo sau để xác lập kích cỡ :
Định cỡ theo T-shirt size [size áo]:
- Scrum teams hoàn toàn có thể dựa vào ý tưởng sáng tạo chia theo T-shirt sizes để xác lập độ lớn, độ phức tạp của một story và gắn giá trị điểm cho từng size. T-shirt sizes là một công cụ ước đạt ở high-level – mức độ tổng quát, được sử dụng để triển khai những ước đạt khởi đầu về những tính năng loại sản phẩm và user story trong quy trình tiến độ khởi đầu của một dự án Bất Động Sản, khi mà chưa có nhiều thông tin chi tiết cụ thể .
- Để phản ánh sự không chắc như đinh tương quan đến những ước đạt đó, đơn vị chức năng ước đạt của tất cả chúng ta sẽ là T-shirt sizes, từ Cực nhỏ – Extra Small [ ES ] đến Cực lớn – Extra Large [ XXL ] .
- Chúng ta sẽ không cố gắng nỗ lực ước đạt size tuyệt đối của từng hạng mục hoặc thậm chí còn kích cỡ lớn hơn hay nhỏ hơn bao nhiêu so với những kích cỡ khác. Tất cả những gì tất cả chúng ta biết sẽ là Extra Small nhỏ hơn Small, nhỏ hơn Medium và liên tục như vậy .
- Ví dụ : nhóm hoàn toàn có thể quyết định hành động sử dụng 1 điểm cho tính năng rất nhỏ [ extra small ], 2 điểm cho tính năng nhỏ [ small ], 3 điểm cho tính năng trung bình [ medium ], 4 điểm cho tính năng lớn [ large ] và 5 điểm cho tính năng rất lớn [ extra large ] .
Extra SmallSmallMediumLargeExtra Large1 điểm2 điểm3 điểm4 điểm5 điểm
- Lũy thừa của 2 :Ngoài ra cũng không ít những nhóm cũng sử dụng dãy số 1, 2, 4, 8, 16 được tạo ra bằng cách lũy thừa của 2 để ước đạt story point .
- Chuỗi Fibonacci cho Story Point :Một khi nhóm quyết định hành động lập kế hoạch theo thang điểm, nhóm cần thống nhất và quyết định hành động sẽ vận dụng theo cách tính điểm nào. Một số nhóm sử dụng chuỗi Fibonacci hoặc 1 số ít biến thể của chuỗi này [ 1, 2, 3, 5, 8, 13, 21 … ] cho story point vì họ nghĩ rằng chuỗi Fibonacci cung ứng cái nhìn thực tiễn hơn về độ lớn của một story, độ lớn của một story này so với một story khác. Miễn là nhóm của bạn sử dụng thang đo một cách đồng nhất, thì đó không phải là yếu tố khi nhóm sử dụng .
Bất cứ điều gì chưa được thực hiện trong Sprint sẽ được chuyển từ Sprint này sang Sprint tiếp theo. Và tổng số story point được hoàn thành trong mỗi Sprint được theo dõi như Velocity [vận tốc – chúng ta sẽ tìm hiểu cụ thể hơn về khái niệm này ở những bài tiếp theo] của dự án. Nếu một nhóm hoàn thành 15 story với tổng số 55 story points trong một Sprint, họ sẽ cho rằng 55 story points này như Sprint velocity và điều này cho nhóm một cái nhìn chung về tốc độ thực hiện công việc của cả nhóm, dự đoán về tổng số story points họ có thể làm trong Sprint tiếp theo.
Theo thời hạn, nhóm ngày càng tốt hơn trong việc gán story points và ngày càng đồng nhất hơn về số story points họ triển khai xong trong mỗi Sprint. Bằng cách đó, nhóm sẽ cảm nhận được họ hoàn toàn có thể làm được bao nhiêu trong Sprint và trấn áp kế hoạch cùng nhau .
Quy trình ước đạt story points
- Bước 1 : Xác định Story cơ sở – Base Story
Để tìm được base story, tất cả chúng ta cần tìm một user story cơ bản, ứng với tiêu chuẩn về định nghĩa hoàn thành xong rõ ràng – DoD, và gán cho nó một story point. Base story được dùng làm cơ sở khi so sánh những story khác .
- Bước 2 : Tạo ma trận để ước đạt
Nhóm sẽ thực thi ước đạt story points như đã trình diễn ở trên [ mục 3 ]. Tiếp theo, nhóm sẽ tạo một ma trận với mỗi hàng cho mỗi story point [ ví dụ ở dưới sử dụng dãy số Fibonacci ] và stories tương quan của chúng. Sau đó, nhóm tập hợp tổng thể stories và mở màn phân loại chúng thành những hàng, so sánh những story với nhau và với những story đã triển khai xong khác, hoặc so với base story. Lưu ý rằng base story đã có trong ma trận này, ở hàng tiên phong với giá trị là một story point .
Story point
Story
1Với tư cách là khách truy vấn vào website, tôi muốn truy vấn trang trình làng để biết thêm về những dịch vụ .2358
Để chỉ định story point cho mỗi story, nhóm có một cuộc họp, nơi tất cả các thành viên của development team sẽ sử dụng Planning Poker để đưa ra con số story point cho một story.
Xem thêm: favorable là gì ? nghĩa của từ favorable trong tiếng việt
Planning Poker là một kỹ thuật ước lượng dựa trên sự đồng thuận, dùng để ước lượng cho Product Backlog. Nó có thể được sử dụng với nhiều đơn vị ước lượng khác nhau, nhưng ở đây chúng ta ví dụ Planning Poker với Story points.
Bước 3: Quy trình ước lượng Planning Poker
- Mỗi thành viên nhận được một bộ thẻ bài .
- Tất cả những thành viên chọn Backlog items để ước đạt, luận bàn những tính năng và đặt câu hỏi .
- Khi một tính năng đã được đàm đạo khá đầy đủ, mỗi người tự đưa ra số lượng ước đạt cho riêng mình – bảo vệ bí hiểm, và chọn một thẻ bài để đại diện thay mặt cho ước đạt của mình .
- Khi toàn bộ đã có cho mình ước đạt của story, họ sẽ bật mý thẻ bài của họ cùng một lúc. Nếu toàn bộ những ước đạt đều khớp, cả nhóm sẽ chọn Backlog item khác và lặp lại tiến trình tựa như. Khi những ước đạt khác nhau quá nhiều, tổng thể sẽ tranh luận về yếu tố này để đi đến thống nhất .
Vào cuối Planning Poker, nhóm sẽ điền hàng loạt hiệu quả có được vào ma trận. Các user story của nhóm được chia thành những hàng theo story point tương ứng thiết yếu để thực thi chúng. Có thể có nhiều story trong một hàng .
Story point
Story
1Với tư cách là người truy vấn vào website, tôi muốn truy vấn trang trình làng để biết thêm về những dịch vụ .Với tư cách là người truy vấn vào website, tôi muốn hoàn toàn có thể đặt lại mật khẩu của mình trong trường hợp tôi quên mật khẩu .2Với tư cách là người dùng đã đăng nhập, tôi muốn hoàn toàn có thể xem lịch sử vẻ vang thanh toán giao dịch của mình trên trang setup .Với tư cách là người truy vấn website, tôi muốn hoàn toàn có thể gửi phản hồi hoặc báo cáo giải trình sự cố bằng cách sử dụng biểu mẫu liên hệ .3Với tư cách là người truy vấn website, tôi muốn đăng nhập / ĐK bằng email / mật khẩu của mình .Với tư cách là người dùng đã đăng nhập, tôi muốn thêm nhận xét vào nội dung trên website .5Với tư cách là người truy vấn vào website, tôi muốn sử dụng biểu mẫu tìm kiếm với những bộ lọc để tìm kiếm nội dung đơn cử .Với tư cách là người truy vấn vào website, tôi muốn xem thông tin cụ thể về nội dung .8Với tư cách là người dùng đã đăng nhập, tôi muốn hoàn toàn có thể thêm nội dung trên tiêu đề website, miêu tả, nội dung phương tiện đi lại [ hình ảnh, video, âm thanh ], vị trí địa lý .Với tư cách là người dùng đã đăng nhập, tôi muốn hoàn toàn có thể tiếp xúc qua tin nhắn với những người dùng khác .
Tại thời gian này, nhóm đã có ước đạt về độ lớn dựa theo story points, câu hỏi đặt ra là làm thế nào để nhóm hoàn toàn có thể quy đổi những story points này thành ước đạt thời hạn trong thực tiễn [ giờ / ngày / tuần ]. Rất tiếc, nhóm không hề thực thi việc này cho đến khi hoàn thành xong Sprint tiên phong. Trong khi Sprint tiên phong đang diễn ra, nhóm hoàn toàn có thể theo dõi Velocity của nhóm. Ngay sau khi Sprint kết thúc, sẽ biết nhóm hoàn toàn có thể triển khai xong bao nhiêu story points cho mỗi Sprint. Nhóm sử dụng những số lượng này để dự báo năng lực của mình cho những Sprint tiếp theo .Khi ước đạt được toàn bộ những việc làm trong backlog dựa vào story point, Scrum hoàn toàn có thể hiểu nhóm sẽ cần bao nhiêu Sprint để triển khai xong dự án Bất Động Sản. Và sau cuối, nhóm hoàn toàn có thể quy đổi những đơn vị chức năng trừu tượng này thành những mốc thời hạn thực .
Những lỗi thường mắc phải khi sử dụng Story Point
- Chuyển đổi story point sang giờ: Bằng cách chuyển đổi story point sang giờ/ngày/tuần, nhóm sẽ bắt đầu làm việc và phải mạo hiểm đưa ra cam kết thời gian hoàn thành chính xác. Giả sử story point được ước lượng có khoanh vùng phạm vi thời hạn từ 10 – 20 giờ, nhưng khi ước đạt theo giờ, nhóm phải đưa ra một số lượng đúng chuẩn như 15 giờ, từ đó sẽ dẫn đến sự rơi lệch, dẫn đến khó đạt được cam kết hơn khi bạn thao tác theo giờ đúng mực .
- Đưa ra story point trung bình :Trong Planning Poker, một nửa thành viên trong nhóm ước đạt một product backlog item là 3 story point và nửa còn lại ước tính 5 story point. Nhóm xử lý bằng cách đặt 4 story point làm số lượng ước đạt. Nhóm không nên làm điều này vì nhóm đang thỏa hiệp với sự cung ứng sai về độ đúng mực. Tốt nhất là nhóm nên có một cuộc luận bàn để hiểu rõ hơn thay vì lấy giá trị trung bình .
- Điều chỉnh ước lượng Story Point của những user story trong Sprint :Khi nhóm bắt đầu giải quyết một vấn đề, nhóm không nên điều chỉnh ước lượng story point ngay cả khi ước đạt của họ không đúng chuẩn. Việc ước đạt nhiều lúc bị rơi lệch là điều thông thường, nên nhóm không nên kiểm soát và điều chỉnh mà hãy lưu lại thông tin này, để làm cơ sở cho việc xác lập story point ở những lần sau đúng mực hơn .
- Ước lượng Story point cho những yếu tố chưa hoàn thành xong một lần nữa :Khi chuyển một product backlog item chưa hoàn thành sang Sprint tiếp theo, không cần thiết phải ước lượng lại. Ước lượng hoàn toàn có thể không đúng chuẩn, nhưng đó không phải là yếu tố. Nhờ Sprint Planning, nhóm sẽ biết toàn bộ những trách nhiệm [ task ] thiết yếu để hoàn thành xong user story. Ước lượng của những trách nhiệm này là theo giờ. Vì vậy, Sprint tiếp theo, nhóm sẽ biết cần bao nhiêu thời hạn để hoàn thành xong product backlog item này .
- Điều chỉnh ước lượng Story Point dựa vào người làm :User story có thể là 3 story point đối với thành viên nhiều kinh nghiệm, nhưng 8 story point đối với thành viên mới. Đây là cách làm không đúng. Chúng ta không nên điều chỉnh story point vì một người cụ thể sẽ thực hiện công việc. Vì story point chỉ dựa vào độ lớn, độ phức tạp, độ khó của user story.
- Tuân theo ý kiến của các chuyên gia trong nhóm: Khi thực hiện Planning Poker, có rủi ro là nhóm sẽ tuân theo ý kiến của các chuyên gia mà không phải là sự kết hợp từ phía mỗi thành viên. Nhóm thường giải quyết công việc bằng cách để chuyên gia trình bày chi tiết về công việc. Sau đó, để phần còn lại của nhóm ước lượng mà không cần những chuyên viên. Chúng ta cần nhớ rằng ước đạt story point là sự nỗ lực của cả nhóm không phải của riêng bất kể thành viên nào .
- Không thảo luận lại các vấn đề không chính xác về việc ước lượng story point trong Sprint Retrospective :Thỉnh thoảng, nhóm xác định được những vấn đề rõ ràng là ước lượng story points đã trọn vẹn xô lệch. Điều quan trọng là phải bàn luận về những yếu tố này và cố gắng nỗ lực học hỏi, cải tổ, để những ước đạt trong tương lai đúng chuẩn hơn .
Tổng kết
Khái niệm về story point đơn thuần nhưng khó vận dụng. Hầu hết mọi nhóm Scrum đều sử dụng chúng, nhưng chúng không phải là một phần những công cụ cốt lõi của Scrum. Bởi vì điều này, mọi người có quan điểm khác nhau về cách bạn nên sử dụng chúng. Ban đầu khi sử dụng story points hoàn toàn có thể sẽ làm nhóm ước đạt rơi lệch, nhưng sau thời hạn hiểu và trấn áp kế hoạch cùng nhau, đồng nhất hơn về số điểm họ phân phối trong mỗi Sprint giúp nhóm thuần thục hơn và làm cho việc làm ước đạt trở nên nhẹ nhàng, thuận tiện hơn rất nhiều .
Kiến thức tổng hợp bởi Trainer Nguyễn Hải Hà [PMP®, PMI-ATP Instructor]
References: PMI-ACP Exam Prep, Head First Agile, Visual-Paradigm, Moutaingoatsoftware, Medium, Ruby.garage
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 AgileTrong dự án Bất Động Sản Agile, việc làm ước tính có thật sự thiết yếu ?
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 – giải pháp giúp nâng cấp cải tiến quy trình tiến độ thao tác của dự án Bất Động Sả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 2020 – The Scrum Guide 2020
Bóng đá có 3-5-2, Scrum có 3-5-3
Xem thêm: Tứ niệm xứ – Wikipedia tiếng Việt
Bắt đầu với Scrum từ đâu đây ta?
Một số cách chạy Daily scrum hiệu suất cao