產能（capacity）一開始稱為速率（velocity）。因為「速度」暗指某種不存在的控制程度，所以我不再使用該術語。想想看一台車：只要踩下油門，就可以輕鬆地提升速度。不過如果你想要增加車子的容量（capacity），你需要做出更大的改變。團隊產能也是如此。他並不是如此輕易可以被改變的事物。
——《敏捷軟體開發的藝術》 p.225

在敏捷開發的實踐裡，有時會因為傳統專案管理開發的思維，導致開始做出與初衷相悖的行為。比如說，要求估算要精準，再比如說，把專案進度落後歸咎團隊速率太慢，應該要趕緊把速率提上來。

但正如《敏捷軟體開發的藝術》所述，產能這件是並不是簡單催個油門就能夠提升的，更像是改變一個車既有的容量，需要做些困難的改變，比如說去償還積欠甚多的技術債、比如說透過長時間的學習與實踐培養更好的開發模式等等。

我也在我服務的團隊導入過速率表，紀錄團隊每次 Sprint 完成的故事點，從一個單純的紙本表格，到紙本上可以簡單畫上趨勢圖；接著開始數位化，然後越來越多複雜的欄位；漸漸地又開始簡化，然後透過一些自動化省下了不必要的使用成本。這些過程我也與團隊在產能這件事上一起學習與成長。

團隊除了學會使用這個歷史數據來評估自己能認領的狀況，偶爾會預測到一些意外而少領一些，偶爾會覺得狀況不錯，想要挑戰自己而多領一些。

以前的我，可能在意的是團隊會不會好好記錄這些數據作為參考。但隨著跟團隊成長的過程中，現在的我更在意的是團隊與產品負責人相互協商的過程。

彼此合作久了，大致對產能的範圍有些經驗累積起來的感覺。但團隊開始會在產品規劃會議時，嘗試去跟產品負責人聊到還有哪些技術性的待辦事項應該要去做以降低未來的什麼風險、團隊這個 Sprint 有些產品外的業務會干擾，可能會少領一點；而產品負責人也會分享自己的觀點，去討論這些事。

雙方願意為彼此付出，交流看法與觀點，說明各自的難處，進而同理彼此的決策。這樣的平衡，比較對於速率表的精細計較，可能更能讓團隊處於一個穩定的節奏，持續去開發與成長。