Khái niệm "Sprint Zero" hoặc "Iteration Zero" đã tồn tại trong nhiều thập kỷ. Nó như là một thùng chứa tất cả các hoạt động cần được thực hiện trước Sprint đầu tiên. Thông thường, các hoạt động này sẽ bao gồm cả việc xây dựng team, thiết lập cơ sở hạ tầng, vị trí hậu cần và những thứ tương tự khác. Hiếm khi sprint zero này thực sự mang lại một sản phẩm có thể bàn giao được. Đây là một chủ đề gây tranh cãi. Nhiều người cho rằng Sprint Zero là bất lợi cho agile process. Trong một số trường hợp, nó có thể dẫn đến water fall trong cam kết của team đối với khả năng bàn giao của mỗi sprint. Trong các trường hợp khác, nó có thể khiến hình thành một hệ thống team phân cấp mà không phù hợp với cơ cấu tổ chức của Agile (tổ chức phẳng- các vai trò ngang hang). Nó thường không phù hợp với các nguyên tắc Lean. Cho dù chúng ta có thích khái niệm Sprint Zero hay không, tuy nhiên, chúng ta có thể đồng ý rằng có những công việc thường phải làm để chuẩn bị cho sprint đầu tiên mà không hoàn toàn thuộc về sprint đầu tiên đó. Cho dù chúng tôi gọi nó là "Sprint Zero" hay “Project before the Project” hoặc thậm chí chỉ là “pre-work” thì nó vẫn cần được hoàn thành. Thật không may, gần như tất cả các văn bản về pre-work này là hướng tới các thành viên của nhóm phát triển. Còn đối với Product Owner thì họ làm gì. Nếu bạn là Product Owner, trong khi nhóm đang thực hiện tất cả các nhiệm vụ trước khi dự án, bạn cần tập trung vào việc làm năm điều quan trọng dưới đây.

1: Phát triển Tầm nhìn Sản phẩm

Nếu PO không có một tầm nhìn vững chắc về sản phẩm (làm thế nào nó sẽ cải thiện vị thế của công ty và giá trị nó sẽ cung cấp cho thị trường) thì đó không phải là một ý tưởng tốt để bắt đầu sprint đầu tiên. Cho dù nó được thực hiện có chủ ý hay không, sprint đầu tiên thực sự sẽ có một số tầm nhìn, và tốt nhất thì một trong số đó là mục đích phát triển. Chỉ cần nhớ không đầu tư quá nhiều vào tầm nhìn ban đầu này, dù là về thời gian hay cam kết. Tầm nhìn ban đầu gần như luôn luôn là sai ở một mức độ nào đó, và nó sẽ là công việc của PO để đảm bảo rằng nhóm đang xây dựng đúng sản phẩm cho thị trường. Điều này thường đòi hỏi PO thiết lập các giả định ban đầu.

2: Xã hội hóa Tầm nhìn Sản phẩm

Một khi đã có được một tầm nhìn ban đầu, điều quan trọng là PO phải thảo luận với các stakeholder. Trong một môi trường đơn giản, stakeholder có thể chỉ bao gồm các đại diện khách hàng và các bên liên quan triển khai công nghệ. Nếu trong một môi trường có quy mô thì có thể sẽ có thêm một đội ngũ quản lý sản phẩm và nhiều nhóm chức năng khác cần làm việc cùng. Tại sao công việc này rất quan trọng? Bởi vì ngay sau khi dự án bắt đầu sẽ không có thời gian để bảo vệ tầm nhìn của sản phẩm đối với các bên liên quan vì họ có thể có những quan điểm khác biệt. Nếu để rơi vào tình trạng này, nó sẽ trở nên rất khó khăn đối với các bên liên quan, đối với việc quản lý và đặc biệt là đối với team. PO phải duy trì sự tôn trọng đối với quyền sở hữu sản phẩm của mình, và việc xã hội hoá tầm nhìn ngay từ ban đầu sẽ là một trong những cách dễ dàng nhất để giải quyết vấn đề này.

3: Hiểu rõ vấn đề của các bên liên quan (stakeholder)

Trên thực tế, nhiệm vụ này nghe có vẻ to lớn. Liệu PO có thể thực sự hiểu những vấn đề của stakeholder đến mức mình mong muốn? Tất nhiên là không rồi. Tuy nhiên, điều bắt buộc là phải đủ hiểu để có thể bắt đầu phân phối sản phẩm đáp ứng được nhu cầu của họ. Rốt cuộc, PO sẽ sớm thay mặt stakeholder để quyết định. Những điều tối thiểu PO cần hiểu bao gồm

• Sự hiểu biết về khách hàng (hoặc người dùng cuối): họ là ai, các danh mục khác nhau của họ và cách bạn mong đợi họ tương tác với sản phẩm của bạn.
• Sự hiểu biết về động cơ của khách hàng để mua (hoặc chấp nhận) sản phẩm của bạn, cách thức và lý do tại sao nhu cầu của họ chưa được đáp
• Một ý tưởng tốt về những gì họ đánh giá và cách họ nhìn bản thân họ Nếu PO có những trao đổi hợp lý về những vấn đề trên thì Sprint đầu tiên có thể bắt đầu. Hãy nhớ tiếp tục tìm hiểu về các bên liên quan trong quá trình làm việc

4: Tạo ra một số ý tưởng cho một sản phẩm Sprint

Xác định phạm vi của sprint là công việc của team (ít nhất là trong Scrum), và có lý do tốt cho điều này: Nếu PO xác định những gì có trong phạm vi dự án, mỗi sprint sẽ là một dự án kéo dài một năm. Thay vào đó, thì cho phép team những người hiểu về dự án được thực hiện việc này. Tuy nhiên, mỗi team sẽ phải bắt đầu từ đâu đó, điển hình là với product backlong, và bạn cần có danh sách các item trong product backlog để team có thể lên kế hoạch xem họ cần bàn giao những gì. Những gì bạn cần trước cuộc họp planning meeting đầu tiên là một tập hợp các ý tưởng nhỏ cái mà sẽ cung cấp một mức giá trị tối thiểu cho doanh nghiệp của khách hàng.

5: chỉ viết đủ User Story để hỗ trợ cho lần đầu tiên Release.

Một khi bạn có danh sách những ý tưởng nhỏ, hãy chọn một vài ý tưởng và biến chúng thành user story. Bạn sẽ có nhiều thời gian để giải thích chi tiết về các user story này sau, nhưng nếu bạn có một vài lựa chọn và có thể viết chúng ra thì bạn sẽ có một điều kiện tốt để có một buổi sprint planning meeting tuyệt vời trước khi sprint bắt đầu. Một vài lời khuyên ở đây:

• Đừng tạo quá nhiều User story. Bạn nên gặp team trước khi dành quá nhiều thời gian để viết chúng
• Giữ cho user story ngắn gọn không quá chi tiết.
• Đừng lo lắng về các chủ đề lớn hơn (như story map hay road map) ở giai đoạn này. Bạn sẽ không có đủ nội dung để lấp đầy và làm chi tiết chúng.

Nguồn: https://www.frontrowagile.com/blog/posts/125-sprint-zero-for-product-owners