給產品負責人的Sprint評審會建議


文章轉自:Leangoo敏捷工具官網

文章鏈接:https://www.leangoo.com/12777.html


Sprint評審會議可能是產品人員最重要的Scrum活動,它可以幫助您收集反饋意見,做出正確的產品決策,從而增加創造成功產品的機會。但是我發現,產品負責人並不總是清楚誰應該參加會議,應該如何開展這個會議,以及如何收集相關反饋。本文將回答這些問題,並分享我的一些建議,以幫助您在Sprint評審會上得到更多收獲。

邀請正確的人參與

從正確的人那里收集反饋信息對於做出正確的產品決策至關重要:如果您邀請了不合適的人參與,或者關鍵人物未到場,那么您不太可能收到您所需要的反饋。因此,你應該確保你邀請合適的人參與。
一般來說,邀請那些你需要獲得反饋來驗證最新產品增量,以及可以幫助您推進產品發展的人參與。這些人通常是您的關鍵干系人 - 對您的產品有興趣的人員,以及您需要去發掘的產品用戶和需要你提供產品的人。這些人可能包括營銷,銷售,服務和支持人員以及其他業務部門的人員,具體取決於您的產品和組織。
為了鼓勵干系人參與,以及管理干系人的期望,告訴他們為什么需要他們參加會議,以及他們可能會看到什么,這是很有幫助的。

協作但不要畏懼說不

我參加過不止一個很快就結束的Sprint評審會:一位開發團隊成員向那些看起來很困惑的干系人和站在這些干系人身后的產品負責人演示了產品功能。然后,Scrum Master詢問大家是否有任何問題或反饋意見,這些干系人相互看着對方,有些人說:“干的不錯”,“看起來還可以”,然后人們就離開了。這次會議收集到的有價值的意見是零。
因此,要鼓勵人們積極參與並分享他們的觀點,想法和擔憂。使用開放式的問題,比如“你怎么看待我們對注冊功能的改進?”,試着理解為什么有人喜歡或不喜歡這個迭代的產品增量。收到諸如“看起來很棒”的反饋可能會感覺很好,但是它並沒有提供任何新的見解。為什么這個人喜歡這個功能?有什么可以進一步改善?
讓所有的與會者有機會發表他們的觀點,欣賞他們的意見和反饋,即使你不同意或難以接受他們。請記住:來自干系人的創造力,知識和反饋可以幫助您做出正確的產品決策,以提供可能的最好的產品。
同時,不要接受某些個人通過這個會議來達成他的個人目的或者某個業務單元的利益。我記得有一次Sprint評審會,當時一位高級干系人在產品負責人和開發團隊中直言不諱地提出了他的要求,這當然不合適,也沒有提供任何幫助。
作為產品負責人,善待和理解很重要。但是不要讓干系人告訴你該怎么做。你對產品負責,你必須擁有最后的發言權,否則你無法獲得足夠的權力和尊重。
對於沒有幫助的想法和不現實的要求,不要害怕說不。基於產品整體戰略和產品路線圖來決定是否需要接受相關請求。如果你懷疑你的決定,可以使用下一個sprint來測試這個想法或請求是否對用戶有益。但請記住,提供一個令所有人滿意的產品幾乎是不可能的。
請您的ScrumMaster協助會議並制定基本規則。這使您可以放手去和參與者進行溝通,並收集反饋意見。

考慮把Sprint評審會分成兩部分

在有些情況下,將Sprint評審會分為兩部分是有幫助的。第一部分,你和開發團隊參與,團隊向您演示產品增量。然后,您向團隊成員提供反饋意見,並確定哪些條目已完成,我們現在進展如何。你可以使用發布燃盡圖來看看進展。如果你在Sprint期間已經有了足夠多的參與,並且已經看過相關完成的功能並給與了反饋,那么第一部分的環節你可能根本不需要。
第二部分,干系人參加會議。我發現,作為產品負責人,您通常最適合向干系人呈現產品增量:您可能比開發團隊成員更好地了解用戶如何與產品進行交互並使用新功能。然后收集干系人的反饋意見,以了解我們是否開發出了具有正確用戶體驗和功能的正確產品。按照上面的建議詢問開放式問題,以便了解為什么新功能很好或者為什么需要調整。
把會議分成兩個部分,這樣你可以與開發團隊有一個線下溝通的機會,也可以在Scrum團隊以外的人加入之前理清分歧。當您在Sprint期間沒有機會與團隊互動時,這種方式尤其有用,例如,您和團隊不在一個地方辦公,或者您忙於訪問用戶和客戶,或參加展會或會議。但是要確保開發團隊成員出席整個會議。直接聽取干系人的意見是非常寶貴的。

考慮分開收集最終用戶和干系人的反饋

Sprint評審會的原意是將所有合適的人聚集在一起,同時收集每個人的反饋意見。如果這對你有效,那很好。但是,我經常發現分別收集用戶和內部干系人的反饋信息會更有幫助。為什么?這兩個群體往往有不同的觀點和利益。
通過用戶測試產品增量可以讓您了解產品是否適用於你的目標用戶群,是否提供了正確的用戶體驗和正確的功能。與干系人討論產品增量可幫助您了解是否高效地提供了產品,是否可以開始運營、銷售和支撐你的組織了。
更重要的是,最好用不同的技術來收集用戶和干系人的反饋:當實現的功能很少時,向最終用戶演示產品增量是有意義的。否則,觀察或測量用戶實際使用產品的方式會更有幫助,例如可用性測試和早期版本。
相比Sprint評審會,這些技術通常需要更長的時間,可能需要幾天的時間才能將產品增量發布給(選定的)用戶后收集相關數據,這種方式自然而然地把收集最終用戶反饋和收集干系人反饋分開了。
記住,用戶勝過干系人:如果產品不利於用戶,人們不會長期使用它,無論它是多么可銷售或者可服務,或者CEO有多喜歡。

不要急於決定

有些情況下,你可以在Sprint評審會議上立即做出產品決策,甚至可以調整好產品Backlog,正如Scrum指南所建議的那樣。但是,很多時候,特別是如果反饋的影響比較大,導致產品Backlog變化更大的時候, 花更多的時間來分析反饋,得出正確的結論,然后再決定如何調整產品Backlog,這樣你能夠得到更多的收獲。
此外,如果您決定分開收集用戶和干系人的反饋意見,如上所述,你可能不會在Sprint評審會獲得相關反饋數據。因此,您應該考慮把收集反饋和數據,跟分析和采取行動分開進行。例如,您可以選擇在下一次Sprint計划會議之前開展一個簡短、聚焦的產品Backlog工作坊,用這種方式來客觀評估這些反饋,並和開發團隊討論如何調整產品Backlog。 或者,您可以在分析工具的幫助下,收集到足夠多的用戶數據以后,在下個Sprint組織一次產品Backlog的會議來評估這些反饋。

討論發布進度

想象一下,所有的反饋和數據表明,人們將會熱愛你的產品。但是,如果你的產品發布延遲或者超出預算,那么您的產品可能不會成功,甚至可能不會正式發布。因此,您必須定期確保產品要有進展。
Sprint評審會是一個很好的機會,因為你現在應該知道哪些條目已經完成,距離終點還有多遠。此外,參加會議的關鍵干系人可能需要知道新的產品版本是否能按計划發布,或者是否有延誤,因為這可能會影響他們的工作。更重要的是,討論發布進度,將當前的Sprint放到了上下文環境中,並和之前Sprint連接起來,讓我們能開到整體的進展。
我喜歡使用發布燃盡圖——Scrum的標准工具來跟蹤發布進度,並預測項目的后續進展。發布燃盡圖展示了產品Backlog中剩余的工作量隨着迭代的開展不斷減少的趨勢。
無論您使用哪種工具:確保它可以幫助您了解您的進度如何,並進行必要的調整:比如,為團隊新增UX設計師,或者推遲發布日期、只部分滿足發布目標、比計划交付更少一些的功能等。

 

英文資料來源:
http://www.romanpichler.com/blog/sprint-review-tips-for-product-owners/

作者:羅馬·皮赫勒

譯者:廖靖斌Eric Liao, Scrum中文網資深敏捷教練、顧問和培訓師,CSP




注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2020 ITdaan.com