Sprint Retrospective: Cuộc họp này nói về điều gì, thực hiện như thế nào và tại sao chúng ta cần nó.

Trong tất cả các sự kiện của Scrum, đây có lẽ là sự kiện hay bị “bỏ-qua” nhất của các team, trong khi đó, Srpint Retrospective lại lại một sự kiện rất quan trọng.

Cuộc họp Sprint retrospective được tổ chức ngay sau sự kiện sprint review, nhưng trước khi bắt đầu sự kiện sprint planning cho một sprint mới. Khi kết thúc cuộc họp sprint retrospective, đội phát triển nên chỉ ra những cải tiến mà sẽ được thực hiện ở sprint tiếp theo.

Chúng ta cần biết gì về cuộc họp Retrospective?

Cuộc họp sprint retrospective để nhóm có thể nhìn lại sprint vừa qua, giúp nhóm tự thanh tra và lập kế hoạch cho những cải thiện sẽ được thực hiện ở sprint tiếp theo (hoặc tương lại).
Có một cách tốt để cuộc họp trở nên hiệu quả là trả lời những câu hỏi sau:
  • Những điều đã làm tốt
  • Những điều cần cải thiện
  • Những điều đã không thực hiện tốt ở sprint trước đó.
Bằng cách trả lời những câu hỏi trên, bạn cần:
  • Thanh tra xem sprint vừa rồi đã diễn ra như thế nào, những vấn đề cần quan tâm về: con người, các mối quan hệ, công cụ và quy trình.
  • Xem lại những điều đã làm tốt và xem những chỗ cần cải thiện.
  • Xây dựng kế hoạch để thực hiện những cải tiến đối với quy trình làm việc của nhóm phát triển.
Ai nên tham dự cuộc họp Retrospective?

Scrum master và nhóm phát triển cộng tác trong cuộc họp retrospective và cố gắng tìm kiếm những cải tiến.

Product owner có thể tham dự hoặc không, các bên liên quan không cần tham dự buổi họp này.
Cuộc họp sprint retrospective nên kéo dài bao lâu
Nhiều nhất là 3 tiếng với sprint 1 tháng. Đối với những sprint ngắn hơn, cuộc họp này có thể rút ngắn.

Các cách thực hiện buổi họp sprint retrospective hiệu quả

Thực hiện các bước nhỏ, nhưng cụ thể.
Thực hiện cải tiến yêu cầu nhóm phát triển phải tạo ra những thay đổi. Và sự thay đổi bao giờ cũng gặp rất nhiều khó khăn, đặc biệt là khi nó mang tới những giá tri tốt hơn.
Tìm kiếm những cải tiến nhỏ, những thay đổi tích cực có thể được nhóm thích nghi nhanh hơn.
Ví dụ, nếu burndown chart của bạn chưa đáp ứng được kỳ vọng giống biểu đồ lý tưởng, bạn nên tìm kiếm xem tại sao vấn đề này lại xảy ra. Lý do có vẻ luôn là do các user story chưa được làm rõ một cách đúng đắn và chưa được chia nhỏ thành cách nhiệm vụ phù hợp. Điều này có thể dẫn tới những kế hoạch không chính xác, và làm bạn trở nên lo lắng.
Giữ sự tích cực
Khi thanh tra các vấn đề để cải tiến, rất dễ chúng ta sẽ bị tập trung vào các vấn đề tiêu cực, và vì vậy nên tránh nó ngay từ đầu.
Các nghiên cứu cho thấy, để đạt năng suất làm việc tốt hơn, sự tích cực đóng một vai trò rất quan trọng. Bằng việc tập trung vào những khía cạnh tích cực của sprint trước và nói rằng nó có thể tiếp tục cải thiện, bạn sẽ thiết lập một trạng thái tốt trong cuộc họp và tránh để một cuộc họp hiệu quả trở nên xấu đi.
Ghi nhận và khuyến khích sự đóng góp của các thành viên.
Trong suốt cuộc họp retrospective, hãy dành vài phút để ghi nhận những đóng góp của các thành viên một cách chân thành. Điều này có thể rất tích cực khi bạn và mọi người vừa thảo luận về “những gì đã có thể làm tốt hơn ở sprint trước”, điều này cũng giúp nhóm của bạn “muốn” tiến về phía trước.
Đảm bảo cuộc họp không bị chi phối
Cuộc họp retrospective được sử dụng để tăng sự cộng tác. Đảm bảo rằng ý kiến của mọi thành viên về những gì hoạt động tốt và có thể được cải thiện trong buổi họp đều được lắng nghe cẩn thận. Nếu cuộc thảo luận bị chi phối bởi một người, thì scrum master có thể phải tham gia và là người tạo điều kiện cho nhóm có không gian để nói lên ý kiến của mình.
Phản tư về Retrospective
Khi họp retrospective, bạn có thể nhận thấy một vài điểm mà bạn muốn cải thiện. Tuy vậy, hãy nhớ nhìn lại về các cuộc họp retrospective lần trước và xem liệu bạn có cải tiến được điều gì không? Nếu những việc cần làm để cải tiến (được rút ra từ cuộc họp trước) bạn chưa thực hiện được. Có khả năng quá trình thực hiện cải tiến của bạn chưa thực sự tốt. Hãy dành thời gian để suy nghĩ về nó trước khi đưa ra những hành động mới – mà rất có thể lại được thực hiện dở dang.
Dịch và hiệu chỉnh từ nguồn: zepel.io