在傳說中的Product Owner中簡單的談了Product Owner（簡稱PO，中文翻為產品負責人）的重要性和如何幫助PO成功。那在現實中的PO會遇到哪些問題呢？ 一些常見的PO怪味道（Smell）有
- 我們團隊有N個PO（N>1）
- 我們團隊有N個Product Backlog（N>1）
- 我們的Scrum Master也當PO
- 我們的PO很忙
- 我不知道為什麼要做這些Items
- 我們直接拿某某Scrum軟體管理Product Backlog
這些怪味道會給團隊帶來什麼影響呢？
1. 我們團隊有N個PO（N>1）
Scrum唯一的中心點就是產品，所有的人事物都圍繞著產品發生，而產品的願景就顯示在Product Backlog上。PO是Product Backlog的守護者，Scrum之所以限定PO只能由一個人擔任，是為了讓產品資訊能集中，決策的效率，與對產品完全當責。所以多過一個PO會造成開發團隊不知道要聽那個PO的，產品資訊分散和決策緩慢等後遺症。
2. 我們團隊有N個Product Backlog（N>1）
Scrum解決時程的方法是讓最高價值的Item先被完成，一份Product Backlog的先後順序很清楚。如有多過一個Product Backlog，要看出先後順序就非常困難，容易誤解。如一個團隊負責兩個以上產品，PO也應合併成一份的Product Backlog。
3. 我們的Scrum Master也當PO
如果Scrum Master加PO，正確的名稱應該叫Team Lead 或 PM。Scrum把PO（對產品）和Scrum Master（對人）分開的原因是權力的過度集中不利於自組織團（Self Organized Team）的發生和發展。我認為這是最嚴重的Smell，因為有利於自組織團隊的環境是跑Scrum最大的價值。如沒辦法誕生自組織團隊，不如不要跑Scrum。
4. 我們的PO很忙
PO是客戶需求的代表，按照敏捷宣言原則第4條業務人員與開發者必須在專案全程中天天一起工作，所以開發團隊應要隨時可以找到PO釐清需求。PO太忙表示開發團隊很難了解需求，風險就是開發出來的軟體不符合需求。
5. 我不知道為什麼要做這些Items
敏捷開發靠的是所有人的自發性，而不了解為何而戰就得不到對工作的成就感，打擊自發性。如何讓開發團隊了解為何而戰可以看看PO傻傻搞不清楚需求和寫一個動人的故事。
6. 我們直接用某某Scrum軟體管理Product Backlog
Product Backlog的功用是溝通產品的願景。而當開始使用Scrum軟體（Excel除外）管理Product Backlog時，通常會讓Product Backlog成為只有PO看的Product Backlog。PO會花上很多時間試圖去完善Backlog Item的內容，而開Product Backlog Refinement的互動也會減少很多，應由開發團隊和PO協作的What（戰術目標），變成PO的演講。副作用是開發團隊自以為了解需求，但是其實並不清楚。
【手把手帶你跑敏捷】Scrum企業實戰課程
由於 Scrum 只提供了框架易學難精，所以鈦坦科技與 Tibame 合作拍攝了 Scrum 運作的實際情況，在看完了這個線上教學後，相信能幫助您更容易理解 Scrum 的運作方式與優點。
圖片：http://themetapicture.com/uh-dont-do-that/
