我有以下用驗收標準的用戶故事示例。用戶故事驗收標準示例
我想知道是否允許我描述如何改變GUI以支持新功能。
這是我的例子：
用戶案例：
驗收標準：
可能是相關的正確的驗收標準？
親切的問候， 啓。
那麼，不管這個問題是否被遷移，我想我會留下我的意見。
驗收標準由產品負責人選擇，簡單明瞭。這是一種形式化產品負責人需要看到能夠在故事上簽名爲「完整」的方式。
PO想要投入多少細節因此是PO的工作風格，知識等的產物。許多PO都有UX培訓，並且希望進一步定義它的外觀。 我認爲這很好，只要它適合你的團隊。其他人主要是客戶專家，並將設計留給團隊。
就我個人而言，我會鼓勵團隊在觀察故事時儘可能多地形式化，以便儘量減少團隊與採購訂單之間相互衝突的假設數量。
但是最終由團隊決定是否接受故事進入他們的衝刺。無論如何，他們都有權利（在Scrum中）說AC太寬泛，過於規範，不可行，或者太大而不能在一次衝刺中咀嚼。因此，在就每個故事達成一致之前，團隊和採購訂單之間通常會進行很多談判。
但是，最終，產品負責人呼籲，因爲她會做「接受」。一般來說，Scrum說產品負責人的工作就是說要建立什麼，並且團隊的工作要說如何建立它（以及實際完成它）。所以真的是關於你想成爲什麼類型的採購訂單。
根據我的經驗，馬克的回答是關於OP列出的AC適用性的錢。然而，儘管這些標準是可以接受的，但我建議他們不足以減少PO在產品被接受時期望產品做什麼的模糊性。
除了列出的AC其描述如何的故事將被執行，我希望看到的AC描述什麼產品做。例如，這些組對論壇用戶和管理員都是可見的嗎？你如何定義「連接」？業務邏輯與用戶和組織綁定的細節是什麼？這個故事是否涵蓋了用戶對羣組的「映射」和「解除映射」，還是將它們分開以保持故事的可擴展大小？
您可能希望將驗收測試添加到用戶故事中。 My question可能會給你一些關於他人如何處理用戶故事規範的觀點。
我會在適當的驗收測試中描述用戶如何與UI（即UX）進行交互，而不是驗收標準。該標準更適合輸入驗證和其他業務規則，這些規則不需要在更高級別的驗收測試中進行覆蓋。
嗨啓，歡迎來到StackOverflow！這個問題實際上對於本網站的任務來說有點偏離主題，這是關於回答特定的*編程*問題的。我建議將它移植到[程序員StackExchange站點]（http://programmers.stackexchange.com/faq）。 –
這個問題是脫離主題，因爲它不在本網站的範圍內，如[我可以在這裏詢問什麼主題？]（// stackoverflow.com/help/on-topic）中定義的。另請參閱：[什麼類型的我應該避免提問？]（// stackoverflow.com/help/dont-ask）您可以在[另一個Stack Exchange站點]（// stackexchange.com/sites#name）上詢問，例如[pm。 se]或[softwareengineering.se]。請務必閱讀幫助中心中針對您打算髮布問題的任何網站的主題頁。 – Makyen
我投票結束這個問題作爲題外話，因爲它不是關於編程。 – TylerH