9 câu hỏi Scrum master và Product owner có thể hỏi

Để thành công với vai trò là một Master Scrum, cần phải chuyển từ việc đưa ra các nhận định sang việc đặt ra nhiều câu hỏi hơn. Dưới đây là một số câu hỏi. Hầu hết trong số này có thể được dùng để đặt câu hỏi cho đội dự án, cho dù bạn là một Scrum Master hoặc Product Owner.

Hai câu hỏi về ước tính

Thường thì chúng ta cần một ước tính sơ bộ từ team (chỉ là ước tính chứ không yêu cầu một cam kết. Ước tính và cam kết không giống nhau.) Câu hỏi có thể đặt ra là “Tôi không tìm kiếm ước tính. Nhưng nếu tôi yêu cầu ước tính, bạn có thể ước tính theo đơn vị nào: Giờ, ngày, tuần, tháng hoặc năm?” Những đơn vị này có thể trùng lặp, nhưng có khi nhận được một ước tính từ nhóm vd như “vài tuần” thì cũng thường đủ tốt để đưa ra quyết định, bao gồm cả quyết định yêu cầu nhóm ước tình chi tiết hơn Trong những tình huống mà tôi có ước tính chính thức từ một nhóm, một câu hỏi khác mà tôi thường hỏi là: “Bạn tự tin thế nào trong ước tính đó?” Những gì bạn đang tìm kiếm ở đây là mức độ tự tin và liệu các thành viên trong nhóm có đồng ý hay không. Ước tính, trong đó hầu hết mọi người tin tưởng 90% sẽ có nhiều khả năng chính xác hơn. Sự bất đồng giữa các thành viên trong nhóm về sự tự tin của họ trong một ước tính cũng có thể cho thấy nhóm đã vội vã tạo ra ước tính. Điều đó có thể ổn nhưng hãy xem xét ước tính kém tin cậy hơn.

Ba câu hỏi về quyết định nhóm

Là một Scrum master hoặc PO, đôi khi tôi muốn có được một cảm giác về việc team đã suy nghĩ như thế nào thông qua một quyết định. Dưới đây là ba câu hỏi tôi thường hỏi:

• Ba lựa chọn khác mà bạn đã cân nhắc trước khi đưa ra quyết định này là gì?
• Điều gì tồi tệ nhất có thể xảy ra nếu chúng ta theo đuổi hướng này?
• Điều gì đã thực hiện đúng để việc này trở thành quyết định tốt nhất? Có thể bạn không muốn hỏi cả ba câu hỏi này. Và đừng hỏi cùng một câu hỏi về mọi quyết định mà một nhóm đã đưa ra. Ngoài ra, bạn không hỏi những câu hỏi này bởi vì bạn (với tư cách là Scrum master hoặc PO) có quyền hủy bỏ quyết định của nhóm. Tuy nhiên, bạn có quyền hiểu được sự tự tin của nhóm trong một quyết định và mức độ liên quan của họ đối với quyết định đó. Những câu hỏi này được thiết kế để khám phá sự bất đồng. Nếu bạn hỏi "Điều gì đã thực hiện đúng để việc này trở thành quyết định tốt nhất?" Và ai đó nói, "Mọi thứ!" thì đó có thể là một vấn đề.

Hai câu hỏi về cuộc họp

Tôi thực sự không thích các cuộc họp. Vì vậy, tôi cố gắng làm ngắn gọn trong việc tổ chức các cuộc họp - và số lượng người tham gia trong một cuộc họp - đến mức tối thiểu. Vì vậy, có hai câu hỏi tôi thường hỏi khi bắt đầu cuộc họp:

• Chúng ta có cần mọi người ở đây bây giờ không?
• Có ai ở đây không? Câu hỏi đầu tiên được thiết kế để xem liệu chúng ta có cần thiết phải có đủ các thành viên tham gia vào một cuộc họp hay không. Tôi thường thấy các đội đi quá xa trong việc theo đuổi tinh thần đồng đội và cộng tác. Các thành viên trong nhóm sẽ cảm thấy như họ cần phải có mặt trong mọi cuộc họp, ngay cả những cuộc họp hoàn toàn không liên quan đến họ. Nếu mọi người trong nhóm của bạn đang quá hăng hái trong cuộc họp mặt của họ, cảm ơn vì sự cam kết hợp tác của họ nhưng đảm bảo với họ rằng họ không cần tham dự mọi cuộc họp. Câu hỏi thứ hai ở trên sẽ giúp xác định xem có ai được yêu cầu nhưng vắng mặt trong buổi họp đó hay không. Đôi khi có quá ít cuộc họp và quá ít người, nhưng một số cuộc họp có giá trị và những cuộc họp đó được thực hiện có giá trị hơn bằng cách có những người tham gia phù hợp.

Một câu hỏi để hỏi khi tìm hiểu

Đặc biệt là khi làm việc như một Scrum Master, tôi dành rất nhiều thời gian để nói chuyện. Ví dụ, nếu tôi thấy một lập trình viên và người thử nghiệm có vẻ đang có một cuộc trò chuyện quan trọng, tôi có thể đi qua và lắng nghe trong trường hợp tôi có thể giúp đỡ với bất cứ điều gì. (Rõ ràng là đừng làm điều này mỗi khi họ nói chuyện bình thường hoặc nếu nó giống như một cuộc trò chuyện riêng tư.) Đôi khi các cuộc thảo luận tôi nghe có thể có giá trị đối với người khác. Vì vậy, tôi sẽ hỏi:

• Có ai khác cần biết về điều này không? Nếu có, tôi sẽ đề nghị là người chia sẻ thông tin nếu có thể. Nếu không, tôi sẽ đề nghị đi tìm người để họ có thể được đưa ra ý tưởng ngay lập tức.

Một câu hỏi để hỏi trong buổi họp daily meeting

Trong daily scrum, tôi thường sẽ nhìn vào biểu đồ burndown của đội và tự hỏi làm thế nào họ sẽ hoàn thành tất cả mọi thứ như plan vào cuối sprint. Nhưng khi tôi hỏi cùng một đội này nếu họ có thể hoàn thành mọi thứ, phản ứng thường là họ sẽ làm. Nếu tôi không đồng ý rằng dự đoán của họ thực tế, tôi sẽ nhìn lại vào cái burndown và hỏi:

• Bạn biết gì mà tôi không biết? Tôi có thể nhận được câu trả lời rằng một thành viên trong nhóm đã không cập nhật giờ làm của họ trong công cụ họ đang sử dụng. Hoặc ai đó sẽ giải thích rằng họ đang làm chậm nhưng bởi họ học được rất nhiều thứ và chuẩn bị tăng tốc độ trong thời gian tới. (Tôi thấy niềm tin này hiếm khi giữ đúng, nhưng tôi nghe rất nhiều.)

Đặt câu hỏi tiết lộ nhiều hơn việc đưa câu ra lệnh

Khi tôi lần đầu tiên trở thành một Scrum Master và chưa học được về sức mạnh của câu hỏi, tôi thường bỏ lỡ những điều học hỏi về các đội của tôi và công việc của họ. Chỉ sau một thời gian tôi mới khám phá ra rằng cách tốt nhất để tôi học hỏi là hỏi một câu hỏi và sau đó thật sự lắng nghe câu trả lời. Tôi hy vọng bạn sẽ tìm thấy những câu hỏi này hữu ích như tôi. Nguồn: https://www.mountaingoatsoftware.com/blog/nine-questions-scrum-masters-and-product-owners-should-be-asking