進行有意義的 Sprint Review（Conducting Meaningful Sprint Reviews）

2023/03/29閱讀時間約 18 分鐘

Photo by unsplash.com

共同作者：Shalom Chin 與 KK；譯者：KK

Sprint Review 是跟利害關係人和客戶建立工作夥伴關係，並取得他們對產品的回饋的特別時段。除了 Scrum 團隊的 Increment，更新的 Release Burndown 和更新的 Team Velocity 等這些 Artifact ，都會跟利害關係人和客戶分享，以便培養透明度（transparency）和管理期望。

然而，這重要的 Scrum Event 被簡化為「展示（demo）」。在更不希望發生的情況時，團隊會因忙於進入下一個 Sprint，所以收到的回饋未能被汲取和適當的整併。讓我們記得，它是 Sprint Review，而不是 Product Review。這指我們應該跟我們的利害關係人和客戶一起審查整個 Sprint。我們交付價值了嗎？我們的使用者何時能感受到價值被展現了？我們在做正確的事嗎？我們的客戶對產品的滿意度如何？我們應該關注其他較高優先順序的 Backlog Item 嗎？有什麼正在阻礙團隊加速的事情，是利害關係人和客戶能幫助解決的嗎？

在這篇文章中，我們詳細列出讓 Sprint Review 更具意義的的步驟，提供給任何 Scrum 團隊參考。

透過提醒參與者 Sprint Goal 和進度來啟動對話。人們易於忘記事情，尤其在他們忙碌的時候。在 Review 開始時，用產品願景（Product Vision）和 Sprint Goal 來提醒大家，有助於讓每個人保持一致。如果團隊已部分完成目標或未兌現承諾，請將這 Event 當成一個探索參與者如何幫助團隊消除障礙的機會。不只如此，要確保邀請到有權力提供幫助的人參與這個 Review。在其中能分享如近三個 Sprint 的 Velocity 或其他指標，以深入了解問題的潛在根本原因，是很好的事。
展示且收集回饋。別只是展示新功能或 Increment 如何作用，而要仔細研究參與者如何跟產品互動。要透過了解使用者行為與辨識出能讓他們滿意的功能來改善產品。要確保能嚴謹地收取回饋，以用於後續更深入的分析。要明確詢問使用者希望看到的調整。並且，回饋的品質很重要，因此要找出使用者面臨的核心問題，但不用深入了解確切解決方案的細節。要鼓勵 Scrum 團隊積極參與這場會議，以便更了解他們的客戶。
確定已完成和要再處理的工作。接著，更新 Product Backlog、Team Velocity 和 Release Burndown。對於需要再處理的工作，要在 Backlog 中建立一個工作項目，並在客戶在場的情況下驗證這項調整。你可以在之後的 Sprint Planning 之前細化精煉（refine）這些項目。此外，Scrum Master 會更新每個 Sprint 的 Team Velocity，Product Owner 則會更新 Release Burndown。讓利害關係人了解狀況，使資訊透明，以便更好地管理他們對交付價值的期望，以及能開放地討論對任何不確定的工作項目的顧慮。
分享團隊學習和發現。 Scrum 團隊應該利用這段時間分享對開發 Increment 的見解，讓參與者更好地了解在開發所需功能時，所面臨的複雜度。這會提高利害關係人和客戶對工程挑戰的認識。我們希望透過這樣的分享，讓參與者建立對團隊的同理心，並簡化開發厚重的功能與調整交付期待。
給利害關係人和客戶時間來提供市場/商業的更新。商業面的更新，會揭露很多關於市場或客戶對產品的評價。這項情報對於塑造即將到來的 Sprint Backlog 非常重要。Product Owner 會使用這些新資訊來調整 Product Backlog ，並新增任務項目以解決市場/商業上的風險。關鍵是調整產品，以便讓它不落後於競爭對手。我們希望降低產品過時的風險。
分享為即將到來的 Sprint 訂出優先順序的工作項目，並收集回饋。這有助於讓利害關係人和客戶對將即將到來的 Sprint 的內容保持一致的認知，這樣團隊才能確信他們在每個 Sprint 中，都在構建有價值的 Increment。運用這段時間弄清楚哪些工作項目能被往後延遲或不需要。Product Owner 應該更新和重新排序 Backlog ，以顯示被提供的回饋。

這些步驟是進行 Sprint Review 的指南，並不詳盡。你能跟參與者一起探索更多做法。我們鼓勵你在 Sprint Review 中進行實驗和迭代。

補充摘錄：

你是否想知道有意義的 Sprint Review 會長什麼樣子？它不只是一個展示。它更是和投資/贊助方和使用者建立關係和信任的機會。在這篇簡短的文章中，我們寫了幾個步驟來指引進行 Sprint Review 的方式。我們希望這會幫助你進行下一次 Review 時產生更多的想法。

Co-written by Shalom Chin and Kaitlyn Peng

The Sprint Review is a special time to connect with stakeholders and customers to establish a working partnership and get their feedback about the product. Besides the Scrum Team’s increments, artifacts such as the updated release burndown chart and the updated team velocity are shared with both stakeholders and customers so as to foster transparency and manage expectations.

However, this important Scrum Event constantly gets simplified into a “demo”. In more undesirable situations, feedback received is not captured and properly incorporated because the team is being rushed into the next Sprint. Let’s remember that this is called the Sprint Review, not the Product Review. That means that together with our stakeholders and customers, the entirety of the Sprint should be reviewed. Did we deliver value? When will the value be felt by our users? Were we working on the right thing? How satisfied are our customers with the product? Should we focus on other higher-priority backlog items? Is there anything that is stopping the team from accelerating that the stakeholders and customers can help resolve?

In this article, we detail a list of steps to conduct more meaningful Sprint Reviews for any Scrum Team to consider.

Open the conversation by reminding the attendees of the Sprint goal and its progress. People tend to easily forget things, especially when they are busy. Starting the review with a reminder of the product vision and the sprint goal helps to get everyone aligned. If the team has partially accomplished the goal or has not delivered on its commitments, use this event as an opportunity to explore how the attendees can help the team remove the impediments. In addition, ensure that the people with the power to help are invited to this review. It would be good to share the data such as the velocity from the last three Sprints or other metrics to give insights into the potential root causes of the problem.
Demo and collect feedback. Don’t just show how the new feature or increment works but study how the attendees interact with the product. Improve the product by understanding the user behaviors and identifying the features that satisfy them. Make sure the feedback is rigorously captured for deeper analysis later. Ask explicitly about the changes which the users would like to see. Quality of the feedback matters so find out the core issues that the users are facing without going into details of the exact solution. The Scrum team is encouraged to actively participate in this session to get to know their customers better.
Determine what is completed and what needs rework. Then update the product backlog, team velocity, and release burndown. For items that require rework, create an item in the backlog and verify the written changes in the presence of the customers. You can refine the items later before the Sprint planning. In addition, Scrum Masters will update the team velocity for each Sprint, and Product Owners will update the release burndown. Make these transparent to the stakeholders so that their expectations of delivered value can be better managed and concerns on any open items can be openly discussed.
Share team learnings and discoveries. The Scrum team should use this time to share insights into developing the increments so that attendees can have a better appreciation of the complexities faced in developing the desired features. This raises the awareness of the stakeholders and customers about the engineering challenges. We hope that through this sharing, the attendees will build up empathy for the team, simplify development-heavy features and adjust delivery expectations.
Give stakeholders and customers time to provide market/ business updates. Updates from the business side reveal a lot about what the market or customers are saying about your product. This intel is important in shaping the upcoming Sprint Backlog. The Product Owner will use this new information to adjust the Product Backlog and add new items to address market/business risks. The key is to adapt the product so that it is not lagging behind the competition. We want to reduce the risk of the Product becoming obsolete.
Share the items prioritized for the upcoming Sprint and gather feedback. This helps to align the upcoming Sprint with the stakeholders and customers so that the team is confident that they are building increments of value in each Sprint. Use this time to clarify the items that can be put off at a later date or are unnecessary. Product Owners should update and re-order the backlog to reflect the feedback given.

This list of steps is a guide for conducting Sprint Reviews and is not exhaustive. There are other activities that you can explore doing with the attendees. We encourage you to experiment and iterate on the Sprint Review.

Extract: Have you wondered what a meaningful Sprint Review would look like? It’s not just a demo. It’s an opportunity for forging a relationship and trusts with your sponsors and users. In this short article, we wrote a few steps to guide you in conducting the Sprint Review. We hope that this would give you more ideas when you conduct your next review.