（一）

Epic 或者 Feature 才是最終可交付的東西。而 Story 很多時(shí)候則是不可單獨(dú)發(fā)布的，所以很多 PO 或者團(tuán)隊(duì)會(huì)有這樣的疑問，為什么還要把 Featrue 拆成盡可能小的 Story？

1. 加快反饋。小的 Story 經(jīng)過開發(fā)、QA、Demo的循環(huán)，可能會(huì)產(chǎn)生新的 Learning。

2. 識(shí)別優(yōu)先級(jí)。拆小之后，會(huì)發(fā)現(xiàn)有些點(diǎn)不是必做的。

（二）

Story 一開始叫 User Story，其余的很難歸于用戶故事的，可以稱之為 Technical Spike。

現(xiàn)實(shí)中則有很多演化。

1. 比如一個(gè)后端API，給小程序、安卓、iOS用。理想的情況是這些團(tuán)隊(duì)屬于一個(gè)Scrum Team，Story 是端對(duì)端的。然而不理想的情況，App端和后端屬于不同團(tuán)隊(duì)，也得找條活路。這時(shí)候可以把后端 API 作為單獨(dú)的 Story。

2. 再比如 Feature 拆成多個(gè) Story 后，每個(gè) Story 都單獨(dú)驗(yàn)收過了，可是對(duì) Fearure 的聯(lián)合測試怎么辦？可以有個(gè) Test Story。但注意它不屬于任何單個(gè) Story，否則的話應(yīng)該歸于那個(gè) Story 的 Task。

3. 再比如，一個(gè) Feature 做完需要發(fā)布時(shí)，發(fā)布需要額外的工作比如 ：生產(chǎn)環(huán)境的數(shù)據(jù)遷移。它也沒法歸于某個(gè) Story。這種情況可以建一個(gè) Release Story。

（三）

問題來了，這些形形色色的 Technical 的 Story，跟 Story 下面的 Task 有什么區(qū)別？

可以用 INVEST 的 Valuable 來區(qū)分：

Story 的Valuable 本來指的是對(duì)用戶有價(jià)值，這邊可以把用戶的外延擴(kuò)大，用戶指的是“團(tuán)隊(duì)以外的人”。所以看上面的 Technical Story：

1. Technical Spike 的價(jià)值是對(duì)團(tuán)隊(duì)外的人澄清，某個(gè) Story 能不能做，多大的 cost 和 Risk。

2. 后端 API 的價(jià)值顯而易見是對(duì)前端團(tuán)隊(duì)。

3. 集成測試的價(jià)值是確保用戶的外部質(zhì)量。

4. Release Story 的價(jià)值也顯而易見，讓用戶用上我們的功能。

所以，區(qū)別是，Story 對(duì)團(tuán)隊(duì)外的人有價(jià)值，或者對(duì)他們產(chǎn)生直接影響，屬于 What。而歸屬于 S投入下面的 Task ，則只對(duì)自己或者本團(tuán)隊(duì)有價(jià)值，屬于 How。