Sprint execution: standup, blocker, điều chỉnh giữa sprint

Lập plan cho sprint là phần dễ; chạy sprint từng ngày mới là chỗ phần lớn team âm thầm tụt lại. Engineer không flag blocker; lead bận trong quá nhiều cuộc họp để nhận ra; đến buổi demo thứ Sáu thì mới vỡ ra rằng có những việc đã không xảy ra. Chương này giới thiệu các artifact hàng ngày giúp giữ cho khoảng cách đó nhỏ lại.

Khi nào kỷ luật sprint execution mang lại giá trị?

Có ba dấu hiệu.

Team lỡ hơn một sprint goal trong ba sprint gần nhất. Lỡ một sprint là chuyện bình thường; nhưng lỡ theo pattern là tín hiệu rằng phần execution đang xuống cấp, chứ không phải phần planning xuống cấp.

Blocker tồn tại hơn 48 giờ. Khi engineer nói "tôi đang bị chặn nhưng sẽ làm việc khác", blocker đó thường sẽ sống đến hết sprint và đập thẳng vào buổi demo cuối.

Bị bất ngờ về scope vào cuối sprint. Câu "chúng ta tưởng sẽ xong X vào thứ Sáu" được nói ra vào chiều thứ Tư mà chưa có plan phục hồi. Đây là dấu hiệu thiếu tầm nhìn ở giữa sprint.

Nếu sprint đang đáp đáng tin cậy và blocker được gỡ nhanh, một mức kỷ luật nhẹ là đủ.

Cái giá khi execution yếu là gì?

Có ba kiểu lỗi thường gặp.

Velocity suy giảm dần. Sprint qua sprint, sản lượng giảm mà không có lời giải thích. Nguyên nhân thường nằm ở việc thêm scope một cách im lặng và blocker không được quản lý, chứ không phải ở việc mất capacity thực sự.

Văn hoá anh hùng. Một engineer làm cuối tuần để gỡ rối. Team âm thầm học rằng đó là kỳ vọng. Burnout đến theo sau.

Mất niềm tin từ stakeholder. Ba buổi demo liên tiếp trình ra ít hơn so với cam kết. Stakeholder dần dần ngừng dự; niềm tin bào mòn.

Một standup hữu dụng trông thế nào?

15 phút, có cấu trúc rõ:

## Daily Standup — 2026-06-11

Mỗi người, 60 giây:
1. Hôm qua: cái tôi ship (PR merge, story chuyển Done)
2. Hôm nay: cái tôi đang lấy
3. Blocker: cái gì chặn tôi, hay tôi chờ sẽ chặn

Sau vòng (4 phút):
- Blocker mới thêm vào danh sách
- Owner đồng ý cho mỗi blocker mới
- Cái nào để thảo luận offline đánh dấu

## Danh sách blocker (sprint này)

| Blocker | Owner gỡ | Tuổi (giờ) | Trạng thái |
|---------|----------|------------|------------|
| Stripe sandbox 503 | Bob -> ticket infra | 28 | Đã escalate |
| Design email refund đợi | Carol -> Designer | 8 | Đang xử |

Danh sách blocker chính là artifact bí mật của standup. Phần lớn các buổi standup nói về blocker rồi quên ngay; còn một danh sách dai dẳng có gắn tuổi sẽ ép việc escalate phải xảy ra - blocker trên 24 giờ thì lead phải chú ý, trên 72 giờ thì lên thẳng status report.

Lead xử lý blocker mà không thành bottleneck ra sao?

Có ba quy tắc.

Quy tắc 1: kết nối, đừng tự làm. Khi một blocker xuất hiện, việc của lead là xác định ai có thể gỡ được và route engineer đến đúng người đó. Tuyệt đối không kéo blocker vào queue của chính mình.

Quy tắc 2: escalate sau 24 giờ. Blocker cũ hơn một ngày thì phải chuyển lên cấp trên. EM được kéo vào cho các blocker xuyên team; sponsor được kéo vào cho các blocker xuyên tổ chức.

Quy tắc 3: theo dõi thời gian gỡ. Blocker tồn tại bao lâu chính là metric đo sức khoẻ của team. Thời gian gỡ trung bình dưới 24 giờ là khoẻ; trên 48 giờ nghĩa là có gì đó sai trong cách team flag hoặc escalate.

Template điều chỉnh giữa sprint là gì?

Khi scope đổi giữa sprint, hãy tài liệu hoá thật rõ:

## Điều chỉnh giữa sprint — 2026-06-11

### Trigger bởi
Bug ảnh hưởng khách phát hiện trong luồng refund production.
Sponsor (VP CS) yêu cầu fix sprint này.

### Sprint goal gốc
Ship luồng refund đầu cuối.

### Sprint goal điều chỉnh
1. Fix bug refund production (ưu tiên: hôm nay)
2. Tiếp việc luồng refund sau fix (còn lại sprint)

### Hoãn cái gì
- "Template email refund" hoãn sang sprint kế
- Demo sprint sẽ trình bày tiến độ luồng refund, chưa hoàn thành

### Duyệt bởi
- PM: có
- Sponsor: có (Slack 2026-06-11)
- Team: có (thảo luận standup)

Template này ép việc điều chỉnh phải có ý thức. Khi không có nó, "ai cũng biết là chúng ta đã đổi" - trừ stakeholder không biết, và họ sẽ xuất hiện ở demo với kỳ vọng dự án đã hoàn thành.

Sprint execution scale lên đa team ra sao?

flowchart TB
    TeamA[Standup Team A<br/>15 phút] --> Cross[Sync blocker xuyên team<br/>10 phút, chỉ khi có blocker]
    TeamB[Standup Team B<br/>15 phút] --> Cross
    TeamC[Standup Team C<br/>15 phút] --> Cross
    Cross --> Lead[Project lead route<br/>blocker xuyên team]

Mỗi team vẫn chạy standup riêng. Một buổi sync blocker xuyên team 10 phút chỉ chạy khi có ít nhất một team đang có blocker liên quan đến team khác (thường khoảng 2-3 ngày mỗi tuần). Project lead chủ trì cuộc sync này; các team gửi danh sách blocker của mình tới. Có thể bỏ qua cuộc sync trong những ngày không có gì cần sync - bỏ là dấu hiệu khoẻ mạnh.

Sprint execution có thể tạo ra những lỗi nào?

• Standup biến thành status report. PM ngồi nghe, engineer thì báo cáo cho PM. Cách phòng: PM không đứng ở vị trí trung tâm; engineer đối diện nói với nhau; danh sách blocker là output duy nhất của buổi.
• Danh sách blocker bị bỏ quên. Danh sách vẫn còn đó nhưng không ai cập nhật tuổi. Cách phòng: standup chỉ kết thúc khi danh sách đã được làm mới.
• Thêm việc một cách im lặng giữa sprint. Sponsor thêm việc, team hấp thụ mà không gọi tên đánh đổi. Cách phòng: bất cứ lần thêm việc nào cũng phải kích hoạt template điều chỉnh.
• Phục hồi kiểu anh hùng. Team làm cuối tuần để kịp goal. Một lần là phục hồi; hai lần là văn hoá. Cách phòng: ghi vào retrospective và làm sprint kế tiếp nhỏ hơn.

Khi nào kỷ luật execution chặt là quá liều?

Có hai trường hợp.

Team senior tự tổ chức. Một team senior đã ship cùng nhau nhiều năm có thể cần ít ceremony hơn. Hãy tin team; chỉ can thiệp khi metric đi xuống.

Sprint chỉ có hai người. Hai engineer không cần standup chính thức; một thread Slack đã đủ phủ.

Kỷ luật chỉ thật sự đáng tốn overhead ở quy mô team từ 5 người trở lên và khi blocker thực sự cắt qua nhiều người. Ở mức nhỏ hơn, các nhịp nhẹ vẫn chạy được.

Đi tiếp từ đây như thế nào?

Chương tiếp theo: launch và handover - những gì xảy ra khi chuỗi sprint kết thúc ở một release. Sau đó, incident và rollback sẽ nói về cách xử lý khi launch trục trặc.