我正在嘗試爲學校項目設置一個Pivotal Tracker項目，而我對「故事」的理解是，它們實際上只是表示用戶想要對該應用程序執行的操作。初始設計與敏捷開發中的故事適合於哪裏？
對於一些簡單的跟蹤工具，用戶可以在其中添加員工，查看員工記錄，刪除員工等，最初的設計將在哪裏與Pivotal Tracker項目匹配？例如，如果我有類似的故事：
「作爲用戶，我希望能夠將新員工添加到數據庫。」
...我將如何添加一些故事到我創建僱員類，我的數據訪問層等項目？對所有故事都需要的東西進行基礎和階級設計？
在此先感謝，希望這是一個這樣的問題的正確的地方。
......我如何在創建員工類，我的數據訪問層等的項目中添加一些故事？對所有故事都需要的東西進行基礎和階級設計？
「創建員工類」不是一個故事，因爲它不會給用戶帶來商業價值。像寫作課程，功能，數據庫計劃這樣的東西是任務，這些任務是在爲下一個衝刺選擇一個故事時創建的。您應該只創建任務並只編寫當前故事集所需的代碼。不要做「種種基礎」和「所有故事需要的東西」（YAGNI）。你不知道所有的故事是什麼！
用戶故事描述對將使用該應用程序的人（或角色）有用的功能。
參與交付故事的工作應該「切分」整個架構。因此，如果您的故事是「作爲員工，我可以在數據庫中創建新的用戶記錄」，所涉及的工作應該處理所有數據庫，數據訪問，安全和所需的用戶界面。
因此，當它「完成」時，該功能有可能被運送。
這是如何適應設計？對於一個大型項目來說，有很多故事並不會讓特別容易看到該解決方案的整體設計。史詩記錄可能會有所幫助，但我仍然希望有一個簡短的設計迭代（Sprint Zero）來構建一個足夠好的設計。
會推薦閱讀「Disciplined Agile Delivery」，其中談到了敏捷設計和建模。