「將大的故事劃分為更小的、業務人員能夠理解的故事會更好。」——《The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece》

一張 Jira task、Issue、Work item、任務卡、User Story 或一個軟體需求，到底最合適的大小（顆粒度）是多少？

舉例來說「使用者可以線上退貨」這個需求，你會怎麼拆？

前端、後端、資料庫各一張？該不會是這種切法吧？

水平切分，看起來剛好能對齊團隊中的不同角色，可以達到權責分明的效果。

但問題是這種切法必須保證在 DEMO 日之前，這三位角色一定都要解完各自的卡，並且還要彼此整合順暢才行。

如果有任何人進度脫隊，那麼另外兩張就只會淪為無法產生價值的半成品。

怎麼切就像是一種難以描述的藝術，不容易有標準答案，這大概是所有軟體開發團隊都會遭遇的日常難題。

到底怎麼切才能真正將大需求轉換成可以各自獨立交付價值的小需求？

而又該是怎麼樣的團隊架構、團隊組成與團隊協作模式，才是最能持續交付價值的團隊呢？