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, 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 hàng). Sprint Zero 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 ta gọi nó là "Sprint Zero" hay “Project before the Project” hoặc thậm chí chỉ là “pre-work” thì các công việc "tiền trạm" vẫn cần được hoàn thành. Bí mật ở chỗ, gần như tất cả các văn bản hướng dẫn pre-work 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ắt đầu, thì bạn cần tập trung vào việc làm 5 đ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 để cải thiện vị thế của công ty và giá trị sẽ cung cấp cho thị trường là gì?) thì chưa thể bắt đầu sprint đầu tiên. Trong bất cứ dự án nào, sprint đầu tiên sẽ luôn có một số tầm nhìn,một trong số đó là trăn trở về mục đích phát triển của sản phẩm là gì. Chỉ cần nhớ không đầu tư quá nhiều thời gian 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, và cả những lợi ích khác nhau. Nếu để rơi vào tình trạng này, 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 sản phẩm

Xác định phạm vi của Sprint là công việc của team (ví dụ như đối với dự án dựa trên mô hình Scrum), lý do cho điều này là: Nếu PO tự ý đưa ra phạm vi dự án, mỗi sprint sẽ là một dự án có thể kéo dài tới ... một năm. Thay vào đó, hãy 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, team sẽ phải bắt đầu từ một điểm xác định, thí dụ với product backlog, 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 làm những hạng mục nào trước (sprint backlog), cần bàn giao những gì (deliverable). 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ỏ -  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
(viblo)