Để đảm bảo nội dung được truyền tải trọn vẹn, mình xin phép sử dụng nguyên một số thuật ngữ Tiếng Anh nhé. Các thuật ngữ các bạn có thể tra cứu trực tiếp bằng việc click vào link dưới mỗi từ khóa.
Scrum được định nghĩa bởi 4 sự kiện: Lập kế hoạch Sprint (Sprint Planning), Scrum hàng ngày (Daily Scrum), Sơ kết Sprint (Sprint Review) và Cải tiến Sprint (Sprint Retrospective). Những sự kiện này được thiết kế đặc biệt để tạo ra sự minh bạch cần thiết. Không thực hiện bất kỳ sự kiện nào theo quy định dẫn đến mất cơ hội để kiểm tra và thích ứng. Các sự kiện được sử dụng trong Scrum để tạo ra sự đều đặn và giảm thiểu nhu cầu về các cuộc họp không được xác định trong Scrum.
1. Sprint
Trước khi tìm hiểu về các sự kiện trong Scrum, chúng ta cần hiểu rõ về một Sprint là gì, bởi cả 4 sự kiện trong Scrum đều sẽ được thực hiện trong một Sprint.
Định nghĩa
Theo scrum guide, thì sprint được định nghĩa là
“Sprints are the heartbeat of Scrum, where ideas are turned into value” (Sprint là nhịp tim của Scrum, là nơi mà các ý tưởng trở nên có giá trị).
Sprint có timeboxed, có độ dài không quá một tháng (hoặc 4 tuần) và nhất quán trong suốt quá trình phát triển. Một Sprint mới sẽ được bắt đầu ngay sau khi kết thúc sprint cũ.
Những lưu ý trong Sprint
- Không cho phép bất kỳ sự thay đổi nào ảnh hưởng đến Mục tiêu Sprint (Sprint Goal)
- Mục tiêu chất lượng không được cắt giảm
- Product Backlog được tinh chỉnh khi cần thiết
- Phạm vi có thể được làm rõ và thương lượng lại với Product Owner khi mọi thông tin được thu thập nhiều hơn.
Sprint cho phép khả năng dự đoán bằng cách đảm bảo kiểm tra và điều chỉnh tiến độ đối với Product Goal ít nhất mỗi tháng dương lịch (calendar month). Khi Sprint quá dài, Sprint Goal có thể trở nên vô giá trị, độ phức tạp và rủi ro có thể tăng. Các Sprint ngắn hơn có thể được sử dụng để tạo ra nhiều chu kỳ học hơn và hạn chế rủi ro về chi phí và nỗ lực trong một khung thời gian nhỏ hơn. Mỗi Sprint có thể được coi là một dự án ngắn.
Một Sprint có thể bị hủy bỏ nếu Sprint Goal trở nên lỗi thời. Chỉ Product Owner mới có quyền hủy Sprint.
2. Lập kế hoạch Sprint (Sprint Planning)
Sprint Planning bắt đầu Sprint bằng cách đưa ra các công việc cần thực hiện cho Sprint. Kế hoạch kết quả này được tạo ra bởi sự cộng tác của Scrum Team. Scrum Team cũng có thể mời những người khác tham gia Lập kế hoạch Sprint để đưa ra lời khuyên. Product Owner đảm bảo rằng những người tham dự được chuẩn bị để thảo luận về các hạng mục Product Backlog quan trọng nhất và cách chúng liên kết với Product Goal.
Toàn bộ buổi Sprint Planning sẽ tập trung vào 3 chủ đề chính gồm: Tại sao Sprint này lại có giá trị? Điều gì có thể hoàn thành trong Sprint này? Làm sao để hoàn thành được công việc trong Sprint này?
Tại sao Sprint này lại có giá trị?
Product Owner đề xuất cách sản phẩm có thể tăng giá trị trong Sprint hiện tại. Điều này được thể hiện trong danh sách các tính năng có trong Product Backlog.
Sau đó, Scrum Team sẽ hợp tác để xác định Sprint Goal nhằm truyền thông lý do tại sao Sprint lại có giá trị đối với các bên liên quan. Mục tiêu Sprint phải được hoàn thành trước khi kết thúc Lập kế hoạch Sprint.
Điều gì có thể hoàn thành trong Sprint này?
Thông qua thảo luận với Product Owner, các Nhà phát triển (Developers of Scrum Team) chọn các mục từ Product Backlog để đưa vào Sprint hiện tại. Scrum Team có thể tinh chỉnh các mục này trong quá trình này, giúp tăng sự hiểu biết và sự tự tin.
Việc lựa chọn số lượng có thể hoàn thành trong một Sprint có thể là một thách thức. Tuy nhiên, Developers càng biết nhiều về hiệu suất trong quá khứ, năng lực sắp tới và Definition of Done (DoD), thì họ càng tin tưởng vào việc lựa chọn các đầu việc cho Sprint tới.
Làm sao để hoàn thành được công việc trong Sprint này?
Đối với mỗi hạng mục Product Backlog đã chọn, Developers lập kế hoạch công việc cần thiết để tạo Increment đáp ứng DoD. Điều này thường được thực hiện bằng cách chia nhỏ các hạng mục Product Backlog thành các hạng mục công việc nhỏ hơn trong một ngày hoặc ít hơn. Việc này được thực hiện như thế nào là do các Developers quyết định.
Sprint Goal, các hạng mục trong Product Backlog được chọn cho Sprint, cộng với kế hoạch phân phối chúng được gọi chung là Sprint Backlog.
Sprint Planning có timeboxed là tối đa 8h cho Sprint 1 tháng (hoặc Sprint 4 tuần), với Sprint ngắn hơn thì timeboxed này ngắn hơn.
3. Scrum hàng ngày (Daily Scrum)
Mục đích của Daily Scrum là kiểm tra tiến độ hướng tới Sprint Goal và điều chỉnh Sprint Backlog khi cần thiết, điều chỉnh công việc đã lên kế hoạch sắp tới.
Daily Scrum là một sự kiện kéo dài 15 phút dành Developers của Scrum Team. Để giảm bớt sự phức tạp, Daily Scrum được tổ chức cùng một lúc và diễn ra vào mỗi ngày làm việc của Sprint. Product Owner và Scrum Master có thể tham gia với tư cách là Developer của Scrum Team.
Developers có thể chọn bất kỳ cấu trúc và kỹ thuật nào họ muốn, miễn là Daily Scrum của họ tập trung vào tiến độ hướng tới Sprint Goal và đưa ra một kế hoạch có thể hành động cho ngày làm việc tiếp theo. Điều này tạo ra sự tập trung và cải thiện khả năng tự quản lý.
Daily Scrums cải thiện thông tin liên lạc, xác định các trở ngại, thúc đẩy việc ra quyết định nhanh chóng và do đó loại bỏ nhu cầu cho các cuộc họp khác.
Những lỗi nên tránh khi thực hiện Daily Scrum
- Biến Daily Scrum trở thành một buổi báo cáo công việc cho ScrumMaster.
- Daily Scrum trở thành một phiên thảo luận để giải quyết vấn đề.
- Diễn ra quá xa nơi làm việc.
- Developers không thấy giá trị của buổi Daily Scrum.
- Các thành viên thường báo cáo là không gặp vấn đề gì.
- Daily Scrum không diễn ra như là một thói quen, hôm làm hôm bỏ.
- Scrum Master giao việc cho thành viên trong Daily Scrum.
- Mỗi người nói xong là xong việc, không nghe người khác nói tiếp.
4. Sơ kết Sprint (Sprint Review)
Mục đích của Sprint Review là để kiểm tra kết quả của Sprint và xác định các điều chỉnh trong tương lai. Scrum Team trình bày kết quả công việc của họ cho các bên liên quan chính và tiến tới thảo luận về Product Goal.
Trong sự kiện này, Scrum Team và các bên liên quan xem xét những gì đã đạt được trong Sprint và những gì đã thay đổi trong môi trường của họ. Dựa trên thông tin này, những người tham dự cộng tác với nhau về những việc cần làm tiếp theo. Product Backlog cũng có thể được điều chỉnh để đáp ứng các cơ hội mới. Sprint Review là một phiên làm việc và Scrum Team nên tránh việc giới hạn nó trong một bài thuyết trình.
Sprint Review có thời gian tối đa là 4 giờ cho Sprint một tháng. Đối với Sprint ngắn hơn, sự kiện thường ngắn hơn.
Những lưu ý để buổi Sơ kết Sprint diễn ra hiệu quả
- KHÔNG trình bày những tính năng chưa “hoàn thành”
- Từ các phản hồi được đưa ra thì Product Backlog có thể được đánh giá lại độ ưu tiên.
- Product Owner nên sử dụng kỹ thuật kiểm thử chấp nhận để đánh giá các tính năng.
- Đây KHÔNG phải là buổi demo sản phẩm. Trong thực tế, việc demo sản phẩm chỉ là một nội dung của buổi Sprint Backlog. Nếu chỉ tập trung vào demo sản phẩm thì sẽ bỏ qua một nội dung quan trọng khác liên quan đến việc thảo luận và cộng tác giữa các thành viên tham gia. Từ đó gây hiểu nhầm và thực hiện sai mục đích thực sự của buổi Sprint Review là thanh tra và thích nghi sản phẩm đang được xây dựng.
5. Cải tiến Sprint (Sprint Retrospective)
Mục đích của Sprint Retrospective là hoạch định các cách thức để tăng chất lượng và hiệu quả.
Scrum Team kiểm tra Sprint cuối cùng diễn ra như thế nào liên quan đến các cá nhân, tương tác, quy trình, công cụ và DoD. Các yếu tố được kiểm tra thường thay đổi theo lĩnh vực công việc.
Scrum Team thảo luận về những gì diễn ra tốt đẹp trong Sprint, những vấn đề mà họ gặp phải và cách những vấn đề đó đã được giải quyết (hoặc không).
Scrum Team xác định những thay đổi hữu ích nhất để cải thiện hiệu quả của nhóm. Những cải tiến có tác động nhất được giải quyết càng sớm càng tốt. Chúng thậm chí có thể được thêm vào Sprint Backlog cho Sprint tiếp theo.
Sprint Retrospective là hoạt động kết thúc Sprint. Thời gian tối đa là 3 giờ cho Sprint một tháng. Đối với Sprint ngắn hơn, sự kiện thường ngắn hơn.
Những lưu ý khi thực hiện Sprint Retrospective
- Nhiều nhóm thực hiện việc cải tiến liên tục rất tùy hứng, không kiểm soát, không theo dõi nên kết quả cải tiến thường không rõ ràng và ít giá trị. Hoạt động cải tiến liên tục cần phải trở thành thói quen của từng cá nhân và nhóm, và lâu dần thành văn hóa của tổ chức thì sẽ đạt hiệu quả cao nhất.
- Có một lỗi mà các nhóm thường gặp phải đó là buổi cải tiến chỉ tập trung vào những vấn đề làm chưa tốt để cải tiến. Điều này thường dẫn đến tình trạng các thành viên có cảm giác không thích thú với sự kiện này và xem nó như một cuộc họp mang tính tiêu cực. Hãy cố gắng tạo ra sự hứng thú và tinh thần tích cực trong các thành viên bằng cách động viên thông qua những công việc đã làm tốt.
- Mặc dù việc cải tiến có thể diễn ra bất cứ lúc nào, nhưng sự kiện Sprint Retrospective vẫn là thời điểm chính thức được quy định để làm việc này. Tuân thủ và thực hiện tốt sự kiện này là cách để tạo một thói quen thanh tra và thích nghi quy trình làm việc trong nhóm.
Bài viết tham khảo nguồn từ scrum guide.
