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 的頭像
kojenchieh

David Ko的學習之旅

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


留言列表 (2)

發表留言
  • Toro
  • 如果寫作者只有一個人的話,卻要拌演那麼多的角色和思考角度,我想會精神崩潰吧。
  • kojenchieh
  • 通常是customer or product owner先開始寫, 之後經由team的檢視和討
    論, 漸漸地把內容豐富. 所以不是一開始要寫得很齊全, 而是要不斷的溝
    通討論, 來豐富其內容

您尚未登入,將以訪客身份留言。亦可以上方服務帳號登入留言

請輸入暱稱 ( 最多顯示 6 個中文字元 )

請輸入標題 ( 最多顯示 9 個中文字元 )

請輸入內容 ( 最多 140 個中文字元 )

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼