Sửa lỗi xong phải chờ Sprint Review mới được phát hành? Increment, phát hành và continuous delivery trong Scrum
Công ty quy định chỉ phát hành sau Sprint Review, kể cả bản sửa lỗi nhỏ. Khách hàng chờ 9 ngày cho một lỗi đã sửa xong. Scrum Guide 2020 nói rõ Sprint Review không phải "cổng" phát hành. Phân biệt Increment, phát hành, continuous delivery và continuous deployment, và vai trò mới của Sprint Review khi phát hành liên tục.
Tình huống liên quan
Bảng Kanban kín việc mà khách vẫn chờ lâu: giới hạn WIP và định luật Little
Đội hỗ trợ triển khai có 6 người nhưng đang "ôm" 31 yêu cầu dở dang, khách hàng chờ trung bình hơn ba tuần. Dùng bốn chỉ số dòng chảy của Kanban Guide và định luật Little để chứng minh rằng bắt đầu ít việc hơn mới là cách xong việc nhanh hơn.
Product Owner kiêm nhiệm "vắng mặt": khi backlog chờ quyết định cả tuần
Product Owner là trưởng phòng nghiệp vụ, chỉ dành được vài giờ mỗi tuần cho đội. Câu hỏi tồn đọng, đội tự đoán yêu cầu và làm lại. Cách chẩn đoán, khôi phục quyền ra quyết định và ủy quyền đúng cách.
Mỗi story qua tay bốn người, cuối sprint dồn kiểm thử: phá silo chuyên môn bằng swarming và kỹ năng hình chữ T
Đội Scrum 8 người nhưng thực chất là bốn "phòng ban mini": phân tích, backend, frontend, kiểm thử. Story nào cũng đi qua bốn tay, kiểm thử viên ngập việc ba ngày cuối sprint. Vì sao đội liên chức năng không có nghĩa là mỗi người một chuyên môn, và cách chuyển sang làm việc theo kiểu "cả đội dồn vào ít việc".
Backlog 180 story mà vẫn không biết phát hành gì trước: lập bản đồ user story theo hành trình người dùng
Danh sách backlog phẳng 180 dòng được xếp theo "giá trị" từng story, nhưng bản phát hành đầu lại không dùng được vì thiếu các bước nền. Cách dựng user story map theo hành trình người dùng, cắt lát phát hành có thể dùng ngay và kiểm tra story bằng INVEST.