我開始爲我的遊戲積壓添加第一個用戶故事。我的團隊對我們想要創建的遊戲有一個大致的瞭解，並且我們準備好收集頂級要求。你怎麼做到這一點？我的意思是，例如，您可以從一個巨型史詩（頂級）開始，其內容是：「作爲發佈商，我想創建一個遊戲，玩家必須餵食怪物，以便他們度過一段非常有趣的時間。」這是一個正確的起點嗎？我們是否應該將這部史詩分成較小的用戶故事，並將這些用戶故事分成較小的用戶故事和最終的任務？這種「像樹一樣」收集需求的方式是好的，還是通常採用「平坦」的方式？如何管理在遊戲中應用Scrum時寫出第一個故事？
在此先感謝。
寫好用戶故事的一個很好的起點是the book by Mike Cohn。網上還有大量有用的資源，如何編寫好的用戶故事，以及如何與作爲產品負責人的積壓工作以及如何讓團隊參與，以持續保持積壓狀態良好，以便您可以進行有效的衝刺計劃會話，做到合理預測功能可用時的日期等。
保持實用和實驗總是很重要的。開始與東西，然後檢查&適應，以便您改善。這是任何敏捷工具/框架的本質。
如果你願意，從大史詩開始，看看如何。
也許不值得擁有這部史詩，而是討論他遊戲的玩家可以做的更具體的各種事情。這些東西是用戶故事，即在整個產品中增加用戶價值的東西。系統的垂直切片。
一些虛構的例子來說明各地的故事的想法在遊戲設置：
是的，你可以看到它是一棵樹或更多，更具體的故事，是其他故事或史詩的孩子。實際上，你只關心葉子，因爲這是作爲團隊和PO在一起工作的產物，用於在衝刺計劃或其他會話期間處理待辦事項。
實驗並從一些東西開始並從那裏改進。
這就是我們所做的。從相當高級別的史詩開始，將它們分解成更多技術用戶故事。通常我們停止在一個層次上，但有時候用戶故事太大了，它需要分成更小的塊。
在頂層是史詩，正下方是用戶故事，就是這樣。它可能會幫助你進一步分解爲一個分解練習 - 但是建立一個龐大的依賴故事樹可能需要很多追蹤。我們試圖捕捉利益相關者的需求和史詩（可以，可以有一些重疊，但沒關係）。我們傾向於希望我們的用戶故事成爲「輕量級需求」。開發人員可以根據需要自由創建儘可能多的任務來完成故事。如果開發者發現任務太多，我們會回過頭來看看我們是否可以打破這個故事。
我們的產品負責人管理「功能積壓」，這只是說「史詩」的奇特方式。我們將特色故事與我們的團隊故事聯繫起來。沒有一個頂級史詩，有許多頂級史詩代表功能需求。通過這種方式，我們可以將功能邏輯分組在一起，以實現「發佈」。
您可能想看看Jeff Patton的一種叫做「User Story Mapping」的技術。
「作爲一個出版商我想創建一個遊戲，讓他們度過了一個非常有趣的時間，玩家必須養活一個怪物」
東西要記住的是，故事是從這個角度寫的系統用戶。在你提到的例子中，我發現發佈者肯定是該項目的利益相關者，但不是用戶（除非你創建了一個應用程序來生成遊戲）。您的遊戲用戶。可能「玩家」將是主角，但你可以想到不同類型的玩家：高級玩家與新手，PC玩家與遊戲控制檯玩家，想要探索的玩家以及快速完成遊戲的玩家等。建議您提供遊戲需要支持的不同功能。
自上而下以樹狀方式進行需求收集對我來說似乎非常邏輯。我注意到的另一件事是，在不同的樹級別（當你沿着樹下，用戶故事更具體），不同的角色將會出現，解釋他們想要或需要完成的大圖（樹的根） 。當你向下移動樹時，你會發現更多表達他們需求的技術角色。正如我所說，我剛開始並試圖分享我的觀點，看看敏捷大師是否可以證實或否認我的想法:)。 – Notbad
您不會爲發佈商製作遊戲，您可以爲玩家制作遊戲 –