在
Scrum中，需求通常以用戶故事表達。那么在Scrum中可以使用用例嗎？如果可以的話，什么情況下我們應該使用用例呢？
Scott Kendrick問到：
用例在Scrum中有一席之地嗎？我的直覺是，如果正確編寫了用戶故事，那就足以驅動討論和協(xié)作了，同時也足以用來制定
測試用例了。
首先，Scrum要求我們使用用戶故事，而不要使用用例嗎？Roy Morien認為不是：
Scrum沒有強制任何引發(fā)誘導和記錄需求的方法，除了推薦面對面的對話、日常的站立會議（當然如果你想坐下也可以）、sprint計劃會議、甚至是用戶故事分析，Scrum推薦的就只有協(xié)作活動和透明性了。根據這些指導原則，我想這取決于你實際想做什么。
鑒于此，在什么情況下你會想使用用戶故事呢？Charles Bradley建議：
通常對于新的Scrum團隊，在他們轉向Scrum的頭幾個月，我建議他們就使用他們以前的需求搜集方法。學習Scrum時，不去
學習一種全新的需求搜集方法會讓學習變得非常困難。
同時Charles Bradley認為，“[……]Scrum的指導原則表明大部分Scrum團隊應該使用用戶故事，而對于那些要求‘任務/生命周期的行為要非常確定’的團隊，可以使用用例”。Adam Sroka不同意這種方法：
傳統(tǒng)觀點認為，“關鍵”的應用程序需要更多文檔。我認為這是不對的。關鍵應用程序需要的是更多（以及更好）的驗證。要做到這一點，就需要詳盡的
自動化測試，許多做“關鍵”應用程序的團隊都不那么做，這點我不能理解。
但是，在純粹的功能范圍外，用例文檔可能會提供價值。Charles Bradley寫到：
嗯，我曾經在航空領域
工作過一段時間，盡管我沒有完備的知識來支持這份工作（比如，什么需求必須具備這個東西），在我們從事文檔工作的時候，讓我記憶猶新的是，編寫文檔的目的不是過程審計，而是找出飛機墜毀的起因和責任方（監(jiān)管部門，訴訟保護）。因此，某些必要的文檔有助于（保護公司）那樣的工作，而且我認為，在某些時候用例可能會比用戶故事更加有助于證實你的案例（避免出錯）。
像
敏捷方法的所有方面一樣，對于用例給組織帶來的價值，應該要仔細檢查。你從付出的精力中究竟得到了什么？畢竟，就像Ron Jeffreis所說的，“我還沒有碰到過很多實際的人，真正善于編寫用例。”如果你承認你可能不擅長編寫用例，那么有什么事情是你一直在做的，能給你的組織帶來更多價值？