5 Common Mistakes We Make Writing User Stories
http://www.scrumalliance.org/articles/366--common-mistakes-we-make-writing-user-stories

 

User_Story_Card-3-515x391  


1. User Story都只有一個 user
通常我們在寫 user story 時, 很容易寫成以下形式:


As a user I want to be able to manage ads, so that I can remove expired and erroneous ads.

因此容易讓你的功能想的不是很齊全, 因為你沒有從不同的 role 來考量. 這種錯誤和 use case 一樣. 若是你有在用 use case, 一定知道這個問題是甚麼.

 

2. User Story只是為了product owner而寫
如果你只是為了 product owner 做出他想要的功能, 你很容易寫出這樣的東西:


As a Product Owner I want the system to have possibility of deleting ads, so that users have possibility of deleting ads.

因此再一次地, 你只有考慮到一個角色, 你只為 product owner 做出他想只用的東西, 但是這是不是真正顧客想要的, 不知道.

 

3. User Story只是為了開發人員而寫
這裡有個例子:
As a developer I want to replaced the folder widget, so that I have maintained folder widget.

這通常代表你可能有 technical debt 要處理. 也就是之前有些地方做得不好, 你想要在這時候加以改進. 但是 scrum 在每個 sprint 結束時, 都要交付對使用者有價值的項目. 因此
這樣的技術負債, 可能無法 demo 或是對使用者來說不易感受到它的價值. 這種 case 是有必要存在, 因此對於價值的部分, 需要針對使用者的角度加以描述.

 

4. 忘記寫對顧客的價值或好處
我們會寫哪個角色需要那些需求, 但是通常卻忘記要寫為什麼顧客要這個東西, 會帶來甚麼好處. 寫這些價值並不是一種浪費, 它可以讓你思考目前的解法, 是否真的幫助到user,
是否有觸碰到她的痛點, 以確保你是做對的事情.

 

5. 沒有驗收標準
沒有驗收標準, 會讓你容易低估了工作的複雜度. 例如 installation package 完成的條件, 若是包含要支援 silent install, 這可能需要的開發時間就不一樣. 或者經理要求必須
要有單元測試和程式碼審核, 這時候你便要加這些項目的處理時間.

 

 

    全站熱搜

    kojenchieh 發表在 痞客邦 留言(2) 人氣()