EP 5. Scrum Events

Các Sự Kiện Trong Scrum

Sprint là một sự kiện chứa tất cả các sự kiện khác.
Mỗi sự kiện trong Scrum là một cơ hội chính thức để kiểm tra và thích ứng các tạo phẩm của Scrum.

Các sự kiện này được thiết kế một cách cụ thể nhằm tạo ra sự minh bạch cần thiết.
Việc không thực hiện được bất cứ sự kiện nào như quy định ở đây sẽ làm mất cơ hội kiểm tra và thích ứng.

Các sự kiện được sử dụng trong Scrum để tạo ra sự điều tiết và giảm thiểu nhu cầu tổ chức các cuộc họp không được định ra trong Scrum.
Tốt nhất, tất cả các sự kiện nên được tổ chức vào thời gian và địa điểm cố định để giảm sự phức tạp.

1. The Sprint

Các Sprint đóng vai trò như nhịp tim đối với Scrum, trong đó các ý tưởng được biến thành giá trị.
Chúng là những sự kiện có độ dài nhất định trong khoảng một tháng hoặc ngắn hơn để tạo ra sự nhất quán. Một Sprint mới sẽ bắt đầu ngay sau khi Sprint trước kết thúc.

Tất cả công việc cần thiết để đạt Product Goal, bao gồm:

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective

Trong một Sprint:

  • Không được thực hiện những thay đổi có thể làm tổn hại đến Sprint Goal
  • Chất lượng không giảm sút
  • Product Backlog được tinh chỉnh nếu cần thiết
  • Phạm vi công việc có thể được làm rõ thêm và thảo luận lại với Product Owner khi một số thông tin trở nên rõ ràng hơn

Các Sprint làm tăng khả năng dự đoán bằng cách đảm bảo kiểm tra và thích ứng tiến độ hướng tới Product Goal diễn ra ít nhất mỗi tháng một lần.

Nếu Sprint quá dài, Sprint Goal dễ trở nên không phù hợp, sự phức tạp tăng lên và rủi ro cao hơn.
Nên thực hiện Sprint ngắn hơn để tạo thêm chu kỳ học hỏi và giới hạn rủi ro.

Mỗi Sprint có thể được xem như một dự án ngắn.

Có nhiều thực hành để dự báo về tiến độ như burn-downs, burn-ups hoặc cumulative flows.
Mặc dù hữu dụng, chúng không thay thế được chủ nghĩa thực nghiệm – trong môi trường phức tạp, không thể biết trước điều gì sẽ xảy ra.

Một Sprint có thể bị huỷ bỏ nếu Sprint Goal trở nên lỗi thời.
Chỉ có Product Owner có quyền huỷ Sprint.

2. Sprint Planning

Sprint Planning khởi đầu một Sprint bằng cách sắp đặt công việc sẽ được thực hiện trong Sprint.
Bản kế hoạch này là kết quả từ sự cộng tác của toàn Scrum Team.

Product Owner bảo đảm những người tham dự được chuẩn bị thảo luận các hạng mục quan trọng nhất trong Product Backlog và sự liên quan của chúng đến Product Goal.

Scrum Team có thể mời thêm người tham dự để đóng góp ý kiến.

Sprint Planning đề cập đến ba chủ đề:

Chủ Đề Thứ Nhất: Tại sao Sprint mang lại giá trị?
Product Owner đề xuất cách tăng giá trị và tính hữu dụng của sản phẩm trong Sprint.
Scrum Team xác định Sprint Goal để truyền đạt lý do Sprint sẽ mang lại giá trị.
Sprint Goal phải được thông qua trước khi kết thúc Sprint Planning.

Chủ Đề Thứ Hai: Những gì có thể được Hoàn Tất trong Sprint?
Các Developers chọn các hạng mục từ Product Backlog, có thể tinh chỉnh để tăng sự hiểu biết và chắc chắn.
Việc chọn vừa đủ để hoàn thành Sprint đôi khi khá thử thách, nhưng với kinh nghiệm, họ sẽ dự đoán chính xác hơn.

Chủ Đề Thứ Ba: Làm thế nào để hoàn tất những việc đã chọn?
Developers lập kế hoạch làm việc để tạo nên Increment thoả Định Nghĩa về Sự Hoàn Tất.
Thường là phân tách các hạng mục lớn thành nhỏ, hoàn tất trong một ngày hoặc nhanh hơn.
Chỉ Developers mới có quyền quyết định cách thực hiện công việc.

Sprint Goal, các hạng mục đã chọn và kế hoạch để thực hiện chúng tạo thành Sprint Backlog.

Sprint Planning được giới hạn tối đa 8 tiếng cho Sprint một tháng.
Với các Sprint ngắn hơn, sự kiện này thường ngắn hơn.

3. Daily Scrum

Daily Scrum nhằm kiểm tra tiến độ và điều chỉnh kế hoạch hằng ngày để đạt Sprint Goal.
Là sự kiện 15 phút mỗi ngày cho các Developers.

Nên tổ chức vào thời gian và địa điểm cố định trong Sprint.

Nếu Product Owner hoặc Scrum Master có công việc trong Sprint Backlog, họ tham gia Daily Scrum với vai trò Developers.

Các Developers có thể dùng bất kỳ hình thức hoặc kỹ thuật nào, miễn là Daily Scrum tập trung vào tiến độ và lập kế hoạch cho ngày tiếp theo.

Daily Scrum giúp:

  • Cải thiện giao tiếp
  • Phát hiện trở ngại
  • Khuyến khích ra quyết định nhanh
  • Giảm nhu cầu các cuộc họp khác

Daily Scrum không phải là cơ hội duy nhất để điều chỉnh kế hoạch — các Developers có thể thảo luận thêm bất cứ lúc nào trong ngày.

4. Sprint Review

Sprint Review nhằm kiểm tra kết quả Sprint và xác định những điều chỉnh cần thiết cho tương lai.

Scrum Team trình bày kết quả công việc cho các bên liên quan và thảo luận tiến độ hoàn tất Product Goal.

Trong buổi này:

  • Cùng xem xét những gì đã hoàn tất
  • Những thay đổi xảy ra trong môi trường
  • Xác định các bước tiếp theo
  • Có thể điều chỉnh Product Backlog

Sprint Review là một buổi làm việc, không nên bị giới hạn thành một buổi trình bày.

Sprint Review là sự kiện kế cuối của Sprint và giới hạn tối đa 4 tiếng cho Sprint một tháng.
Với các Sprint ngắn hơn, thời gian cũng sẽ ngắn hơn.

5. Sprint Retrospective

Sprint Retrospective nhằm lập kế hoạch cải thiện chất lượng và hiệu quả.

Scrum Team kiểm tra Sprint vừa qua thông qua:

  • Con người
  • Tương tác
  • Quy trình
  • Công cụ
  • Định Nghĩa về Sự Hoàn Tất

Scrum Team:

  • Xác định các giả định sai lệch và nguyên nhân
  • Thảo luận điều tốt, điều chưa tốt
  • Tìm cách giải quyết vấn đề

Những cải tiến quan trọng nên được xử lý càng sớm càng tốt, thậm chí đưa vào Sprint Backlog cho Sprint tiếp theo.

Sprint Retrospective kết thúc một Sprint và giới hạn tối đa 3 tiếng cho Sprint một tháng. cho những sprint ngắn hơn thì thời lượng cũng ngắn hơn.