Bài 7 — Scrum Framework — 3-5-3

Mở đầu — vì sao bài này quan trọng

Nếu bạn từng nghe ai đó nói "team mình đang làm Scrum" rồi bạn hỏi lại "vậy team có mấy vai trò, mấy sự kiện, mấy artifact?" mà người ta ấp úng — thì bạn vừa chạm vào lý do bài học này tồn tại.

Scrum, dù được nhắc đến khắp nơi, thực ra là một framework cực kỳ gọn gàng. Toàn bộ "bộ xương" của nó có thể tóm lại bằng một công thức dễ nhớ: 3-5-3. Ba accountabilities (trách nhiệm/vai trò), năm events (sự kiện), ba artifacts (tạo tác). Nhớ được 3-5-3, bạn nắm được cấu trúc đầy đủ của Scrum theo đúng Scrum Guide 2020 — không thừa, không thiếu.

Đây là bài học mang tính "bản đồ tổng thể". Các bài sau trong khóa sẽ đào sâu từng phần: Scrum Master (Bài 8), Product Owner (Bài 9), Developers (Bài 10), Sprint Planning (Bài 11), Daily Scrum (Bài 12), Sprint Review (Bài 13), Retrospective (Bài 14), Product Backlog Refinement (Bài 15), Definition of Done (Bài 16)... Bài 7 này giúp bạn thấy cách tất cả ráp lại với nhau trước khi bạn lao vào chi tiết từng mảnh. Giống như khi học giải phẫu: bạn cần thấy toàn bộ bộ xương trước khi nghiên cứu từng đốt sống.

Tại sao một người làm Project Management lại cần thuộc lòng 3-5-3? Vì rất nhiều "Scrum giả" ngoài thị trường đến từ việc bỏ bớt một mảnh. Bỏ Retrospective thì team không cải tiến. Bỏ vai Product Owner rõ ràng thì backlog hỗn loạn. Bỏ artifact Increment thì Sprint kết thúc mà chẳng có gì "Done". 3-5-3 là danh sách kiểm tra (checklist) tối thiểu để bạn biết mình đang làm Scrum thật hay chỉ đang họp đứng mỗi sáng rồi gọi đó là Agile.

Khái niệm cốt lõi

Scrum là gì trong một câu

Scrum là một framework nhẹ giúp con người, team và tổ chức tạo ra giá trị thông qua các giải pháp thích ứng (adaptive) cho những bài toán phức tạp. Nó dựa trên empiricism (kinh nghiệm thực nghiệm — chúng ta sẽ học sâu ở Bài 6) và lean thinking. Scrum cố tình không đầy đủ — nó chỉ định nghĩa phần khung tối thiểu, còn cách bạn lấp đầy khung đó bằng kỹ thuật, công cụ, quy trình cụ thể là tùy bạn.

Khung tối thiểu đó chính là 3-5-3.

3 Accountabilities — Ba vai trò trong Scrum Team

Lưu ý thuật ngữ: Scrum Guide 2020 đổi từ "roles" sang "accountabilities" (trách nhiệm giải trình) để nhấn mạnh rằng đây là trách nhiệm, không phải chức danh trên danh thiếp. Một Scrum Team là một đơn vị gắn kết, thường không quá 10 người, không có sub-team hay phân cấp bên trong.

1. Product Owner (PO) — chịu trách nhiệm tối đa hóa giá trị của sản phẩm. PO là người quyết định cái gì được làm và theo thứ tự nào. Cụ thể, PO sở hữu Product Backlog: tạo và truyền đạt Product Goal, sắp xếp thứ tự ưu tiên các Product Backlog Item, đảm bảo backlog minh bạch và mọi người hiểu được. PO là một người duy nhất, không phải một ủy ban (dù họ có thể đại diện cho nhiều stakeholder). Khẩu quyết: PO lo value, priority, stakeholder.

2. Scrum Master (SM) — chịu trách nhiệm về hiệu quả của Scrum Team và tính hiệu lực của Scrum. SM là một leader phục vụ (true servant-leader): coach team tự quản và đa năng, gỡ bỏ impediment (vật cản), bảo vệ team khỏi gián đoạn, đảm bảo các sự kiện Scrum diễn ra đúng tinh thần và trong khung thời gian. SM không phải sếp, không giao việc, không phải project manager truyền thống. Khẩu quyết: SM lo process, coaching, remove impediments.

3. Developers — chịu trách nhiệm tạo ra Increment khả dụng mỗi Sprint. Đây là những người làm ra sản phẩm: lập trình viên, tester, designer, BA, DevOps... — bất kỳ ai góp phần xây dựng. Trong Scrum, từ "Developer" mang nghĩa rộng, không chỉ là coder. Developers tự lập kế hoạch công việc (tạo Sprint Backlog), tuân thủ Definition of Done, điều chỉnh kế hoạch mỗi ngày hướng tới Sprint Goal, và chịu trách nhiệm chất lượng. Khẩu quyết: Developers lo how, build, quality.

Ba vai này không phải ba "phòng ban" mà là ba trọng tâm trách nhiệm trong cùng một team gắn bó. Không có vai nào "cao" hơn vai nào.

5 Events — Năm sự kiện

Mọi sự kiện trong Scrum đều là cơ hội để inspect & adapt (thanh tra và thích ứng). Tất cả đều có time-box (khung thời gian cố định) để tránh lãng phí.

Container event — Sprint: Sprint là "trái tim" của Scrum, một khung thời gian cố định kéo dài một tháng hoặc ngắn hơn (thường 1–4 tuần), trong đó một Increment khả dụng được tạo ra. Sprint là vật chứa (container) bao bọc bốn sự kiện còn lại. Sprint mới bắt đầu ngay sau khi Sprint trước kết thúc — không có khoảng trống. Độ dài Sprint nên cố định để tạo nhịp điệu (cadence) ổn định.

Bốn sự kiện bên trong Sprint:

• Sprint Planning — mở màn Sprint. Cả team trả lời: Tại sao Sprint này có giá trị? (Sprint Goal), Có thể Done được gì? (chọn item từ Product Backlog), Sẽ làm thế nào? (lên kế hoạch). Time-box: tối đa 8 giờ cho Sprint 1 tháng, tỷ lệ giảm cho Sprint ngắn hơn.

• Daily Scrum — 15 phút mỗi ngày, dành cho Developers, để kiểm tra tiến độ hướng Sprint Goal và điều chỉnh Sprint Backlog. Đây không phải buổi báo cáo cho sếp; nó là buổi đồng bộ của chính Developers.

• Sprint Review — gần cuối Sprint. Team và stakeholder cùng xem xét kết quả (Increment) và điều chỉnh Product Backlog dựa trên phản hồi. Đây là buổi làm việc, không phải buổi "trình diễn show". Time-box: tối đa 4 giờ cho Sprint 1 tháng.

• Sprint Retrospective — khép lại Sprint. Team nhìn lại cách mình làm việc (con người, quan hệ, quy trình, công cụ) để cải tiến cho Sprint sau. Time-box: tối đa 3 giờ cho Sprint 1 tháng.

Nhớ: Sprint Planning mở đầu, Daily Scrum lặp mỗi ngày ở giữa, Sprint Review rồi Retrospective khép lại. Tất cả nằm gọn trong container Sprint.

3 Artifacts — Ba tạo tác (và commitment đi kèm)

Mỗi artifact trong Scrum 2020 gắn với một commitment (cam kết) để tăng tính minh bạch và tập trung.

• Product Backlog — danh sách có thứ tự, đang tiến hóa, của mọi thứ cần để cải thiện sản phẩm. Đây là nguồn công việc duy nhất cho team. Commitment đi kèm: Product Goal — mục tiêu dài hạn mà team hướng tới.

• Sprint Backlog — gồm Sprint Goal (cái tại sao), tập item được chọn cho Sprint (cái gì), và kế hoạch thực thi (cái như thế nào). Là bức tranh thời gian thực do Developers sở hữu. Commitment đi kèm: Sprint Goal — mục tiêu duy nhất của Sprint.

• Increment — bước tiến cụ thể, khả dụng, hướng tới Product Goal. Mỗi Increment cộng dồn với các Increment trước. Một Increment chỉ được coi là hữu ích khi nó đạt Definition of Done (DoD) — đây chính là commitment đi kèm artifact này (chúng ta sẽ học sâu DoD ở Bài 16).

Bảng tóm tắt nhanh để bạn ghim vào đầu:

Tình huống thực tế

Ví dụ 1 — Tiki: khi "team Scrum" thiếu mất một mảnh của 3-5-3

Giả định một team 7 người tại một công ty thương mại điện tử như Tiki, phụ trách tính năng "gợi ý sản phẩm". Họ tự nhận đang làm Scrum: có họp đứng mỗi sáng, có Sprint 2 tuần, có Jira board. Nhưng sau 4 Sprint, sản phẩm vẫn ì ạch và team mệt mỏi.

Khi soi qua lăng kính 3-5-3, vấn đề lộ ra ngay: họ có Daily Scrum, Sprint Planning, Sprint Review — nhưng bỏ luôn Retrospective vì "tốn thời gian, ai cũng bận". Hệ quả: cùng một lỗi lặp đi lặp lại — môi trường staging hay sập, ước lượng luôn sai — mà không ai dừng lại để xử lý gốc rễ. Thiếu một event trong "5", cỗ máy cải tiến của Scrum bị tháo mất bánh răng.

Bài học: 3-5-3 là một bộ tối thiểu. Bỏ bất kỳ mảnh nào, bạn không còn làm Scrum đầy đủ nữa, dù vẫn gọi tên là Scrum. Sau khi team khôi phục Retrospective 1 giờ mỗi cuối Sprint, ba Sprint sau họ tự sửa được quy trình deploy và độ chính xác ước lượng tăng rõ rệt.

Ví dụ 2 — Startup fintech ở TP.HCM: lẫn lộn vai Scrum Master và Product Owner

Một startup fintech khoảng 30 người ở quận 1, TP.HCM. Vì tiết kiệm nhân sự, anh Trưởng phòng Sản phẩm kiêm luôn cả Product Owner lẫn Scrum Master cho team 6 developer. Nghe thì "đa năng", nhưng thực tế tạo ra xung đột lợi ích kinh điển.

Là PO, anh ấy bị áp lực giao tính năng nhanh cho stakeholder, nên liên tục nhồi thêm việc vào Sprint đang chạy. Là SM, lẽ ra anh ấy phải bảo vệ team khỏi đúng kiểu can thiệp đó. Hai trách nhiệm này kéo về hai hướng đối nghịch, và khi gom vào một người, vai SM luôn thua. Team bị ép việc liên tục, Sprint Goal vô nghĩa, và sau 3 tháng hai developer giỏi nghỉ việc.

Họ sửa bằng cách tách vai: anh Trưởng phòng giữ PO, một developer kỳ cựu được train làm SM bán thời gian. Ngay Sprint kế tiếp, scope-creep giữa Sprint giảm hẳn vì giờ đã có người nói "không" thay cho team.

Bài học: Ba accountabilities tồn tại tách biệt là có chủ đích. PO tối đa hóa giá trị (đẩy việc vào), SM bảo vệ tính lành mạnh của quy trình (kiểm soát việc đẩy vào). Gộp hai vai mâu thuẫn này vào một người sẽ làm hỏng cơ chế cân bằng của Scrum.

Ví dụ 3 — Agency phần mềm Đà Nẵng: Increment "Done một nửa"

Một agency outsourcing ở Đà Nẵng làm dự án cho khách Nhật. Mỗi Sprint Review, team trình diễn tính năng chạy mượt trên máy lập trình viên, khách hài lòng, Sprint được coi là thành công. Nhưng đến khi gom lại để release thật, mọi thứ vỡ: chưa viết test, chưa xử lý lỗi, chưa làm tài liệu API — vì những việc đó không nằm trong định nghĩa "xong" của ai cả.

Vấn đề nằm ở artifact Increment và commitment Definition of Done của nó. Team không có DoD thống nhất, nên "Done" với mỗi người một nghĩa. Increment trông như đã hoàn thành nhưng thực ra chỉ là demo, không phải sản phẩm khả dụng.

Họ khắc phục bằng một DoD chung dán ngay trên tường: code review xong, unit test pass, chạy được trên staging, tài liệu cập nhật. Từ đó, "Done" trong Sprint Review nghĩa là thật sự dùng được, không còn nợ kỹ thuật giấu sau lưng.

Bài học: Artifact chỉ minh bạch khi đi kèm commitment. Increment mà thiếu Definition of Done sẽ tạo ra ảo giác tiến độ — bạn tưởng đã đi 80% chặng đường, nhưng 80% đó chưa được tính đúng.

Hướng dẫn từng bước

Nếu bạn đang setup hoặc kiểm tra một team theo chuẩn 3-5-3, hãy đi theo trình tự sau:

• Xác lập 3 accountabilities trước. Chỉ định đúng một Product Owner (một người, có quyền quyết priority). Chỉ định một Scrum Master. Xác định nhóm Developers (gồm mọi kỹ năng cần thiết để tạo Increment — cross-functional). Viết rõ ai chịu trách nhiệm gì, dán công khai.

• Chốt độ dài Sprint. Chọn 1, 2, 3 hoặc 4 tuần và giữ cố định. Với team mới, 2 tuần là điểm khởi đầu phổ biến vì đủ ngắn để học nhanh, đủ dài để hoàn thành thứ có ý nghĩa.

• Lên lịch cố định cho 4 event con. Đặt sẵn trên calendar: Planning đầu Sprint, Daily Scrum mỗi ngày cùng giờ cùng chỗ, Review và Retrospective cuối Sprint. Nhịp điệu cố định giúp team không phải hỏi "khi nào họp" mỗi lần.

• Tạo Product Backlog và đặt Product Goal. PO dẫn dắt, sắp xếp thứ tự. Mọi việc team làm phải truy được về backlog này — không có "việc ngoài luồng".

• Mỗi Sprint Planning, sinh ra Sprint Goal + Sprint Backlog. Bắt đầu từ "tại sao" (Sprint Goal) rồi mới đến "cái gì" và "như thế nào".

• Định nghĩa Definition of Done ngay từ đầu. Trước Sprint đầu tiên, cả team thống nhất "Done nghĩa là gì". Đây là điều kiện để Increment có giá trị thật.

• Mỗi cuối Sprint, kiểm Increment theo DoD, rồi Review và Retrospective. Review để điều chỉnh sản phẩm; Retrospective để điều chỉnh cách làm việc. Đừng gộp hai buổi này làm một.

• Lặp lại. Sprint mới bắt đầu ngay. 3-5-3 không phải làm một lần — nó là vòng lặp.

Lỗi thường gặp & mẹo

Lỗi: Daily Scrum biến thành buổi báo cáo cho sếp. Khi quản lý đứng nghe và mỗi người lần lượt "báo cáo lên", buổi họp mất ý nghĩa đồng bộ. Mẹo: Daily Scrum thuộc về Developers; họ nói chuyện với nhau về tiến độ hướng Sprint Goal, không phải với quản lý.

Lỗi: bỏ Retrospective khi bận. Đây là event hay bị cắt nhất, và cũng là event khiến team ngừng tiến bộ nhanh nhất khi mất. Mẹo: coi Retrospective là bất khả xâm phạm. Một team không cải tiến là một team đang thụt lùi.

Lỗi: gộp vai hoặc làm mờ ranh giới accountabilities. Đặc biệt là PO kiêm SM (như ví dụ 2). Mẹo: nếu thiếu người, thà để SM kiêm nhẹ phần Developer còn hơn gộp PO với SM — vì PO và SM có lợi ích đối nghịch.

Lỗi: Sprint không có Increment khả dụng. Sprint trôi qua mà chẳng có gì "Done" thực sự. Mẹo: mọi Sprint phải tạo ra một Increment đạt DoD, dù nhỏ.

Lỗi: đổi độ dài Sprint liên tục. Tuần này 1 tuần, tuần sau 3 tuần. Mẹo: giữ cadence cố định để velocity và nhịp làm việc ổn định.

Lỗi: Sprint Review thành buổi "diễn". Chỉ trình chiếu slide đẹp, không lấy phản hồi thật và không cập nhật backlog. Mẹo: Review là buổi làm việc cộng tác với stakeholder để điều chỉnh hướng đi.

Mẹo ghi nhớ tổng: Mỗi khi nghi ngờ team có đang làm Scrum thật không, hãy chạy checklist 3-5-3 trong đầu. Đếm đủ 3 vai, 5 sự kiện, 3 artifact với 3 commitment. Thiếu cái nào, đó chính là chỗ cần sửa.

Bài tập thực hành

• Tự kiểm tra trí nhớ: Không nhìn lại bài, hãy viết ra giấy đầy đủ 3 accountabilities, 5 events, 3 artifacts (kèm commitment của từng artifact). Sau đó đối chiếu với bảng tóm tắt ở trên. Đây là kiến thức nền bạn cần thuộc nằm lòng cho mọi bài sau.

• Audit một team thật: Chọn một team bạn biết (nơi bạn làm, hoặc một dự án bạn từng tham gia). Lập bảng 3-5-3 và đánh dấu: mảnh nào có, mảnh nào thiếu, mảnh nào "có tên nhưng làm sai tinh thần". Viết 3 câu kết luận về sức khỏe Scrum của team đó.

• Tình huống xử lý: Một PO yêu cầu chèn thêm tính năng vào giữa Sprint đang chạy. Dựa vào 3 accountabilities, hãy viết cách Scrum Master nên phản hồi, và giải thích tại sao Sprint Goal lại quan trọng ở đây.

• Ghép cặp event–mục đích: Với mỗi event trong "5", viết một câu duy nhất trả lời "event này tồn tại để inspect cái gì và adapt cái gì?". Ví dụ: Retrospective inspect cách làm việc, adapt quy trình của Sprint sau.

Tóm tắt

• Scrum là một framework nhẹ, cố tình tối giản, và toàn bộ khung của nó gói trong công thức 3-5-3.
• 3 accountabilities: Product Owner (giá trị, priority, stakeholder), Scrum Master (quy trình, coaching, gỡ vật cản), Developers (cách làm, xây dựng, chất lượng). Ba vai tách biệt là có chủ đích — đừng gộp PO với SM.
• 5 events: Sprint là container; bên trong có Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective. Mỗi event là một cơ hội inspect & adapt với time-box rõ ràng.
• 3 artifacts: Product Backlog (commitment: Product Goal), Sprint Backlog (commitment: Sprint Goal), Increment (commitment: Definition of Done). Artifact không có commitment thì mất minh bạch.
• 3-5-3 là checklist tối thiểu để phân biệt Scrum thật với "họp đứng rồi gọi là Agile". Thiếu mảnh nào, đó chính là chỗ đang hỏng.
• Bài này là bản đồ tổng thể; các bài 8–16 sẽ đào sâu từng vai trò, sự kiện và artifact. Hãy thuộc bộ khung trước khi bước vào chi tiết.