Các hoạt động chính trong Agile Scrum

⏱︎

Read time:

4–7 minutes
Minh họa các hoạt động trong một Sprint Scrum

Sprint là đội dài của 1 vòng lặp trong Agile Scrum. Thông thường sẽ là khoảng 2 tuần. Đôi khi là 1 tuần đối với nhiều team cần release nhanh chóng.

Lưu ý
Theo Scrum Guide hiện hành, các events chính thức là Sprint Planning, Daily Scrum, Sprint Review và Sprint Retrospective. Backlog refinement là hoạt động liên tục; demo và code freeze không phải Scrum events bắt buộc.
Lưu ý
Tất cả các event dưới đây đều do Scrum master là người điều phối. Tuy nhiên, nếu team không có SM, thì team lead hoặc tester hoàn toàn có thể tự đảm nhiệm

Sprint Planning

Sprint Planning mở đầu Sprint và trả lời ba câu hỏi: Sprint này có giá trị gì, có thể hoàn thành những việc gì và sẽ thực hiện như thế nào. Kết quả chính là Sprint Goal và Sprint Backlog.

  • Product Owner làm rõ Product Backlog Items và thứ tự ưu tiên.
  • Developers chọn lượng công việc phù hợp với năng lực và lập kế hoạch thực hiện.
  • Tester nêu risk, testability, test data, test environment và effort kiểm thử.
Ví dụ
Sprint Goal là “Khách hàng có thể thanh toán bằng QR”.
– Product Owner làm rõ Product Backlog Items và thứ tự ưu tiên. Sau đó nhặt các ticket cần hoàn thành vào sprint
– Dev lead phân tích và tiến hành đánh giá khối lượng công việc cho từng ticket, nếu thừa thì bỏ bớt, còn thiếu thì thêm ticket khác vào
– Tester phối hợp đánh giá khối lượng test cho từng ticket
– Cuối cùng, chốt ra được list tickets cho sprint, và tiến hành assign từng ticket cho từng member trong team
Lưu ý
– Mỗi ticket được ước lượng bằng Story points. Nó không nhất thiết phải là manday, mà là độ phức tạp của ticket đó. Ví dụ: 1 (đơn giản), 2 (vừa phải), 3 (tương đối), 5 (khó)…
– Ticket to quá sẽ break thành các ticket nhỏ hơn để giảm thiểu rủi ro
Lưu ý
– Cả team sẽ vote xem ticket đó có khối lượng bao nhiêu story points, nếu bất đồng giữa các member thì thảo luận rồi vote lại, ưu tiên có buffer cho từng ticket. Có thể sử dụng 1 bộ bài (Scrum Deck) để thay cho việc vote nếu cần.
– Có cả effort cho việc test cho từng ticket

Daily Scrum (Daily Meeting)

Daily Scrum là sự kiện 15 phút dành cho team phát triển để kiểm tra tiến độ hướng tới Sprint Goal và điều chỉnh kế hoạch. Nhiều team dùng ba câu hỏi “hôm qua làm gì, hôm nay làm gì, có blocker gì”, nhưng Scrum không bắt buộc đúng format này.

Cảnh báo
Daily không phải buổi báo cáo cho Scrum Master hay quản lý. Và chỉ diễn ra trong 15 phút, tránh dông dài hàng tiếng đồng hồ!

Backlog Refinement

Backlog refinement là hoạt động liên tục nhằm chia nhỏ và làm rõ Product Backlog Items, bổ sung description, thứ tự và size. Nó không phải một Scrum event chính thức, nhưng team thường đặt lịch cố định để dễ phối hợp.

  • Làm rõ user story, acceptance criteria và business rules.
  • Chia story quá lớn, nhận diện dependency và risk.
  • Tester đặt câu hỏi, đưa ví dụ, boundary và negative scenarios.
  • Team ước lượng khi item đã đủ rõ.
Ví dụ
Feature mới khá phức tạp. BA book 1 buổi refinement để làm rõ với cả Dev và Tester. Nhờ có buổi này, nhiều thứ mơ hồ đã được xử lý, nên ticket được chỉnh sửa chuẩn chỉ hơn. Tiết kiệm thời gian cho buổi Planning

Sprint Review và Demo

Sprint Review diễn ra gần cuối Sprint để Scrum Team và stakeholders kiểm tra kết quả, thảo luận thay đổi của thị trường hoặc nhu cầu, rồi điều chỉnh hướng đi tiếp theo.

Lưu ý
Buổi Review để check xem sprint vừa rồi có hoàn thành không, ticket nào bị delay, ticket nào thì release được. Từ đó, PO có quyết định của mình

Demo là 1 buổi meeting mà team sẽ Demo các feature mới cho các team khác trong công ty

Ví dụ
Demo các feature chính trong 2 tuần vừa rồi cho team PO và các team Marketing, Sales… Để họ nắm được feature mới của sản phẩm

Sprint Retrospective (Retro)

Retro là 1 buổi nhìn lại xem team đã làm tốt những gì, những gì chưa tốt và cách cải thiện ra sao

Mỗi người trong team sẽ có 1 mẩu giấy, ghi các việc OK, việc chưa OK ra. Sau đó tổng hợp lại. Việc nào chưa OK thì cả team cùng nhau tìm ra solution

Ví dụ
Ví dụ action item tốt: “Từ Sprint sau, QA tham gia refinement và BA bổ sung acceptance criteria trước Planning”, thay vì câu chung chung “cần viết requirement tốt hơn”.
Lưu ý
Có thể diễn ra 1 tháng 1 lần thay vì 2 tuần 1 lần, vì diễn ra với tần suất quá cao không đem lại nhiều benefit cho buổi này

Code Freeze là gì?

Code freeze là quy ước tạm ngừng hoặc hạn chế thay đổi code trước release để ổn định build. Đây không phải thực hành bắt buộc của Scrum. Team có CI/CD tốt có thể release thường xuyên mà không cần freeze code day.

Ví dụ
Sprint bắt đầu từ thứ 2. Đến ngày thứ 4 của tuần kế tiếp, sẽ là ngày Code Freeze, cảm team dev không ai được đẩy code lên môi trường QA nữa. Để QA chạy regression test. Việc này đảm bảo source code trước khi release là không đổi.
Lưu ý
Tuy nhiên, team đủ khoẻ và senior, thì hoàn toàn có thể sử dụng chiến thuật One commit – One Deploy. Không cần dồn 1 bản release ở cuối mỗi sprint mà release hàng ngày luôn. Miễn là team member có thể thích nghi được mà không bị quá tải

Kết luận

Scrum events tạo feedback loop đều đặn trong mỗi Sprint. Demo, refinement hay code freeze chỉ có giá trị khi phục vụ mục tiêu đó; đừng biến chúng thành thủ tục hoặc nhầm chúng với quy định bắt buộc của Scrum.