Thursday, August 19, 2021

Cách estimate user story trong Agile theo points

Posted by with No comments

I. Bối cảnh: 

 Trong buổi planning hay refinement team tiến hành estimate user story theo các ticket. Tuy nhiên team thường không rõ để estimate sẽ dựa vào những yếu tố nào để đưa ra số points cho mỗi user story



                                                        Minh họa: estimate thời gian làm các phương tiện


II.  Cách thức thực hiện: 

1. Các bước thực hiện: 

Bước 0: Lựa chọn khoảng estimation:  Lựa chọn dãy số Fibonanci 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144 

 Sẽ bao gồm 2 group: 

  • 1, 2, 3, 5, 8, 13:  Những số nhỏ hơn đại diện cho thấy team đã rõ ràng về cách làm, mức độ phức tạp thấp hoặc quen, và đã rõ ràng 
  • 21, 34, 55, 89, 144: Những con số này thường đi với những stories cần phải chia ra nhỏ hơn với mức độ phức tạp, rủi ro và mơ hồ cao 

Bước 1:  Lựa chọn và đồng thuận reference PBI ( project backlog items) 

Khi start những sprint từ sprint 2 trở đi, team có thể define được các ticket đã hoàn thành để làm reference,  lựa chọn ticket theo các story point theo mức độ effort ít nhất tới effort rất nhiều, đề xuất lựa chọn 3 mức.( khoảng nhỏ, khoảng trung bình, khoảng lớn) 

Khi team trưởng thành hơn, cải tiến hơn về estimation thì sẽ là thời điểm thích hợp để điều chỉnh lại tham chiếu ticket 



Bước 2: Với  product backlog items  tham chiếu này, sẽ cùng đi estimate với 1 ticket mới thì sẽ ở mức độ như thế nào so với những done items được lựa chọn ở bước 1, thực hiện estimation tool là Planning Poker trong buổi Planning meeting. Để so sánh tương quan hãy đi từ story có point nhỏ nhất, sau đó x2, x4 lần và tiếp tục x n lần tương ứng với effort cần bỏ ra ( độ phức tạp, mức độ rủi ro) để tìm ra được con số phù hợp trong chuỗi fibonanci cho story 

 Tips:

 - lúc lựa chọn point nếu phân vân giữa 2 con số, hãy chọn con số lớn hơn. 

 - Sau khi các thành viên cùng đưa ra số point cho story, pick point lớn nhất và nhỏ nhất để lắng nghe các góc nhìn khác biệt  ==> re-vote 


2. Cách thực hiện trong buổi planning meeting:

Technical sử dụng Planning Poker


1. Sau khi PE hay 1 thành viên nào đó trong team diễn giải về ticket, các thành viên đặt câu hỏi để làm rõ 

2. Sau khi đã clarify, các thành viên đồng loạt đưa ra con số mình chọn cho effort phải làm story ( mức độ phức tạp + độ rủi ro mơ hồ) 

3. Khi có sự khác biệt trong điểm thành viên đưa ra, lắng nghe ý kiến của thành viên đưa ra point lớn nhất và point nhỏ nhất 

4. Re-vote

3. Các qui tắc trong việc estimation: 

 -  Khi estimate cần kết hợp các yếu tố mức độ phức tạp và độ mơ hồ rủi ro 

 -  Không lấy điểm trung bình của các thành viên khi thực hiện planning poker 

 -  Không điều chỉnh story point khi sprint đang chạy 

 -  Không điều chỉnh tham chiếu story, tickets để tham khảo khi estimate ở mỗi sprint 

 -  Không nên cho điểm sub task, story point chỉ áp dụng cho parent, không cho điểm những bugs phát sinh do ticket đang phải done trong sprint gây ra  ( bugs trong quá trình phát triển) 

-  Không cho điểm lại những ticket chưa done còn dang dở từ sprint trước, nếu có extra cần tạo ticket khác 


4. Vậy làm sao để estimate tốt hơn: 

 Cách tốt nhất là cố gắng chia nhỏ story lớn thành các story nhỏ hơn, để nâng cao chất lượng estimate, khi retro luôn có tâm thế cần cải thiện estimate cần tốt hơn


Một số câu hỏi cần member tham gia estimate hỏi và nhận câu trả lời : 

  •   Value mang lại của ticket cho khách hàng là gì ?   ( tránh lãng phí về tính năng mở rộng không cần thiết + biết được mục đích của ticket ) 
  •  Tiket đã đủ rõ để estimate chưa ( giải pháp kĩ thuật đã có chưa, Acceptance Criteria  có đủ hiểu và đủ  để triển khai chưa), có cần chia nhỏ ticket ra  ngay không ? 
  • Tester đã nắm được cách test chưa, những moduel nào ảnh hưởng ?

0 comments:

Post a Comment