推測階段：制定基于功能或性能的里程碑、版本和迭代計劃，從而交付愿景價值。

敏捷計劃的五個層次

敏捷愿景：在敏捷章程中記錄，為敏捷的第一層計劃。

產品路線圖為產品負責人所擁有，是產品需求的高層次概述，常用作特性優先級排序、特性分類和粗略實踐框架確定工具。它是動態的

發布計劃：又叫版本計劃，一個高層級的計劃。由多個迭代組成，交付完整的有價值的功能，是以功能為導向。一個項目包含一個或多個版本，一個版本包含一個或者多個迭代。

用戶故事地圖是backlog的二維圖形化展示，它反應了故事的優先級及先后順序。通過它可以用來做我們產品地圖替代傳統的產品發布計劃。

里程碑計劃一般做到故事層，經常用作重大的同步點和集成點，比如對于哪些既有軟件也有硬件的產品，或者高層關心的重點特性交付時間點。

迭代計劃：比版本小，通常一周到一個月，聚焦于實現本迭代所應用開發的用戶故事的詳細任務及任務的下發，是以技術為導向。

每日站會計劃：對于Scrum框架中的每日懺悔，它提到的3個問題中的兩個就可以被視為每日站會計劃。敏捷團隊中，重點考慮版本計劃、迭代計劃和每日站會計劃。

各個計劃都是動態調整調整的。只是所處的計劃層級不同。

ROI/NPV/IRR/EVM

ROI(Return on Investment)投資回報率，即收益與投資總額的比值。等于年利潤或年均利潤/投資總額×100%。

NPV 凈現值，等于收入現值-支出現值，考慮時間價值，NPV越大越好。

IRR 內部收益率，資金流入現值總額與資金流出現值總額相等，凈現值等于0時的折現率。內部收益率 IRR≥0，可接受，且越大越好，IRR<0，不可接受，考慮時間價值。

EVM 掙值管理針對于迭代，SPI=實際完成的故事點/計劃完成的故事點;CPI=掙值/實際花費。

卡諾分析與MoSCoW

Kano用于給需求進行優先級排序,它將需求分為以下四種類型：

作為閥值的功能：必須的功能：是產品要成功就必須具備的那些功能。改善增加閥值功能數量到一定程度，對客戶滿意度提升就沒有多少影響了。

線性功能：“越多越好”的功能。它的改善與數量增加能直接提升用戶滿意度，它的降低和數量減少也直接降低用戶滿意度

興奮點和驚喜點：指提供了很高滿意度，并常常為產品增加額外價格的哪些功能。但是缺少它不會讓客戶滿意度降到中性以下。

無關緊要屬性：這些特性無論從哪方面來說對客戶都沒有影響。因為客戶對其根本就不關心，我們應該努力著消除、最小化或者延遲交付這些特性。

MoSCoW

莫斯科法則，就是must or should，could or would not，用于給需求進行優先級排序

按照：Must：必須做的；Shoud：應該做的；Could：可以做的；Would not：不要做的，來做，保證PO所需要的Must、Should完成，并力爭Could能完成。在響應變更時，優先考慮犧牲Could乃至Should需求特性

用戶故事

用戶故事描述了對用戶、系統或軟件購買者有價值的功能，用來收集客戶需求。在卡片正面描述用戶的需求，在背面描述該功能對應的期望：如估值、交付實踐、驗收標準等。正面描述實例如下：

另外用戶故事需滿足INVEST屬性，并遵循3C原則

DoD

Definition of Done，工作完成準則。是幫助干系人對項目工作達成一致的必要準則，由團隊所有成員一起決定，一般在敏捷各個層次的計劃上制定，包括如下三個層級：

發布DoD如：完成發布規劃范圍內的哪些需求；至少通過一次發布的回歸測試；修復所有等級為1、2的缺陷…

迭代DoD如：所有完成的用戶故事已驗收；所有代碼得到靜態分析，糾正最高級別的不符合項；所有新增代碼得到評審；所有完成的用戶故事都有對應的測試用例…

用戶故事DoD如：用戶故事最終的描述符合INVEST；用戶故事都有對應的測試用例…