iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 23
0
Software Development

團隊導入Scrum會遇到的30個問題系列 第 23

[Day 22] User Story的尺寸大小

[Day 22] User Story的尺寸大小

問題:
有人覺得User Story切太小沒意義,有人覺得User Story要切得越小越好,
我們想找到一個平衡,是每個人共同期待的大小。

我們該如何決定User Story 要切多大多小?

問題分析:

  • 切User Story的目的是什麼?
  • 我們怎麼判斷怎樣是大,怎樣是小?
  • 大一點有什麼影響,小一點有什麼影響?

SamHuang的看法:
忘記最原始出處是哪裡,看過一個說法是把工作大概切分成25%工作時間的大小是個不錯的做法。
假設一個Sprint是兩週,那一個story 可以切成大概2,3天可以完成的大小。
原因是我們能在拆解後降低風險,容易看到進度,也不會小到花太多時間切、討論。

對策:

  1. 切完工作後,大概猜一下是不是25%的工作時間可以完成,如果超過,就繼續切。
  2. 如果用相對複雜度的點數,有沒有大家做起來感覺剛好的點數? 如果有的話,我們可以盡量切成那個大小。

選擇對策:

執行:

    1. Scrum講的是經驗主義,不用花太多時間討論完美的切法。 快速決定一個做法就試試,體驗後再討論可以怎麼調整。

上一篇
[Day 21] Product Backlog 小孩子才做選擇,我全都要
下一篇
[Day 23] Scrum 團隊對工作項目的瞭解
系列文
團隊導入Scrum會遇到的30個問題30

尚未有邦友留言

立即登入留言