進行有意義的 Sprint Review（Conducting Meaningful Sprint Reviews）
更新於 發佈於 閱讀時間約 18 分鐘
共同作者：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.
9會員
28內容數
一生懸命在「改善臺灣職場與職人能力」的使命，有十餘年產品和團隊管理經驗。期待透過推廣產品管理知識與管理實務，改善對臺灣職人能力，讓企業因此而更有競爭力，因此創立臺灣產品人學會 （POA) 。
現任：
- 臺灣產品人學會 (POA) 理事長
- 生活和職涯教練
- 臺灣百大企業 Agile Coach
留言0
查看全部你可能也想看
Google News 追蹤
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
「"衝刺 Sprint"是“敏捷開發 Agile Development”的“爭球法 Scrum”中的用語。
首先設定一個產品使用流程作為目標，
然後在一週至一個月期間內，將能夠做到這個使用流程的功能製作出來。
這段預設用來迅速進行開發工作的期間，就叫做衝刺期間。」
「精
「Scrum的用意是為科技業設想一套更快速，更可靠，更有效的軟體開發手法。」
「Scrum源自於 Toyota生產系統，以及空戰的OODA循環。」
「設定為期一週至一個月的“衝刺 Sprint"，以維持動能，讓每個成員承擔應有的責任。」
「進行簡短的"每日立會 Daily St
敏捷開發的實踐方式有很多，其中以簡單、易懂的 Scrum 框架最廣為大家接受。 2024年7月 LeSS 網站發布了新一版的《Scrum 指南》，其中調整的內容我覺得讓這個框架更符合實務上的應用，因此就其內容並結合個人經驗與見解撰寫這篇短文，希望幫助大家快速了解這套能幫助團隊適應變化的敏捷開發方法。
如何有效運用Scrum的船舶理論來主持專案檢討會。船舶理論將專案比作船，通過風帆、礁石、錨等元素可視化檢討內容。會議前的準備、進行步驟及專案經理的主持技巧，幫助團隊在輕鬆愉快的氛圍中總結經驗、識別問題、制定改進計劃，從而提升未來專案的成功率。
在數位時代，Scrum已成為專案管理的利器。本文介紹Scrum的核心角色、工件和事件，並結合我開發CDP的實際經驗，分享如何通過產品待辦清單管理、Sprint計劃與執行、每日站會和Sprint回顧來提升專案靈活性與效率。希望能啟發更多專案經理運用Scrum，優化專案流程。
在敏捷開發過程中，每兩週都會有一場回顧會議（retro），PO、UX、RD、QA 會針對該 Sprint 進行檢討和反思，這篇想記錄以產品經理（PO）的角度常被提到的檢討點，一方面是幫助自己成長，另一面是更濃縮自己的產品想法。
誰適合看這篇文章？✔ 對產品經理、產品企劃、產品策略、產品規劃有興
產品開發的成功，除了品質，更在於是否能夠在適當的時程內推出並滿足客戶需求。
身為開發、設計人員，從文中提供的三個角度來思考，以確保產品與公司的競爭力。
本文介紹了在公司專案中採用敏捷(Agile)方法，並分享了Scrum的好處、成員負責工作以及工作流程。希望可以掌握Scrum的核心：透明度、檢視和調整的核心，來推動敏捷工作。
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
「"衝刺 Sprint"是“敏捷開發 Agile Development”的“爭球法 Scrum”中的用語。
首先設定一個產品使用流程作為目標，
然後在一週至一個月期間內，將能夠做到這個使用流程的功能製作出來。
這段預設用來迅速進行開發工作的期間，就叫做衝刺期間。」
「精
「Scrum的用意是為科技業設想一套更快速，更可靠，更有效的軟體開發手法。」
「Scrum源自於 Toyota生產系統，以及空戰的OODA循環。」
「設定為期一週至一個月的“衝刺 Sprint"，以維持動能，讓每個成員承擔應有的責任。」
「進行簡短的"每日立會 Daily St
敏捷開發的實踐方式有很多，其中以簡單、易懂的 Scrum 框架最廣為大家接受。 2024年7月 LeSS 網站發布了新一版的《Scrum 指南》，其中調整的內容我覺得讓這個框架更符合實務上的應用，因此就其內容並結合個人經驗與見解撰寫這篇短文，希望幫助大家快速了解這套能幫助團隊適應變化的敏捷開發方法。
如何有效運用Scrum的船舶理論來主持專案檢討會。船舶理論將專案比作船，通過風帆、礁石、錨等元素可視化檢討內容。會議前的準備、進行步驟及專案經理的主持技巧，幫助團隊在輕鬆愉快的氛圍中總結經驗、識別問題、制定改進計劃，從而提升未來專案的成功率。
在數位時代，Scrum已成為專案管理的利器。本文介紹Scrum的核心角色、工件和事件，並結合我開發CDP的實際經驗，分享如何通過產品待辦清單管理、Sprint計劃與執行、每日站會和Sprint回顧來提升專案靈活性與效率。希望能啟發更多專案經理運用Scrum，優化專案流程。
在敏捷開發過程中，每兩週都會有一場回顧會議（retro），PO、UX、RD、QA 會針對該 Sprint 進行檢討和反思，這篇想記錄以產品經理（PO）的角度常被提到的檢討點，一方面是幫助自己成長，另一面是更濃縮自己的產品想法。
誰適合看這篇文章？✔ 對產品經理、產品企劃、產品策略、產品規劃有興
產品開發的成功，除了品質，更在於是否能夠在適當的時程內推出並滿足客戶需求。
身為開發、設計人員，從文中提供的三個角度來思考，以確保產品與公司的競爭力。
本文介紹了在公司專案中採用敏捷(Agile)方法，並分享了Scrum的好處、成員負責工作以及工作流程。希望可以掌握Scrum的核心：透明度、檢視和調整的核心，來推動敏捷工作。