有的需求問題是不可能在user story 的review過程中全部發現的。 有些問題只有在你真正寫代碼的時候纔會發現，例如這個user story和另外一個有衝突, 這個user story的前置條件在系統還沒有實現等等。
通常的形式是 郵件或者IM，希望BA儘快回答問題。這無形中就是就一種形式阻礙。 需要在daily scrum meeting提出。
但是大多數情況，我們會到到BA的答覆很遲緩，有時候甚至得不到答覆。比較好的形式是要責任到人。
1. 可以用現有的工具如Jira或者excel列清條目，指定owner, 一定要設due date, 每次都明確的發出。讓PO也瞭解到。
2. Jira其實比較好，因爲有ownership,BA在轉回給你之前，必需添加回復的註釋或者答案。 或者如果長時間在BA的名下，就是BA的責任。