Product Increment là tổng những tính năng sản phẩm đã được hoàn tất trong một Sprint và tất cả những Sprint trước đó.
Product Increment thể hiện những giá trị mà sản phẩm có được qua các Sprint
Thật đáng ngạc nhiên là Product Increment, dù được công nhận là 1 trong 3 Scrum Artifacts (Product Backlog, Sprint Backlog, Product Increment) nhưng Scrum Guide chỉ đề cập tới nó khá khiêm tốn so với 2 Artifacts còn lại.
Nếu Product Backlog là công cụ chính của Product Owner, Sprint Backlog là công cụ làm việc hàng ngày của Development Team, thì Product Increment là sự kết nối cuối cùng được để hiện ở Sprint Review khi mà Development Team trình bày những giá trị mình đã đóng góp được cho sản phẩm. Nói cách khác Product Increment là kết quả của sự chuyển hoá Product Backlog thành hiện thực.
Một Tính Năng Làm Được Phân Nửa Có Được Tính Là Product Increment Không?
Scrum không chỉ định rõ rằng chỉ có những gì được hoàn tất theo “Định nghĩa hoàn tất” (Done Definition) đã được cả Scrum Team đồng thuận từ đầu, và bên cạnh đó phải đem lại giá trị cho sản phẩm, khi đó mới được coi là Product Increment. Vì vậy, 1 tính năng chưa được hoàn tất theo định nghĩa trên không được xem là Product increment.
Điều này sẽ thường là vấn đề gây tranh cãi đặc biệt là trong Development Team khi mà họ chính là ngừoi bỏ công bỏ sức vào tính năng của sản phẩm đó, và thực chất là họ cũng đã làm được 50% và Sprint sau chỉ còn cần 50% nữa là hoàn thành, vậy tại sao lại không công nhận “thành tích” của họ?
Nhưng cũng chính vì sự rõ ràng tưởng chừng đến ngặt nghèo này mà Scrum được xem là một mô hình được các công ty ưu chuộng. Đơn giản vì nó hướng cả tập thể chú trọng với việc được tính năng đến với người dùng chứ không phải chỉ lo hoàn thiện bên trong mà không chịu đưa ra sử dụng. Cũng chính vì yêu cầu này, mà Scrum sẽ giúp cho công ty đưa sản phẩm ra thị trường một cách nhanh nhất.
Nếu Đến Khi Sprint Review Mà Product Owner Thay Đổi Ý Định Và Không Chấp Nhận Tính Năng Đã Được Lên Kế Hoạch Từ Đầu Thì Tính Năng Đó Có Được Coi Là Product Increment Không?
Đây cũng là một trong những câu hỏi nhức nhói cho các Scurm Team và nếu xử lý không khéo chúng ta sẽ làm mất niềm tin giữa Product Owner và Development (vốn là cốt lõi để Scrum thật sự có ý nghĩa).
Chúng ta không thể chối cãi một điều là Product Owner là ngừoi ra quyết định sau cùng tính năng nào sẽ được đưa ra cho ngừoi dùng (deploy to Production), và họ cũng là người hiểu rõ về thị trường và người nắm giữ ngân sách. Vì vậy, chúng ta phải tôn trọng ý kiến sau cùng của họ, vì nếu thị trường thay đổi, thì họ có trách nhiệm tiếp tục chỉnh sửa thay đổi.
Tuy nhiên, Product Owner nên hiểu thông báo sự thay đổi vào cuối Sprint đôi khi có thể là quá muộn. Họ hoàn toàn có thể thông báo cho Development Team để cập nhật Sprint Backlog cho phù hợp. Tất nhiên trong trường hợp khẩn cấp Product Owner vẫn là người nắm giữ quyết định huỷ bỏ hoàn toàn 1 Sprint.
