Mở đầu — vì sao bài này quan trọng
Nếu Product Backlog là tấm bản đồ và Sprint Backlog là lộ trình của chuyến đi tuần này, thì Increment chính là quãng đường thật mà bạn đã đi được — không phải kế hoạch, không phải lời hứa, mà là kết quả hữu hình, có thể chạm tay vào. Trong toàn bộ Scrum framework, Increment là artifact duy nhất trả lời câu hỏi tối thượng của mọi dự án: "Rốt cuộc thì chúng ta đã tạo ra giá trị gì?"
Với kỳ thi PSM I, Increment là một chủ đề mà người ra đề rất thích "gài". Lý do là vì nhiều người học Scrum theo bản năng nghĩ rằng Increment chỉ là "phần code làm xong trong Sprint" — và đó là một hiểu lầm tốn điểm. Họ quên rằng Increment gắn chặt với một commitment cụ thể là Definition of Done (DoD), rằng một Increment có thể được tạo ra nhiều lần trong một Sprint, và rằng việc một công việc "hoàn thành" theo nghĩa thông thường khác hoàn toàn với "Done" theo nghĩa Scrum.
Trong bài này, chúng ta sẽ mổ xẻ Increment ở cả hai khía cạnh: nó là một Artifact (sản phẩm hữu hình của sự minh bạch) và nó mang theo một Commitment là Definition of Done (lời cam kết về chất lượng). Hiểu vững bài này, bạn không chỉ trả lời đúng các câu hỏi PSM I về artifact, mà còn nắm được tinh thần "empiricism" — chỉ những thứ Done mới đáng tin để đưa ra quyết định.
Khái niệm cốt lõi
Increment là gì — định nghĩa "by the book"
Theo Scrum Guide 2020, một Increment là "a concrete stepping stone toward the Product Goal" — một bậc thang cụ thể, hữu hình tiến tới Product Goal. Hãy chú ý ba từ khóa trong định nghĩa này:
- Concrete (cụ thể, hữu hình): Increment không phải là tài liệu thiết kế, không phải bản demo "giả lập", không phải lời hứa. Nó là phần sản phẩm thực sự hoạt động.
- Stepping stone (bậc thang): Mỗi Increment là một bước tiến. Nó không phải đích đến, mà là một nấc thang trên con đường dẫn tới Product Goal.
- Toward the Product Goal: Increment luôn có hướng đi. Một Increment không liên quan gì tới Product Goal là một dấu hiệu của vấn đề.
- Each Increment is additive to all prior Increments — Mỗi Increment cộng dồn vào tất cả các Increment trước đó. Increment không thay thế cái cũ; nó xây thêm lên cái cũ. Sau Sprint 5, bạn không có "Increment của Sprint 5" tách rời — bạn có toàn bộ sản phẩm tích lũy đến thời điểm đó.
- All Increments work together — Các Increment phải hoạt động ăn khớp với nhau. Để đảm bảo điều này, chúng phải được verified thoroughly (kiểm chứng kỹ lưỡng), đảm bảo tất cả các Increment làm việc cùng nhau một cách trơn tru.
Một sự thật khiến nhiều người bất ngờ: nhiều Increment trong một Sprint
Đây là điểm mà PSM I rất hay kiểm tra. Nhiều người tin rằng "một Sprint = một Increment". Sai. Scrum Guide nói rõ:
> "Multiple Increments may be created within a Sprint."
Trong một Sprint, đội có thể tạo ra nhiều Increment. Mỗi khi một hạng mục của Product Backlog đạt được Definition of Done, một Increment ra đời. Nghĩa là nếu trong Sprint bạn hoàn thành 7 Product Backlog Items, bạn có thể đã tạo ra nhiều Increment liên tiếp trong suốt Sprint, chứ không phải chờ đến cuối Sprint mới "gộp" lại thành một.
Sprint Review KHÔNG phải là điểm để "phát hành" Increment
Một điểm tinh tế nữa: Scrum Guide nói "The sum of the Increments is presented at the Sprint Review" — tổng các Increment được trình bày tại Sprint Review. Nhưng câu quan trọng là:
> "However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value."
Increment có thể được giao cho stakeholder bất cứ lúc nào trong Sprint, ngay khi nó Done. Sprint Review không bao giờ được coi là một "cổng" để phát hành giá trị. Đây là điểm phân biệt Scrum hiện đại với cách hiểu cũ kỹ "phải chờ cuối Sprint mới release".
Increment và Commitment của nó: Definition of Done
Đây là phần xương sống của bài. Mỗi artifact trong Scrum gắn với một commitment để tăng tính minh bạch và tập trung:
| Artifact | Commitment |
|---|---|
| Product Backlog | Product Goal |
| Sprint Backlog | Sprint Goal |
| Increment | Definition of Done |
> "The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product."
DoD là mô tả chính thức về trạng thái của Increment khi nó đạt các tiêu chuẩn chất lượng cần thiết của sản phẩm. Và đây là quy tắc vàng:
> "The moment a Product Backlog item meets the Definition of Done, an Increment is born."
Khoảnh khắc một hạng mục Product Backlog đạt Definition of Done, một Increment ra đời. Ngược lại — và điều này cực kỳ quan trọng cho kỳ thi:
> "If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration."
Nếu một hạng mục không đạt DoD, nó không thể được release, không thể được trình bày tại Sprint Review, mà phải quay lại Product Backlog để xem xét trong tương lai. Không có khái niệm "90% Done" trong Scrum. Hoặc Done, hoặc không Done.
Ai sở hữu Definition of Done?
Nếu DoD là một phần của tiêu chuẩn tổ chức, tất cả các Scrum Team phải tuân theo nó tối thiểu. Nếu không phải là tiêu chuẩn của tổ chức, thì Scrum Team (cụ thể là các Developers) phải tự tạo ra Definition of Done phù hợp với sản phẩm. Đây là điểm hay bị nhầm: DoD không phải do Product Owner hay Scrum Master "ban xuống". Developers là người chịu trách nhiệm tuân thủ DoD, và họ tham gia định nghĩa nó. (Chúng ta sẽ đào sâu riêng về DoD ở Bài 20, nên ở đây chỉ cần nắm mối quan hệ Increment ↔ DoD.)
Tình huống thực tế
Tình huống 1 — Tiki và bài học "Done vs gần Done"
Hãy hình dung một đội phát triển tính năng "đặt hàng nhanh bằng một chạm" tại một sàn thương mại điện tử lớn như Tiki. Sprint kéo dài 2 tuần, và đội cam kết hoàn thành 8 Product Backlog Items.
Đến ngày Sprint Review, một Developer hồ hởi báo cáo: "Tính năng one-tap checkout đã code xong, chạy ngon trên máy em, chỉ còn chờ team QA test integration và viết unit test là xong thôi ạ." Definition of Done của đội này yêu cầu: code review xong, unit test coverage tối thiểu 80%, pass integration test, không có lỗi P1/P2 tồn đọng, và đã merge vào nhánh release.
Vậy tính năng one-tap checkout này có phải là một phần của Increment không? Không. Dù đã "code xong", nó chưa pass integration test, chưa có unit test đầy đủ. Theo Scrum, nó chưa Done, nên nó không được tính vào Increment, không được trình bày tại Sprint Review như một việc đã hoàn thành, và phải quay về Product Backlog.
Bài học rút ra: "Chạy được trên máy em" không phải là Done. Nếu đội quen với việc "gần Done cũng tính là Done", họ sẽ tích lũy một đống "undone work" — nợ kỹ thuật ẩn. Tính minh bạch (transparency) bị phá vỡ, vì Sprint Review báo cáo một mức tiến độ ảo. Tinh thần empiricism sụp đổ khi quyết định dựa trên dữ liệu không trung thực.
Tình huống 2 — Một startup fintech ở TP.HCM giao Increment giữa Sprint
Một startup fintech tại Quận 1, TP.HCM, đang xây ứng dụng quản lý chi tiêu. Sprint của họ dài 3 tuần. Trong Sprint thứ 4, đội hoàn thành tính năng "thông báo đẩy khi vượt ngân sách" vào đúng ngày thứ 6 của Sprint — nó đạt đầy đủ Definition of Done.
Product Owner nhìn thấy giá trị tức thì: nhiều người dùng đang phàn nàn vì xài quá tay mà không biết. Cô quyết định phát hành tính năng này ngay lập tức cho 5.000 người dùng beta, thay vì chờ 15 ngày nữa đến Sprint Review.
Một thành viên mới trong đội thắc mắc: "Ơ, mình release giữa Sprint vậy có đúng Scrum không? Em tưởng phải chờ Sprint Review chứ?"
Câu trả lời: Hoàn toàn đúng Scrum. Như Scrum Guide nói rõ, "an Increment may be delivered to stakeholders prior to the end of the Sprint" và "the Sprint Review should never be considered a gate to releasing value." Khi một Increment đã Done, nó là sản phẩm thật, có thể giao bất cứ lúc nào.
Bài học rút ra: Sprint Review là nơi để inspect và adapt dựa trên Increment, không phải là cổng phát hành. Đội nào bị "kẹt" vào tư duy "chờ cuối Sprint mới release" đang tự trói tay mình và làm chậm dòng chảy giá trị tới khách hàng.
Tình huống 3 — Đội game studio ở Đà Nẵng và "Increment additive"
Một studio làm game mobile ở Đà Nẵng đang phát triển một tựa game nhập vai. Qua các Sprint, họ lần lượt làm: Sprint 1 hệ thống nhân vật, Sprint 2 hệ thống chiến đấu, Sprint 3 hệ thống nhiệm vụ.
Đến Sprint 3, khi hoàn thành hệ thống nhiệm vụ, đội phát hiện một bug: việc nhận thưởng từ nhiệm vụ làm hỏng hệ thống chiến đấu đã làm ở Sprint 2 (chỉ số nhân vật bị reset sai). Một Developer định kệ nó: "Hệ thống nhiệm vụ tự nó chạy ngon mà, phần chiến đấu là việc của Sprint trước rồi."
Sai lầm. Nguyên tắc "each Increment is additive to all prior Increments, and all Increments work together" đòi hỏi Increment mới phải hoạt động ăn khớp với toàn bộ Increment trước đó. Một Increment phá vỡ chức năng cũ thì chưa phải là Increment Done. Nó phải được verified thoroughly với toàn bộ sản phẩm tích lũy.
Bài học rút ra: Increment không phải là những mảnh ghép rời rạc cộng lại. Nó là một sản phẩm tích hợp, liền mạch, lớn dần. Đây chính là lý do "integration" và "verification" phải nằm trong Definition of Done — để đảm bảo tổng thể luôn hoạt động.
Hướng dẫn từng bước
Dưới đây là cách tư duy đúng về Increment trong thực tế (và để trả lời PSM I):
- Bắt đầu từ Product Backlog Item. Mỗi PBI khi được hoàn thành sẽ trở thành (một phần của) Increment — nhưng chỉ khi nó đạt DoD.
- Kiểm tra với Definition of Done. Đặt câu hỏi: PBI này đã đáp ứng tất cả tiêu chí trong DoD chưa? Code review, test, tích hợp, không lỗi nghiêm trọng tồn đọng? Nếu thiếu dù một tiêu chí — chưa Done.
- Khi đạt DoD → một Increment ra đời. Ngay khoảnh khắc đó. Không cần chờ cuối Sprint. Bạn có thể có nhiều Increment trong một Sprint.
- Verify với toàn bộ Increment trước đó. Increment mới phải additive và hoạt động ăn khớp với mọi thứ đã có. Tích hợp và kiểm chứng kỹ lưỡng.
- Có thể release bất cứ lúc nào. Nếu Increment đã Done và có giá trị cho stakeholder, Product Owner có thể quyết định giao nó ngay — không cần đợi Sprint Review.
- Trình bày tổng các Increment tại Sprint Review. Đây là nơi để inspect Increment cùng stakeholder và adapt Product Backlog — không phải nơi "xin phép release".
- Xử lý phần chưa Done. Bất kỳ PBI nào không đạt DoD đều quay lại Product Backlog. Không tính vào Increment, không demo như việc đã xong.
Lỗi thường gặp & mẹo
Lỗi 1: Nghĩ "một Sprint = một Increment". Sai. Nhiều Increment có thể ra đời trong một Sprint. Mỗi PBI đạt DoD là một Increment.
Lỗi 2: Coi "code xong" là "Done". Done được định nghĩa bởi DoD, không phải cảm giác cá nhân. "Chạy trên máy em" không phải tiêu chuẩn Scrum.
Lỗi 3: Tin rằng Increment phải được release tại Sprint Review. Sai. Sprint Review không phải là cổng release. Increment Done có thể giao bất cứ lúc nào trong Sprint.
Lỗi 4: Demo việc chưa Done tại Sprint Review. Việc chưa đạt DoD không được trình bày như đã xong, và phải quay về Product Backlog.
Lỗi 5: Nhầm chủ sở hữu DoD. Nếu tổ chức không có tiêu chuẩn chung, chính Scrum Team (Developers) tạo DoD — không phải Product Owner hay sếp ra lệnh.
Mẹo ghi nhớ cho PSM I:
- Increment ↔ Commitment là Definition of Done. Học thuộc cặp này.
- Câu thần chú: "The moment a Product Backlog item meets the Definition of Done, an Increment is born."
- Nhớ ba cụm: concrete stepping stone, additive, verified thoroughly.
- Increment chưa Done → quay lại Product Backlog, không bao giờ release hay demo như đã xong.
- Sprint Review không bao giờ là gate to releasing value.
Bài tập thực hành
- Tự định nghĩa Increment bằng một câu (không nhìn tài liệu), bao gồm cụm "concrete stepping stone toward the Product Goal". So sánh với Scrum Guide.
- Tình huống phán đoán: Đội bạn hoàn thành 6/8 PBI đạt DoD; 2 PBI còn lại đã "code xong" nhưng chưa qua integration test. Trả lời: Increment gồm bao nhiêu PBI? 2 PBI kia đi đâu? Có được demo tại Sprint Review không?
- Đếm Increment: Trong một Sprint 2 tuần, đội hoàn thành (đạt DoD) lần lượt 5 PBI vào các ngày khác nhau. Theo Scrum Guide, có thể nói đã tạo ra "nhiều Increment" trong Sprint này không? Giải thích bằng câu trích từ Scrum Guide.
- Viết một bộ DoD giả định cho một ứng dụng web (tối thiểu 5 tiêu chí), rồi tự hỏi: nếu thiếu một tiêu chí, PBI đó có phải Increment không?
- Tranh luận: Một đồng nghiệp nói "Phải chờ Sprint Review mới được release Increment cho khách." Hãy viết 3 câu phản biện dựa trên Scrum Guide.
Tóm tắt
- Increment là một Artifact — "a concrete stepping stone toward the Product Goal", phần sản phẩm hữu hình, hoạt động được.
- Mỗi Increment additive vào tất cả Increment trước, và tất cả phải work together, được verified thoroughly.
- Nhiều Increment có thể được tạo ra trong một Sprint; tổng của chúng được trình bày tại Sprint Review.
- Commitment của Increment là Definition of Done. Khoảnh khắc một PBI đạt DoD, một Increment ra đời.
- PBI không đạt DoD thì không được release, không được demo như đã xong, và phải quay lại Product Backlog.
- Increment Done có thể giao cho stakeholder bất cứ lúc nào; Sprint Review không bao giờ là cổng để release giá trị.
- Increment là biểu hiện cao nhất của transparency và empiricism: chỉ thứ thật sự Done mới đáng tin để đưa ra quyết định.