1. 此案因為需求明確，使用敏捷式開發適不適合的，敏捷式開發適合需求變動頻繁、產品需快速迭代與驗證的開發情境。建議應該根據需招標要求明確回應與展開本案應該交付的項目。
2. 文件內容大部分描述不明確，合作文件沒有雙方簽名與用印，不具代表性。
3. 公司與相關產品年輕，需要再提供更多交付能力佐證證明；人力看起來真正負責開發的人只有1-2人，考量本案交付金額與交付時程，令人疑慮，應該提供更多的開發規劃內容。
4. 目前只能看出交付、檢討的週期是以 Sprint (如2週) 為單位。如果是這麼大的案子，要交代 Scrum 協作方式的細節，建議至少要有以下要素
建議 Sprint 裡面要以 User Story 為單位，User Story 是跟所有利害關係人，包含非技術人員溝通的最小單位。User Story 裡要有 Acceptance Criteria （驗收標準）
往上建議劃分 MVP 0, 1, 2。（MVP = Minimum Viable Product（最小可行產品））
列出每個階段要完成的範圍
再劃分要以幾個 Sprint 完成
例如 MVP 0 要達成 XXX，需要4個 Sprint
Sprint 1 裡面會有 哪些 User Story，這樣也方便驗收、歸屬功能需求要在哪一期完成
Notion 這個月有更新內建的 Sprint，建議直接採用，能減 少很多自己拉關聯的負擔