在敏捷開發時，你們都怎麼選擇哪些 backlog要先做？那些 ticket 的優先序都怎麼排的？
如果你的公司和團隊可以明確的分出優先順序，follow 產品 roadmap，那我真的要恭喜你！雖然在敏捷開發中，在每個 sprint 中排定優先任務好像可以遵照一些規則，如上面大家多少也看過的艾森豪 decision matrix，用很直白的概念(重要性與緊急性）決定出決策的優先順序，但現實世界中事情的黑與白真的那麼單純嗎？

我只能說理想很豐滿，但現實很骨感。
以過去我在小小新創的經驗舉例，的確剛開始大家對於 roadmap 都有很美好的想像，也真得以此為根據，排定各功能的優先順序，但當第一個客戶進來時，一切就不一樣了，有時候也不一定是客戶的錯，甚至有時我還會同情他們，因為我們產品根本開發不到20%，他們卻以為他們買到了一隻會飛的大象。
所以當客戶開始使用時，產品根本跟不上客戶需求，這時候就會出現很多插件，不管是功能還是 bug ，有時候還會發生插件比原先排定的任務還多，大家開始哭笑不得，還得在死線前拼命趕工。大家忙了一季過後，才發現一些最重要的部分都還沒開始做，甚至還得回過頭收拾當初趕時間拼出來的板塊，這些後來都有高機率會出問題。

所以我為什麽說需求優先級是一種假象，因為這取決於公司體質，當你體質不好又缺錢醫病時，你其實沒有決定優先級的權利，因為公司要生存而你也需要錢。