Story points – Công cụ ước lượng của Agile – Atoha

Như đã chia sẻ trong bài viết “Câu chuyện của người dùng – Công cụ lập kế hoạch nhanh nhẹn” , chúng tôi đã đề cập đến Câu chuyện của người dùng – một trong những công cụ. Các công cụ mà nhóm nhanh nhẹn sử dụng để lập kế hoạch hiệu quả và những việc cần làm ngay bây giờ. Tiếp tục loạt công cụ và kỹ thuật này, chúng ta sẽ tìm hiểu một công cụ thứ hai, quan trọng không kém, Điểm câu chuyện .

Đương nhiên, chúng tôi khó đưa ra ước tính tuyệt đối chính xác, nhưng việc lập ước tính bằng cách so sánh với một yếu tố khác (ước tính) sẽ dễ dàng và thoải mái hơn. lượng tương đối). Điều này cũng đúng đối với các nhóm nhanh nhẹn, những người coi trọng các ước tính tương đối. Hầu hết các ước tính của họ không tính bằng giờ / ngày / tuần, mà bằng các đơn vị tương đối được gọi là “ điểm câu chuyện “.

Một lý do khác để sử dụng công cụ ước tính tương đối là mỗi thành viên trong nhóm làm việc với tốc độ khác nhau. Ví dụ, một câu chuyện của người dùng với số điểm ước tính là 3 (3 điểm) có thể được hoàn thành trong một buổi sáng bởi một nhân viên có kinh nghiệm, nhưng có thể mất cả ngày để một nhân viên mới hoàn thành. Vì vậy, các điểm câu chuyện chỉ tập trung vào việc ước tính quy mô và độ phức tạp của câu chuyện.

Điểm câu chuyện?

Điểm câu chuyện là một thuật ngữ được sử dụng trong quản lý và phát triển dự án để ước tính quy mô, độ khó và độ phức tạp của việc triển khai câu chuyện của người dùng nhất định, là một thước đo trừu tượng về nỗ lực cần thiết để thực hiện nó. Tóm lại, điểm câu chuyện là một con số, một đơn vị đo lường mức độ khó khăn để kể một câu chuyện cho cả nhóm. hoặc không chắc chắn. Nỗ lực thực hiện đầy đủ một mục trong Product Backlog (danh sách việc cần làm) hoặc bất kỳ công việc nào khác.

Ước tính điểm câu chuyện, một ước tính tương đối, thường được thực hiện trong các cuộc thảo luận về sản phẩm tồn đọng.

Tại sao lại sử dụng điểm câu chuyện?

Khi lập kế hoạch cho các dự án nhanh, các nhóm thường không thể dự đoán các tính năng của sản phẩm / phần mềm sẽ mất bao lâu hoặc ngày hoàn thành chính xác của chúng. Khi ước tính theo giờ / ngày / tuần, bạn phải cam kết thời gian chính xác. Thay vào đó, khi sử dụng điểm câu chuyện, nhóm sẽ gán cho mỗi câu chuyện một giá trị điểm dựa trên quy mô của nó. Đây là lý do tại sao hầu hết các nhóm scrum sử dụng các điểm câu chuyện để lập kế hoạch cho các dự án của họ, cho phép họ so sánh các câu chuyện. Bằng cách tập trung vào độ phức tạp của các tính năng hơn là thời gian chính xác chúng được phát triển, các nhóm có thể tham gia lập kế hoạch cùng nhau và dự đoán những tính năng gia tăng nào có thể được thêm vào phần mềm / sản phẩm sau mỗi chu kỳ.

(Xem thêm: Khóa đào tạo thực hành về quản lý dự án Agile)

Làm thế nào để ước tính điểm câu chuyện trong nhanh?

Điểm câu chuyện rất đơn giản: nhóm chỉ cần chọn một số điểm đại diện cho quy mô, độ khó, độ phức tạp và nỗ lực cần thiết cho mỗi câu chuyện và chỉ định số điểm đó cho mỗi câu chuyện của người dùng trong tồn đọng. Thay vì cố gắng dự đoán chính xác thời gian để xây dựng một tính năng, nhóm đã chỉ định cho mỗi câu chuyện một số điểm dựa trên độ phức tạp của nó sau khi so sánh nó với các tính năng khác mà nhóm đã biết. Ban đầu, ước tính cho mỗi câu chuyện sẽ rất khác nhau, nhưng sau một thời gian, khi nhóm đã quen với kích thước mà nhóm sử dụng để ước tính, việc tính toán kích thước của mỗi câu chuyện trở nên dễ dàng hơn.

Khi chúng tôi sử dụng điểm câu chuyện để ước tính, chúng tôi chỉ định mỗi mục một giá trị điểm. Giá trị ban đầu được sử dụng bởi nhóm không quan trọng. Điều quan trọng là các giá trị này là tương đối. Ví dụ: Điểm phân công câu chuyện là 2 phải gấp đôi Điểm phân công câu chuyện là 1. Nó cũng phải là 2/3 câu chuyện, ước tính là 3 điểm câu chuyện. Ngoài việc chỉ định 1, 2 và 3, các nhóm 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ần suất chứ không phải con số thực tế (giờ / ngày / tuần).

Trong sơ đồ, để lập kế hoạch sprint hiệu quả hơn, chủ sở hữu sản phẩm và nhóm phát triển sẽ đưa ra một ước tính sơ bộ và kiểm tra trước khi lập kế hoạch sprint khi tinh chỉnh sản phẩm tồn đọng:

– Sẵn sàng thực hiện kế hoạch chạy nước rút một cách hiệu quả?

– Có đủ thông tin để hoàn thành những câu hỏi này không?

– Các câu chuyện của người dùng có được phân chia chính xác không?

Có nhiều cách để ước tính điểm câu chuyện trong nhanh và mỗi nhóm sẽ thống nhất về cách tính toán. Trong hầu hết các trường hợp, các điểm câu chuyện được tính theo một trong các thang đo sau:

Theo Cỡ áo phông:

• Nhóm scrum có thể dựa trên ý tưởng chia nhỏ theo kích cỡ áo thun để xác định kích thước và độ phức tạp của câu chuyện và gán giá trị điểm cho mỗi kích cỡ. Kích thước áo phông là công cụ ước tính nâng cao được sử dụng để ước tính sơ bộ về các tính năng của sản phẩm và câu chuyện của người dùng trong giai đoạn đầu của dự án, vì chưa có thông tin chi tiết.
• Phản ánh sự không chắc chắn có liên quan Với những ước tính này, các công cụ ước tính của chúng tôi sẽ là các kích thước áo phông, từ cực nhỏ – cực nhỏ đến cực lớn – cực lớn (xxl).
• Chúng tôi không cố gắng ước tính loại kích thước tuyệt đối của mỗi chiếc áo phông, hoặc thậm chí kích thước lớn hơn hoặc nhỏ hơn bao nhiêu so với các loại khác. Những gì chúng ta biết sẽ cực kỳ nhỏ, hơn nhỏ, nhỏ hơn trung bình, v.v.
• Ví dụ: một nhóm có thể quyết định sử dụng 1 cho các tính năng nhỏ, 2 cho các tính năng nhỏ, 3 cho 4 cho các tính năng trung bình, 4 cho các tính năng lớn và 5 cho các tính năng rất lớn.

Siêu nhỏ

Nhỏ

Trung bình

lớn

Quá khổ

1 điểm

2 điểm

3 điểm

4 điểm

5 điểm

• Quyền hạn của 2: Ngoài ra, nhiều nhóm cũng sử dụng dãy số 1, 2, 4, 8, 16 được tạo bởi lũy thừa của 2 để ước tính số điểm của câu chuyện.
• Chuỗi Fibonacci các điểm của câu chuyện: Khi nhóm quyết định lập kế hoạch theo thang điểm, nhóm cần thống nhất và quyết định áp dụng phương pháp tính điểm. không tí nào. Một số nhóm sử dụng dãy Fibonacci hoặc một số biến thể của dãy (1, 2, 3, 5, 8, 13, 21 …) làm điểm cốt truyện vì họ tin rằng dãy Fibonacci cung cấp chế độ xem Câu chuyện thực tế hơn, quy mô của một câu chuyện tương đối với một câu chuyện khác. Miễn là nhóm của bạn sử dụng thang đo một cách nhất quán, thì việc sử dụng nó sẽ không thành vấn đề đối với nhóm của bạn.

Bất cứ điều gì chưa hoàn thành trong một nước rút sẽ được chuyển từ nước rút này sang nước rút tiếp theo. Và tổng số điểm câu chuyện đã hoàn thành trong mỗi nước rút được theo dõi dưới dạng vận tốc của dự án (vận tốc – chúng ta sẽ tìm hiểu thêm về khái niệm này trong một bài đăng trong tương lai). Nếu một nhóm hoàn thành 15 câu chuyện trong một chặng nước rút với tổng số điểm là 55 câu chuyện, họ sẽ coi 55 điểm câu chuyện đó là vận tốc nước rút, điều này cung cấp cho nhóm một ý tưởng chung về tốc độ chung của cả nhóm, dự đoán tổng số điểm câu chuyện mà họ có Có thể thành công trong nước rút tiếp theo.

Theo thời gian, các nhóm trở nên tốt hơn trong việc chỉ định điểm câu chuyện và họ trở nên nhất quán hơn về số điểm câu chuyện mà họ hoàn thành trong mỗi sprint. Bằng cách này, các nhóm có thể xem họ có thể làm được bao nhiêu trong một chặng nước rút và cùng kiểm soát kế hoạch.

Quy trình ước tính điểm câu chuyện

• Bước 1: Xác định câu chuyện cơ sở

Để tìm câu chuyện cơ sở, chúng tôi cần tìm câu chuyện cơ sở của người dùng đáp ứng các tiêu chí được xác định rõ ràng để xác định dod và gán cho câu chuyện đó một điểm cốt truyện. Câu chuyện cơ sở được dùng làm cơ sở khi so sánh các câu chuyện khác.

• Bước 2: Tạo ma trận để ước tính

Nhóm sẽ ước tính điểm câu chuyện (mục 3) như mô tả ở trên. Tiếp theo, nhóm sẽ tạo một ma trận với mỗi hàng cho mỗi điểm câu chuyện (ví dụ bên dưới sử dụng số Fibonacci) và các câu chuyện liên quan của nó. Sau đó, nhóm sẽ thu thập tất cả các câu chuyện và bắt đầu phân loại chúng thành các hàng, so sánh các câu chuyện với nhau và với các câu chuyện đã hoàn thành hoặc câu chuyện cơ sở khác. Lưu ý rằng câu chuyện cơ sở đã có trong ma trận này, ở hàng đầu tiên và giá trị là một điểm câu chuyện.

Cốt truyện

Câu chuyện

1

Với tư cách là khách truy cập trang web, tôi muốn truy cập trang Giới thiệu để tìm hiểu thêm về dịch vụ.

2

3

5

8

Để chỉ định điểm câu chuyện cho mỗi câu chuyện, nhóm tổ chức một cuộc họp, trong đó tất cả các thành viên của nhóm phát triển sẽ sử dụng poker lập kế hoạch để xác định điểm câu chuyện cho một câu chuyện.

Plan Poker là một kỹ thuật ước tính dựa trên sự đồng thuận để ước tính lượng sản phẩm tồn đọng. Nó có thể được sử dụng với nhiều công cụ ước tính khác nhau, nhưng ở đây chúng tôi đang lập kế hoạch chơi poker với các điểm cốt truyện.

Bước 3: Lập kế hoạch Quy trình Ước tính Poker

• Mỗi thành viên sẽ nhận được một bộ thẻ.
• Tất cả các thành viên đều chọn những việc cần làm để ước tính, thảo luận về các tính năng và đặt câu hỏi.
• Sau khi các tính năng đã được thảo luận đầy đủ, mọi người sẽ đưa ra ước tính của riêng mình – đảm bảo tính bảo mật và chọn một thẻ để đại diện cho ước tính của họ.
• Sau khi mọi người có ước tính riêng về câu chuyện, họ sẽ ngay lập tức hiển thị thẻ của mình. Nếu tất cả các ước tính đều khớp, nhóm sẽ chọn một mục tồn đọng khác và lặp lại quy trình tương tự. Khi các ước tính chênh lệch quá nhiều, vấn đề sẽ được thảo luận để đạt được sự đồng thuận.

Khi kết thúc trò chơi poker theo kế hoạch, nhóm sẽ điền vào ma trận với tất cả các kết quả thu được. Các câu chuyện người dùng của nhóm được chia thành các dòng dựa trên các điểm câu chuyện tương ứng được yêu cầu để thực hiện chúng. Một dòng có thể có nhiều câu chuyện.

Cốt truyện

Câu chuyện

1

Với tư cách là khách truy cập trang web, tôi muốn truy cập trang Giới thiệu để tìm hiểu thêm về dịch vụ.

Là một khách truy cập vào trang web, tôi muốn có thể đặt lại mật khẩu của mình nếu tôi quên.

2

Với tư cách là người dùng đã đăng nhập, tôi muốn có thể xem lịch sử thanh toán của mình trên trang cài đặt.

Với tư cách là khách truy cập trang web, tôi muốn có thể sử dụng biểu mẫu liên hệ để gửi phản hồi hoặc báo cáo sự cố.

3

Với tư cách là khách truy cập trang web, tôi muốn đăng nhập / đăng 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 trang web.

5

Với tư cách là khách truy cập vào trang web của tôi, tôi muốn sử dụng biểu mẫu tìm kiếm với các bộ lọc để tìm kiếm nội dung cụ thể.

Là một khách truy cập vào trang web, tôi muốn xem thông tin chi tiết về nội dung.

8

Với tư cách là người dùng đã đăng nhập, tôi muốn có thể thêm nội dung vào tiêu đề trang web, mô tả, nội dung phương tiện (hình ảnh, video, âm thanh), vị trí địa lý.

p>

Với tư cách là người dùng đã đăng nhập, tôi muốn có thể giao tiếp với những người dùng khác qua tin nhắn.

• Bước 4: Lập kế hoạch Sprint

Tại thời điểm này, nhóm có ước tính độ lớn dựa trên các điểm câu chuyện, câu hỏi đặt ra là làm cách nào nhóm chuyển các điểm câu chuyện này thành ước tính thời gian thực tế (giờ / ngày / tuần). Thật không may, nhóm không thể làm điều này cho đến khi nước rút đầu tiên hoàn thành. Khi chạy nước rút đầu tiên, nhóm có thể theo dõi vận tốc của nhóm. Khi nước rút kết thúc, nó biết được nhóm có thể hoàn thành bao nhiêu điểm câu chuyện trong mỗi lần chạy nước rút. Các đội sử dụng những con số này để dự đoán xem họ sẽ thể hiện như thế nào trong nước rút tiếp theo.

Khi ước tính tất cả công việc tồn đọng dựa trên các điểm của câu chuyện, scrum có thể xem nhóm sẽ cần bao nhiêu nước rút để hoàn thành dự án. Cuối cùng, nhóm có thể biến các đơn vị trừu tượng này thành dữ liệu thời gian thực.

Các lỗi thường gặp khi sử dụng cốt truyện

• Chuyển đổi Điểm câu chuyện thành Giờ: Bằng cách chuyển đổi Điểm câu chuyện thành Giờ / Ngày / Tuần, nhóm sẽ bắt đầu làm việc và phải mạo hiểm thực hiện các cam kết về thời gian phù hợp để hoàn thành. Giả sử khung thời gian để ước tính điểm câu chuyện là 10 – 20 giờ, nhưng khi ước tính theo giờ, nhóm phải đưa ra một con số chính xác, chẳng hạn như 15 giờ, điều này có thể dẫn đến sai lệch và khiến bạn khó đạt được cam kết hơn trong khi làm việc trên đó chính xác giờ.
• Đưa ra điểm câu chuyện trung bình: Khi lập kế hoạch chơi poker, một nửa số thành viên trong nhóm ước tính lượng sản phẩm tồn đọng là 3 điểm câu chuyện và nửa còn lại là 5 điểm câu chuyện. Nhóm nghiên cứu đã giải quyết vấn đề này bằng cách đặt 4 điểm câu chuyện làm ước tính. Các đội không nên làm điều này vì các đội sẽ thỏa hiệp bằng cách cung cấp độ chính xác sai. Các đội tốt hơn nên thảo luận để hiểu rõ hơn là lấy mức trung bình.
• Điều chỉnh ước tính điểm câu chuyện cho câu chuyện của người dùng trong quá trình chạy nước rút: Thời điểm và thời điểm các nhóm bắt đầu giải quyết vấn đề, các nhóm không nên điều chỉnh ước tính điểm câu chuyện ngay cả khi ước tính của họ không chính xác. Việc ước tính đôi khi bị sai là điều bình thường, vì vậy thay vì điều chỉnh, nhóm nên lưu thông tin này làm cơ sở để xác định chính xác hơn các điểm câu chuyện trong tương lai.
• Đánh giá lại điểm nổi bật của câu chuyện: Không cần ước tính lại khi chuyển các hạng mục tồn đọng sản phẩm chưa hoàn thành sang nước rút tiếp theo. Các ước tính có thể không chính xác, nhưng đó không phải là vấn đề. Nhờ lập kế hoạch chạy nước rút, nhóm sẽ biết tất cả các nhiệm vụ cần thiết để hoàn thành câu chuyện của người dùng. Ước tính cho các nhiệm vụ này là hàng giờ. Vì vậy, ở sprint tiếp theo, nhóm sẽ biết mình sẽ mất bao nhiêu thời gian để hoàn thành dự án product backlog này.
• Điều chỉnh ước tính điểm câu chuyện theo người biểu diễn: Người dùng thành viên có kinh nghiệm có thể có 3 điểm câu chuyện và thành viên mới có thể có 8 điểm câu chuyện. Đây là phương pháp sai. Chúng ta không nên điều chỉnh các điểm câu chuyện vì những người cụ thể sẽ thực hiện công việc. Bởi vì điểm câu chuyện chỉ dựa trên quy mô, độ phức tạp và độ khó của câu chuyện người dùng.
• Thực hiện theo lời khuyên của các chuyên gia trong nhóm: Khi lập kế hoạch chơi poker, có nguy cơ nhóm sẽ làm theo lời khuyên của các chuyên gia hơn là sự kết hợp của từng thành viên. . Các nhóm thường giải quyết công việc bằng cách nhờ các chuyên gia trình bày các chi tiết của công việc. Sau đó, yêu cầu những người còn lại trong nhóm ước tính mà không cần chuyên gia. Chúng ta cần nhớ rằng ước tính điểm câu chuyện là nỗ lực của cả nhóm, không chỉ của bất kỳ thành viên nào.
• Tính không chính xác của ước tính sẽ không được mở lại. Điểm câu chuyện trong phần hồi tưởng nước rút: Đôi khi nhóm phát hiện ra vấn đề trong đó việc ước tính điểm câu chuyện rõ ràng là hoàn toàn sai. Điều quan trọng là phải thảo luận về những vấn đề này và cố gắng học hỏi và cải thiện để các ước tính trong tương lai sẽ chính xác hơn.

Tóm tắt

Khái niệm về điểm cốt truyện rất đơn giản, nhưng khó áp 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 của các công cụ scrum cốt lõi. Vì vậy, mọi người có ý kiến ​​khác nhau về cách sử dụng chúng. Việc sử dụng các điểm câu chuyện ngay từ đầu có thể dẫn đến ước tính sai của nhóm, nhưng việc hiểu và kiểm soát kế hoạch cùng nhau theo thời gian, số điểm được giao trong mỗi nước rút nhất quán hơn sẽ giúp nhóm trưởng thành hơn và làm cho công việc ước tính trở nên dễ dàng hơn và dễ dàng hơn.

Kiến thức chung của giảng viên nguyễn hải hà (pmp®, giảng viên pmi-atp)

Tài liệu tham khảo: luyện thi pmi-acp, đầu óc nhanh nhẹn, mô hình trực quan, moutaigoatsoftware, medium, ruby.garage

Product Backlog là gì? Nó liên quan gì đến wbs

Tuyên ngôn Agile – Lịch sử của Agile

12 nguyên tắc của Agile

Việc ước tính có thực sự cần thiết trong một dự án nhanh không?

Sử dụng scrum để quản lý dự án

những câu nói lảm nhảm

Câu chuyện của người dùng – Công cụ lập kế hoạch nhanh nhẹn

Điểm câu chuyện – Công cụ ước tính nhanh nhẹn

Vận tốc là gì – Một nhóm nhanh nhẹn hoàn thành công việc nhanh như thế nào

Bản đồ câu chuyện – Lập kế hoạch nhanh nhẹn

Agile Retrospective – Đánh giá và Cải thiện Hiệu suất Dự án

Kanban – một cách giúp cải thiện quy trình làm việc của dự án

pdca – Chu kỳ cải tiến liên tục

Vai trò – một công cụ để xây dựng sự hiện diện của khách hàng một cách linh hoạt

Lean – Các quy trình được sắp xếp hợp lý một cách hiệu quả

Hướng dẫn Scrum 2020 – Hướng dẫn Scrum 2020

Bóng đá có 3-5-2, scrum có 3-5-3

Chúng ta bắt đầu scrum từ đâu?

Một số cách để thực hiện một cách hiệu quả một công việc hàng ngày