是否應該建立使用者故事來計劃系統維護和支援？
這個問題可能源於對敏捷開發的誤解。敏捷專案團隊旨在為特定專案進行組裝。一旦進行了一定數量的產品規劃，積壓計劃和衝刺計劃，第一個衝刺就會啟動。從那時起，敏捷團隊的目標是在每次衝刺結束時遞增使用者價值，並使團隊提供這種價值的速度最大化（Velocity只是在衝刺期間完成的Story Points數量的一個奇特術語），Story Points是用於相對彼此調整使用者故事大小的度量單位。
所有這些都意味著速度包含了與開發使用者故事所定義的特徵相關的所有成本。敏捷團隊中仍然存在開銷。事實上，故事點根本就不可能追蹤絕對時間。他們的目的是顯示相對大小和複雜性的使用者故事的優先次序和衝刺規劃的目的。
通常，專案管理和產品管理時間被集中在間接成本中。其中一個主要原因是這些角色所做的大部分工作不能用使用者故事來一對一對映。有大量的專案管理工作和產品管理工作的產生對使用者並沒有價值。例如，產品經理可以記錄或引導建立一系列使用者故事，這些使用者故事一旦被評估，最終將被排除在優先順序之外。也許做出的決定是，在使用者故事中沒有足夠的價值來開發它們。因此，這是一個例子，使用者故事不會跟蹤敏捷專案團隊工作人員所花費的時間。
所以回到我們原來的問題，是否應該為維護和支援建立不同的使用者故事？簡短的回答是：不，一旦開發了系統或應用程式，就會繼續進行硬體和基礎架構管理。有人需要監視伺服器負載，當系統負載上升到伺服器效能下降開始時，將新的虛擬伺服器聯機等。
稍微長一點的答案是，儘管使用者故事不應該只為系統支援或維護建立，支援和維護任務有時可以在有意義的情況下被定為新的使用者故事。如果預先知道使用者故事中定義的特徵需要大量的基礎設施來支援新的功能，那麼在使用者故事估計中應該包括建立和配置新伺服器所需的時間。當然，將時間分配給需要新後端資源的幾個使用者故事是有意義的。所以，這取決於工作是否是使用者故事本身的結果。
值得注意的是，重構是敏捷開發的一個自然和必要的部分。重構描述了在不影響使用者檢視系統外部功能的情況下重構現有程式碼內部結構的行為。可能需要重構來改進系統的非功能方面，如響應時間，或者可能需要重構來支援當前體系結構結構不支援的新特性。在敏捷專案中，重構是預期的並且應該被計劃。在可能的情況下，重構的增量成本應該分散在受影響的使用者故事中。使用者描述包含接受測試，在重構發生後需要重新測試以確保現有功能沒有被破壞。