使用敏捷電子表格進行發現估計

本文包含一個預先格式化的電子表格，可幫助您開發敏捷發現估計。 它還包括幫助您遵循特色示例的信息。 您可以從此處的模板製作可編輯的副本（文件>製作副本或文件>下載）。

在我組建團隊或了解 MVP 要求之前，客戶經常要求我提供敏捷估算。 在這個早期階段，我無法使用速度、衝刺數量或團隊成本等傳統指標來計算這些估計值。 但客戶想要答案。 他們能在兩個月或六個月內推出一個假設的產品嗎？ 他們的（通常很低的）預算是否可行？

輸入敏捷電子表格。

電子表格是敏捷思維方式的合適選擇，但經常被忽視。 它們是鼓勵協作的低技術、高接觸工具。 也就是說，只要產品的成本和質量滿足他們的要求，您的客戶可能並不關心您的工具是否“敏捷批准”。 電子表格的真正價值在於它們對所有經驗水平的項目經理和利益相關者的可訪問性。

許多專業項目管理工具的學習曲線對於快速移動項目的沒有經驗的用戶來說過於陡峭。 因此，客戶、產品所有者和開發人員更新需求和勞動力成本越容易，您就越早得出現實的估計。 使用預先格式化的電子表格，項目經理可以調整值和參數，以展示每個波動資源或移動時間線的影響。

電子表格也是與同事分享知識的好方法。 我使用的電子表格源自 Toptal 的一位同事，此後我製作了一份副本並對其進行了修改以滿足我的需要。 我鼓勵你也這樣做。

在本文中，我將演示如何提供成功的發現估計，使客戶和利益相關者能夠與項目目標保持一致並繼續開發。 以下是如何填補空白並提供您可以支持的早期估算。

首先解決產品願景和路線圖

假設您的客戶想以固定預算開發一個約會網站，但產品的細節卻很模糊。 在不了解團隊成本和速度的情況下，產品願景是最好的起點，因為它需要利益相關者就設計目標達成一致並提高整個團隊的透明度。

我喜歡 Scrum.org 產品願景格式的直觀敘述風格。 這是它的樣子：

設定產品願景後，您可以在新的電子表格選項卡中添加產品路線圖，讓客戶了解長期項目計劃。 路線圖應列出每個產品路線圖版本的目標、關鍵特性和截止日期。

路線圖版本是指導其市場軌蹟的產品的計劃、面向消費者或客戶的版本。 第一個路線圖版本是您可以在市場上首次亮相的產品。 隨後的路線圖版本代表具有與產品願景一致的引人注目的新功能的市場版本。

以微軟為例：Windows 8 可能是一個路線圖版本。 Windows 10 是另一個路線圖版本，具有許多新的和理想的功能。

一旦產品願景和路線圖完成，就該要求客戶承諾 MVP。

使用三重約束圖協商 MVP 功能

現在是使用三重約束圖表來塑造客戶對時間和費用的期望的時刻：

在瀑布方法中，固定功能決定了時間和成本，並且根據詳細的項目計劃進行開發。 相反，敏捷的固定成本和進度決定了產品的功能，並且這些功能會根據更靈活的項目願景不斷地重新排列優先級。

三重約束圖表向客戶表明，在第一個版本中包含所有所需的功能將增加開發時間和氣球成本。 取而代之的是，與客戶一起為 MVP 選擇“必須具備”的功能，並列出任何剩餘的功能以供將來發布。

電子表格可以根據客戶的不斷變化的需求，輕鬆地將功能分組和重新分配到不同的版本、版本和優先級，並且它們會立即顯示這些更改的成本。

在您確定 MVP 功能時，請向您的主題專家 (SME) 尋求幫助，根據他們從事的類似項目列出項目的步驟。 稍後您將使用這些步驟來創建史詩。 一旦你準備好這些輸入，你就可以開始建立一個估計。

從 T 卹尺碼開始

要開始第一個積壓工作，請向產品所有者詢問產品功能的詳細描述，然後根據每個功能的難度級別為其分配 T 卹尺寸。

在您獲得任何絕對值之前，T 卹尺寸將顯示每個開發任務的相對複雜性和持續時間。 隨著我們對項目計劃的深入了解，我們會將這些相對大小轉換為故事點和工作時間。

例如，如果您的客戶希望您在約會網站上開發一系列彈出窗口，那將是耗時但簡單的。 您可能會將任務複雜性描述為“小”，但工作量將是“中”。 您可以將其縮寫為“SM”。 另一方面，由於所有必需的文檔和測試，為新 API 開發後端連接將是一項更複雜的任務。 為此所需的技能和注意力可能使其在努力和技能水平上都成為“大”：“LL”。

完成 T 卹尺寸調整後，您將對每個未來團隊成員的相對工作量和技能要求有所了解。 然後，開發團隊的技術專家可以幫助您將 T 卹尺碼與時間範圍和故事點相關聯。

設置你的參數

現在您已準備好使用電子表格併計算您的估算值。 首先創建一個參數選項卡。 這將作為您計算的關鍵，您在此處輸入的值將輸入到您的待辦事項/用戶故事和按發布選項卡估算摘要中使用的公式。

這是您在“參數”選項卡中需要的所有內容：

貨幣。 這是您輸入貨幣換算的地方。 例如，如果客戶的預算是巴西雷亞爾，您可以輸入美元或歐元的當前兌換率。

開始日期。 預計開發開始日期將用於創建項目時間表。 在每個示例中，我們的開始日期都是 10 月 25 日。

初始預算。 預算提供了約束，顯示是否所有 MVP 功能都適合它。

T 卹尺碼。 以表格形式輸入您的 T 卹尺碼，並為每個尺碼組合分配故事點和小時範圍。 在此示例中，SS 使用 1 到 2 小時，LL 使用 33 到 48 小時。

請記住，您的衝刺持續時間將限制您最大 T 卹尺寸的小時數。 如果衝刺只有一周，最大的規模不能超過 40 小時。 這就是為什麼在為任務分配 T 卹尺寸時諮詢 SME 如此重要的原因。

每小時費率。 使用此表記錄每個角色的工資率。 如果您的後端開發人員有不同的費率，請使用兩者的平均值。

高架。 將項目總工作量的一部分分配給管理任務，例如狀態會議、反饋會議和項目修訂。 百分之十（或每個參與者每週工作的四個小時）是一個很好的起點，但對於更複雜的項目，開銷可能會更高。

意外情況。 這表明您的估計中的潛在差異。 考慮到您在電子表格中輸入的值，從 0% 的意外事件開始將向您顯示最佳情況（即不太可能）的預算和時間表。 稍後在我們的示例中，我們會將意外事件增加到 50% 的粗略數量級 (ROM) 方差，以顯示成本和項目持續時間的潛在高端。 隨著您獲得更精確的數字，意外事件將減少。

每個版本的大小與史詩

我們從整個產品的粗略尺寸開始，以確保我們不會浪費客戶的時間或金錢。 根據規模與他們提出的預算和截止日期的接近程度，客戶可能會決定放棄該項目或投資於更詳細的估算。 因為此時我們沒有太多細節，所以我們在 Backlog/User Stories 選項卡中輸入主要功能作為史詩。 然後，對於每個史詩，我們輸入 SME 和開發負責人根據“參數”選項卡中的 T 卹尺寸表為每個開發堆棧建議的小時數。

首先，選擇“EPIC？”列並確保只選擇了“史詩”。

接下來，寫下史詩描述並輸入開發堆棧每一列的小時數。 例如史詩級的《安全連接和登錄》大約需要 8 個小時的 UI 開發，40 個小時用於後端，等等。

請注意，在大多數情況下，“點”列中的單元格顯示“34*”。 如果返回“參數”選項卡，您將看到 34 個點對應於 33 到 48 小時之間的每小時範圍。 如果我們的 sprint 持續時間只有一周，那麼這個小時數就太長了。

一旦我們有了更多細節，這些時間就需要縮短，或者史詩必須分成更易於管理的故事。 然而，為了時間的緣故，我們將忽略點列並繼續粗略估計。

現在轉到 Estimate Summary by Release 選項卡。 在電子表格的頂部，您將看到“參數”選項卡中定義的“開銷”和“應急”值。 您還可以選擇一個按鈕來按史詩或用戶故事顯示估算值。

因為我們還沒有要顯示的用戶故事，所以請選中“史詩模式”按鈕。

您現在可以看到 MVP 的粗略成本和時間表，以及未來版本（R3 和 R4）中不太緊急的功能和更新。 在此示例中，第二個版本 (R2) 為空，因為客戶已要求在第一個版本中啟動所有 MVP 史詩。

您現在可以看到最樂觀的總成本：28,810 美元。 這個數字是從 MVP 到 R4 的每個版本的成本總和。

我們還估計了產品交付的最短時間線，這對應於 R4 開發堆棧中的最新完成日期。 項目經理將這些較慢的開發堆棧稱為“關鍵路徑”，因為它們決定了整個發布的速度。

在這種情況下，關鍵路徑是前端開發，完成日期為 1 月 31 日。

現在是時候調整參數以模擬最壞情況的預算和最長的時間線了。

將應急率調整為 50%

我們仍然對產品的工作量和專業知識要求知之甚少，因此我們將在“參數”選項卡中添加 50% 的 ROM 意外事件。 隨著我們了解有關該項目的更多細節，意外事件將減少。

同樣，這裡是 0% 意外事件的總項目估算。

這裡是 50% 的意外事件。

這意味著整個項目的 ROM 估計在 28,810 美元到 41,860 美元之間。 在最好和最壞的情況下，客戶的 20,000 美元預算不足以包括他們願望清單上的所有功能。

50% 意外事件的完整項目完成日期現在是 3 月 14 日，比 0% 意外事件完成日期晚了六週。

與此同時，MVP 將於 1 月 10 日準備就緒。

客戶並沒有放棄該項目，而是要求進行更詳細的估算，看看它是否可能在更短的時間內更接近他們的目標預算。

重新確定滿足最後期限的優先級

假設客戶將 MVP 的目標日期設置為 12 月 25 日，距離 10 月 25 日啟動還有兩個月。

為了提前 1 月 10 日的 MVP 完成日期，客戶同意將兩個 MVP 史詩推遲到下一個版本 (R2)。

電子表格計算此調整的級聯效應。 在這種情況下，MVP 時間線縮短到 12 月 27 日。前端和後端開發是本次模擬的關鍵路徑，因為它們需要最長的時間才能完成。

根據此信息，您可能決定再添加兩名開發人員，以使前端和後端的完成日期與其他開發堆棧保持一致。 為此，請將 MVP“每週工作時間”行中的工作時間從 40 增加到 80。

前端和後端開發堆棧現在都在 11 月完成，QA 成為新的關鍵路徑（完成日期為 12 月 20 日）。 請注意，成本不會改變。 這是因為每個堆棧中的總工作時間保持不變。 不是一名開發人員工作兩週（80 小時），而是兩名開發人員工作一周（80 小時）。

該電子表格還考慮了全職和兼職工作之間的差異。 假設 UI 開發人員將兼職工作。 我們可以將 UI“每週設計小時數”更改為 20 以模擬交付延遲。

按照全時計劃，UX/UI 將於 11 月 29 日完成。

在兼職計劃中，UX/UI 將於 12 月 27 日完成。

再一次，成本沒有改變，但 UX/UI 成為新的關鍵路徑，將 MVP 的時間表延長到 12 月 27 日。

您可以繼續這種反複試驗的方法，直到根據您的資源和客戶的最後期限到達可接受的關鍵路徑。 一旦適當的截止日期到位，就該開始微調您的估算了。

使用用戶故事優化您的估算

由於 50% 的意外事件估算超出了客戶的預算，因此值得細化您的變量，以便您可以降低意外事件並獲得更現實的估算。

為此，請與您的開發人員和 SME 合作，將您的史詩分解為詳細的用戶故事。 故事比史詩定義得更好，因此我們可以更準確地確定它們的大小。

接下來，根據任何新信息調整參數選項卡中的值。 例如，您的 SME 和開發團隊可能對每個角色有一組更準確的費率，並且可能還希望調整 T 卹尺寸和積分分配。 有了這些新參數，您可以對自己的計算更有信心，並將意外事件降低到 25%。

讓我們看看我們如何將史詩分解成更小、更詳細的用戶故事：

與需要手動輸入每個堆棧的估計小時數的史詩估算不同，故事估算使用 T 卹尺碼作為快捷方式。 這就是您在“參數”選項卡中輸入的 T 卹尺寸派上用場的地方。

在 Backlog/User Stories 選項卡中的“T-shirt Sizing”下，輸入您的開發人員和 SME 為每個故事分配給他們的堆棧的尺寸組合。 從那裡，電子表格公式將自動填充“參數”選項卡中的相應小時數。 請記住，最大尺寸 LL 必須保持在 34 點以下，以確保它可以在您商定的 sprint 持續時間內完成。 任何仍然評分為 34 分或更高的故事都需要細分。

確保為所有故事分配的點數少於 34 點後，取消選中 Estimate Summary by Release 選項卡上的“史詩模式”按鈕，以便僅查看“故事”。

現在你會看到一組新的數字：

在詳細說明所有任務並僅堅持 MVP 功能之後，時間線和成本現在符合客戶的要求。 由於餘額完全在他們的預算之內，客戶決定繼續使用 MVP 並在提交其他版本之前對其進行測試。

讓它成為你的

電子表格易於使用，並且具有一些基本的公式知識（不需要宏），您可以調整它們以適應幾乎任何需要。 如果您的 Excel 知識生疏，Udemy 和 edX 的在線課程將幫助您重溫這些技能。

本文介紹了發現估計，但您可以使用相同的電子表格來生成燃盡圖/燃盡圖、調整時間線並根據速度和衝刺計算估計以供後續階段使用。 我使用我的自定義電子表格來補充應用程序，例如 Jira、Asana 和 Trello，並堅持認為它們是我的項目管理工具包中的強大工具。 我希望它們對您同樣有用且用途廣泛。

與現成的項目管理工具相比，您更喜歡自定義電子表格嗎？ 在評論中告訴我們為什麼或為什麼不。