為什麼我覺得 User Story 是學會專案控制很重要的一環。是因為我發現長久以來，很多開發者 do project management the wrong way。
事情做不完的根本原因是很難分清楚：手頭上的東西是「異想天開的想法」「也許改天再做也可以的想法」「真正對專案有重大貢獻的想法」還是「完全不需要實作的想法」。
在不把「真正對貢獻的想法」以及「真正對專案有重大貢獻的想法」梳理出來之前，你不可能知道在給定時間內，有多少資源讓自己能夠準時交付對專案有貢獻的 code。更不可能知道，在時間緊迫之下，哪些「想法」是可以被無情地刪除的。
因此專案延遲是相當正常的。
在最近上課後跟學員交流之後，我更從互動中發現，為什麼有些公司導入 Scrum 會失敗，是因為到 RD 手上的時候，其實 Ticket 都已經被切好。而這些 RD 是在「完全不知道原始故事長什麼樣的狀況」的情境去實作這些 Ticket 的。所以就容易做出歪掉的產品，而因為歪掉，就會在 Acceptence Test 被打回去。
許多 delay 或做歪的專案，問題都在原始 requirement 或 goal 並沒有被專案中負責執行的人好好理解，然後再化之為能夠執行的 Tickets。
而 Issue Tracking System 也淪為「掛想做的任務的工具」，而不是「管控」「應該被做」的「管理任務工具」。
在此前提下，更不可能將專案所收斂。
把該做的事情分離出來
所以如果要真正貫徹 Agile。第一件事情就是要把「該做的事情」好好的分出來。
以此為出發點。再去學如何做 Story Valuation，Velocity，Priority 管控。
在這過程中，後續使用更多的 communication tool 、collaboration tool、continuous delivery tool 排除協作中所會遇到的障礙。
然後，你才會開始看得懂: 那些敏捷開發的書到底在講什麼。哪些你可以用，哪些你不需要用。為什麼 scrum 某些方法 work，哪些方法不 work。
為什麼你花時間讀完一本 scrum 教科書，你的團隊卻還是敏捷不起來。
我想真正的關鍵在這裡。