杭州vi設計公司曾經要解決的最早的挑戰之一是正確處置死者。典型情況如下。我的團隊會將用戶故事計劃到他們的Sprint待辦事項列表中，然后在Sprint期間對其進行處理。相應的值將投入增量中。換句話說，將創建發行質量的增量，例如達到團隊的“完成的定義”，然后將那些計劃的故事從剩余工作范圍中刪除。

問題在于，由于增量發布獲得的經驗有時會發現其中一些故事是不正確的或不適當的。當然，這完全可以從敏捷的工作方式中獲得。每個版本都是檢查和修改產品的機會。但是，對于將相關的用戶故事委托給歷史的團隊，這也可能會產生問題，或者至少是一個問題。然后如何修改這些故事以正確地獲取最新的理解，從而可以做進一步的工作并改進產品？這是杭州vi設計公司的團隊陷入的困境，他們向我求助。簡而言之，他們希望我把用戶故事從墳墓中帶回來。

那時，杭州vi設計公司還不太了解，用戶故事對于他們所開發的Sprint僅“有效”。請記住，用戶故事是有關可能需求的對話的占位符。這些對話在執行故事的Sprint期間進行。時間框結束且故事結束后，其中的對話占位符確實是歷史。

如果一個故事在退役后被發現是“錯誤的”（即使只是一個或兩個不同的驗收標準而已被確定），那么這些發現就與一個新的故事有關。換句話說，我們將有一個新的占位符，用于以后有關所需范圍的一次或多次對話，并且必須對此工作進行估計并在產品待辦事項列表中進行說明。新的用戶故事可能與早期的此類占位符非常相似，但這仍然是一個新的故事。

當然，如果原始故事的接受標準實際上沒有得到滿足，那么故事一開始就永遠不會完成。它應該保留在產品待辦事項列表中，并重新估算完成工作所需的工作。

有時，杭州vi設計公司會在出現新需求時陷入用戶故事“破裂”的困境。要記住的是，用戶故事實際上并不能中斷。對話將有希望發生，并且故事將在時間表結束時滿足其接受標準并滿足“完成的定義”，否則將不會。Sprint期間故事所代表的對話不會因將來的發現而中斷，因此占位符本身也不會中斷。這些古老的對話都無法超越過去，無法進入未來的時間范圍，而在這些時間范圍內它們會被撤銷和破壞。希望“破裂”的是該故事的某些產品，例如從舊的驗收標準得出的不推薦使用的回歸測試。

完全有理由認為，驗收測試將需要進行更改（就像系統本身需要進行更改一樣），以適應杭州vi設計公司因敏捷開發和交付而出現的新對話和新故事。但是，“考慮對舊故事的影響”是不合理的。沒有影響。有可能是對他們的產品，如外接老驗收標準BDD測試產生影響，但這應該由考慮系統新的故事來解決的，是和剩余的工作。通過有新的對話和新的故事來代表他們，可以實現這一點。