Mục tiêu của Sprint là gì

Sprint Planning là gì?

Một Sprint bắt đầu bằng buổi lập kế hoạch Sprint để xác định mục tiêu và lên kế hoạch chi tiết cho những công việc cần thực hiện. Buổi Sprint Planning này sẽ lần lượt trả lời các câu hỏi chính:

• Mục tiêu của Sprint này là gì?
• Sprint này team mình cần chuyển giao cái gì?
• Làm sao để team mình đạt được kết quả như mong muốn?
  

Diễn biến một buổi làm kế hoạch Sprint thường như sau:

1. What: Product Owner trình bày tầm nhìn về sản phẩm, mục tiêu Sprint. Nhóm phát triển hỏi kỹ về các hạng mục cũng như mục tiêu

2. How: Nhóm phát triển thảo luận, phân tích và dùng kỹ thuật để bẻ nhỏ thành Sprint Backlog, có thể trao đổi với PO

‍

Ai tham gia Sprint Planning?

Toàn bộ nhóm bắt buộc cần tham gia phần thứ nhất ở sự kiện - tức xác định Mục tiêu của Sprint bao gồm Product Owner, Scrum Master và Nhóm phát triển. Tuy nhiên nếu Product Owner đã phân quyền và giao cho team quyền tự chủ quyết định việc mình sẽ làm trong mục tiêu ngắn (ví dụ tháng/quý) thì team hoàn toàn chủ động làm được phần này.

Phần thứ 2, Product Owner có thể vắng mặt, nhưng luôn cần ở trạng thái sẵn sàng support để làm rõ cho nhóm các hạng mục quan trọng. Nếu không có thể có mặt, có thể trả lời qua online hoặc qua điện thoại, tránh để mất thời gian chờ đợi nhau.

Sprint Planning dài bao lâu?

Timebox là yếu tố cực kỳ quan trọng của các buổi họp. Điều quan trọng là chúng ta có kết quả và bước tiếp theo cần phải làm gì sau mỗi cuộc họp chứ không phải muốn họp đến lúc nào thì họp. Thông thường,

Với sprint 1 tháng, buổi kế hoạch Sprint kéo dài 8 tiếng

Với sprint 2 tuần, buổi kế hoạch Sprint kép dài 4 tiếng

Và như tại Magestore, sprint 1 tuần, buổi kế hoạch Sprint không kéo dài hơn 2 tiếng. Trong đó 1 tiếng dành cho việc xác định mục tiêu và thời gian còn lại dành cho việc tìm/trao đổi và xác định cách thực hiện.

Minh hoạ thời gian Sprint Planning tương ứng với độ dài của Sprint (Internet)

‍

Product Backlog Đầu vào của Sprint Planning

Không phải cứ đến giờ Sprint Planning, Product Owner hoặc cả team mới xác định Sprint này làm gì. Thông thường việc phát triển sản phẩm có roadmap khá rõ ràng với những milestone cụ thể, mục tiêu đạt được rõ ràng. Điều này được phản ánh thông qua các buổi Định hướng sản phẩm, Product Planning và sau đó được Product Owner chia sẻ lại với team thông qua công cụ Product Backlog, và đây cũng sẽ là đầu vào của hoạt động Sprint Planning.

Product Backlog là danh sách các tính năng mong muốn của sản phẩm. Danh sách được sắp xếp dựa trên độ ưu tiên của từng hạng mục. Các hạng mục được ưu tiên sẽ được để ở trên, và được nhóm Phát triển ưu tiên pick chọn. Product Backlog trong team Triển khai sản phẩm, sẽ thường là các nhiệm vụ của các Project khách hàng. Tuỳ vào mốc thời gian đã cam kết với khách hàng, các nhiệm vụ này sẽ được sắp xếp theo các thứ tự ưu tiên khác biệt.

Product Backlog có thể được quản lý trên Google Spreadsheet, trên Trello, hoặc sử dụng các công cụ quản lý source code như Gitlab. Tại Magestore, chúng mình sử dụng Gitlab cho hoạt động này.

Các bước tiến hành Sprint Planning

Phần 1 - Xác định mục tiêu của Sprint

Product Owner sẽ trình bày mục tiêu mong muốn đạt được trong Sprint này, hoặc team sẽ chủ động nhắc lại các mục tiêu đã được thống nhất với PO từ đầu quý. Nếu cần làm rõ hơn các hạng mục trong Product Backlog, nhóm sẽ trao đổi trực tiếp với PO. Nhưng thông thường, việc làm rõ này đã được thực hiện trước qua các buổi làm mịn Backlog (hay còn gọi là Grooming)

Thứ tiếp theo cần cân nhắc để lựa chọn số lượng mục tiêu cho phù hợp chính là năng lực của nhóm. Việc tính toán năng lực của nhóm là điều rất quan trọng, vì nếu tính toán không chính xác, bạn sẽ nhận nhiều hơn sức mình có hoặc quá ít so với năng lực của nhóm dẫn đến hiệu suất kém. Một bí kíp tại Magestore chúng mình thường áp dụng, nếu 1 ngày các bạn có 8 tiếng làm việc, thì thời gian năng suất để mỗi thành viên thực sự làm việc được hiệu quả sẽ chỉ là 5 hoặc 6 giờ. Tiếp theo, hãy nhìn vào lịch cá nhân của mình xem có thành viên nào trong nhóm vướng mắc việc gì trong tuần này không, nếu có hãy chủ động chia sẻ ngay đầu buổi Planning.

Hình ảnh một buổi làm việc của team tại Magestore

Phần 2 - Xác định cách thực hiện mục tiêu của Sprint

Làm thế nào để hoàn thành công việc đã chọn? Kết quả của phần làm việc chính là Sprint Backlog - bảng công việc được nhóm Phát triển sử dụng trong suốt Sprint.

Đối với mỗi hạng mục trong danh sách đã lựa chọn, nhóm sẽ tách thành những công việc cụ thể. Các công việc này thường đủ nhỏ để hoàn thành trong vòng một ngày hoặc ít hơn. Thông thường các task của team sẽ là: thiết kế solution, viết testing, code, viết tài liệu, nghiên cứu kỹ thuật/công nghệ mới, fix bug, họp với team làm BA cho feature mới

Sau khi xác định đầu mục công việc, nhóm sẽ cùng nhau chốt thời gian & nỗ lực team cần để hoàn thành công việc đó, có thể theo thời gian (giờ) hoặc point (điểm) Thông thường trong 1 team phát triển, chúng mình sẽ có nhiều thành phần developer, tester, BA, nên việc ước lượng cho các task có thể có sự chênh lệch. Đó là lúc chúng mình sẽ dụng Planning Poker để tìm ra con số chung của nhóm.

Sau khi tính toán khối lượng công việc đã lựa chọn, nhóm phát triển có thể chủ động nhận thêm hoặc trao đổi với PO để cắt bớt các hạng mục.

Kiểm soát chất lượng bằng định nghĩa hoàn thành

Tại Magestore chúng mình, Product Owner sẽ thường làm việc với các team theo Quý với định hướng Quý, sau đó các team chủ động làm việc trong các Sprint. Việc tham gia Sprint Review cũng không bắt buộc với PO. Liệu có dễ dàng và bị thiếu chất lượng khi để một nhóm tự đề xuất công việc dựa trên mục tiêu, rồi review với nhau và chủ động đưa ra các phiên bản update?

Có 2 cách để bạn quản lý chất lượng, 1 là giao nhiệm vụ, rồi kè kè bên cạnh kiểm soát và khi kết quả hoàn thành bạn sẽ check để soi lỗi. Cách còn lại là giao nhiệm vụ, hướng dẫn team cách tự tư duy về định nghĩa hoàn thành (thế nào là hoàn thành) một cách cực kỳ chi tiết, team sẽ tự giám sát lẫn nhau và đảm bảo cho chất lượng đầu ra của mình. Cách thứ 2 này là cách Magestore lựa chọn. Chính vì vậy, định nghĩa hoàn thành lại trở thành một tiêu chuẩn cực kỳ quan trọng của bất cứ nhiệm vụ nào trong Sprint.

Minh hoạ Definition of Done (Internet)

Định nghĩa hoàn thành là một danh sách các quy định những công việc cần được thực hiện xong trước khi một hạng mục được công nhận là DONE. Việc nhóm cùng nhau đưa ra định nghĩa hoàn thành cũng giúp mọi người trong nhóm hiểu chung về yêu cầu công việc, ngăn ngừa các mâu thuẫn do hiểu nhầm hoặc không hiểu rõ. Gia tăng tính minh bạch về yêu cầu cũng giúp nhóm tự tổ chức hiệu quả hơn. Chúng mình hay gọi Định nghĩa hoàn thành là DOD tức Definition of Done.

Sprint 1 tuần tại Magestore

Hồi đầu áp dụng Scrum, Magestore cũng để các team tự lựa chọn độ dài của Sprint tuỳ từng team. Tuy nhiên sau đó một thời gian thử nghiệm, thấy việc thiếu đồng đều về mặt cam kết kết quả giữa các team, team thì 1 tuần, team thì 2 tuần, có team lên tới 3 tuần nên Magestore đã quyết định sử dụng Sprint 1 tuần cho tất cả các team. Và tinh thần DELIVER WEEKLY" đã được áp dụng triệt để. Cho dù là một kế hoạch MVP có thể kéo dài 2-3 tuần, nhưng từng tuần, định nghĩa hoàn thành cũng được quy định rõ ràng, và các team cố gắng đạt được milestone cho từng tuần trong mục tiêu chung.

Việc sử dụng Sprint 1 tuần có những tác dụng:

• Nhịp độ công việc nhanh, thấy công ty sôi nổi, các team nhiều năng lược mỗi tuần
• Cả công ty đồng bộ thực hiện mục tiêu đầu tuần & review kết quả cuối tuần, sáng thứ 2 trong mỗi buổi Monday Motivation, các team show & tell kết quả của team mình
  

Áp dụng Sprint Planning tại team sản phẩm tại Magestore

Team sản phẩm tại Magestore có 5 thành viên và các bạn thường làm Sprint Planning vào tuần đầu sáng thứ 2. Hãy cùng nghe Vincent - thành viên gắn bó với Magestore 2 năm chia sẻ:

Đầu quý, team mình cùng anh Steve (CEO - Product Owner) và Alex (Product Manager) làm rõ các mục tiêu trong quý cùng mức độ quan trọng. Bên cạnh định hướng đó, chúng mình cũng thực hiện việc bảo trì sản phẩm. Vì vậy đầu tuần, chúng mình sẽ lên Github để check một lượt các issue cần fix ngay, rồi để vào plan tuần. Kết hợp mục tiêu từ đầu quý và các issue cần fix urgent, team sẽ chủ động nhận việc, estimate thời gian. Có những công việc chưa ai nhận, thì ai xong việc trước sẽ pick để làm. Tuy nhiên trường hợp này rất ít, thông thường mọi người sẽ chủ động san sẻ với nhau ngay từ đầu tuần. Các nhiệm vụ không rõ ràng thường đã được chúng mình làm mịn 1,2 tuần trước đó nên Sprint Planning khá nhanh gọn và hiệu quả.

Tại Magestore, mỗi chiều thứ 6 hàng tuần chúng mình lại đón một chuyến tàu, tên gọi thân thương của Release Train. Hiểu là khi đưa Sprint 1 tuần, chúng mình cam kết sản phẩm luôn tốt hơn sau mỗi tuần. Và sản phẩm tốt hơn đó được mang đến cho khách hàng ngay lập tức. Có thể là fix bug, nhiều lúc là Feature Update, đảm bảo sản phẩm nóng hổi. Đây cũng là hoạt động Magestore sử dụng các kỹ thuật của DevOps để đảm bảo sự liền mạch và chủ động từ các bên, hướng đến giá trị cuối cùng chuyển giao cho khách hàng.

Hình ảnh thông báo Release Train hàng tuần vào thứ 6 tại Magestore

‍

Áp dụng Sprint Planning tại team triển khai sản phẩm tại Magestore

Còn với team Triển Khai Sản phẩm, chúng mình đang làm Sprint Planning như thế nào? Hãy cùng lắng nghe Jessie - BA mới join Magestore chia sẻ nhé:

Team mình sẽ làm planning vào chiều thứ 6, lúc 3h30. Tụi mình lựa chọn thời gian này là để thứ 2 đi làm có luôn mục tiêu chiến luôn chứ không phải chờ đợi hay lấy lại não sau 2 ngày nghỉ nữa. Team mình sử dụng cả Gitlab và Google Sheet để quản lý công việc. Trên Gitlab, chúng mình chia theo các trạng thái của task, và cho các Dev lựa chọn ai sẽ làm task nào. Việc cập nhật thứ tự ưu tiên của task sẽ do Project Manager phụ trách, vì thông thường các mục tiêu này sẽ được cập nhật liên tục theo yêu cầu của khách hàng. Có khách đang vội lại thành không vội, có khách vội thì lại có thể hoãn lại sang tuần sau nữa cung được. Còn tổng quan tất cả các dự án, để nhìn được những khoảng trống của team, thì team mình sẽ dùng Google Sheet để lường trước thời gian rảnh hay nghẹt của team trong thời gian tới.

Jessie - ngoài cùng bên trái cùng team Rỗng

Bí kíp để buổi Sprint Planning đạt hiệu quả cao

Các bạn có thể bị rơi vào một buổi Planning dài lê thê như mưa ngâu tháng 7 và khiến cảm xúc bị tụt kinh khủng. Sprint Planning - lập kế hoạch không tốt thì khi đến Sprint Review và Sprint Retrospective tâm trạng sẽ rất xuống dốc. Để tránh trường hợp này, hãy nắm chắc 3 bí kíp sau nhé, chúng mình đã lượm lặt từ các team Agile của Magestore và sharing cho các bạn ngay đây:

1. Thống nhất giờ Sprint Planning phù hợp với tính chất công việc của team mình

Như chia sẻ ở trên, bạn sẽ thấy ngay tại Magestore, các team có sự lựa chọn thời gian Sprint Planning khác nhau, có team thì làm luôn vào chiều thứ 6, có team thì sáng thứ 2 mới làm. Tuy nhiên, theo quan sát, các team tiếp xúc với khách hàng hay có sự thay đổi thường xuyên và công việc cần sự tiếp nối cao thì sẽ thích làm Planning vào chiều thứ 6 để không bị quên tình huống của khách hàng sau 2 ngày cuối tuần. Còn các team ít sự biến động, chủ động hơn với mục tiêu công việc của mình sẽ chọn Planning vào đầu tuần.

2. Các thành viên trong team rà soát & chuẩn bị các task của bản thân đẩy lên trước và làm rõ

Buổi làm việc sẽ không thể hiệu quả nếu đến lúc đó bạn mới bê não vào phòng họp. Thông thường giờ planning của chúng mình là 8h30, hoặc 9h, sau 1 đến 1,5 tiếng vào làm việc (Magestore vào làm việc lúc 7h30) Khoảng thời gian này là lúc chúng mình sẽ cùng đẩy lên các mục tiêu của cá nhân hoặc chủ động nhìn lại các mục tiêu của team và đưa vào kế hoạch tuần. Có một số các thành viên còn tranh thủ làm việc từ ngày chủ nhật, để backlog luôn dồi dào khi mở ra vào đầu tuần sau.

3. Thực hiện Grooming (làm mịn) thường xuyên

Làm mịn là một kỹ thuật trong việc quản lý Product Backlog. Các hạng mục trong Product Backlog có kích thước khác nhau, mức độ chi tiết khác nhau và thường chúng cần được làm mịn trước khi đi vào sản xuất. Làm mịn có thể bao gồm việc bẻ nhỏ những hạng mục có kích thước lớn thành những hạng mục nhỏ hơn, càng nhỏ, càng chi tiết thì càng rõ ràng và mịn. Anh em dev Magestore còn hay dùng từ đập đá" để mô tả quy trình này.

1 nhóm Scrum có thể dành ra 10% thời gian Sprint để ngồi cùng nhau làm mịn Product Backlog cho các phiên tiếp theo. Việc tư duy công việc từ trước để có sự chuẩn bị và không bị động là bí kíp để các buổi Sprint Planning được hiệu quả cao.

Chúc các bạn có hoạt động Sprint Planning hiệu quả nhé!