昨日PM小組例會，談到了需求評估工作量遠大於有效資源情況下，如何保證迭代週期穩定的問題。討論的內容，對於PM如何控制、保持迭代週期穩定有較大的參考價值。

有效資源	評估工作量
1	多	少
2	少	多
3	相同	相同

注：
有效資源：指迭代週期內，開發團隊所能提供的有效工作日，單位人/天。
評估工作量：指迭代週期內，產品經理提供需要實現的業務需求所評估的工作量之和。

上表描述以固定週期為兩週的迭代中，可能會出現的有效資源和評估工作量對比情況。其中，1、3兩種情況因為評估工作量小於或等同能提供的有效資源，所以不會影響迭代週期。重點需討論的是有效資源小於評估工作量時，如何保持固定週期？

例舉：一迭代週期，能提供有效資源20人/天，需求評估工作量30人/天。
1、功能較獨立，需求不能拆分發布；
安排一個release，兩個iteration。這種情況需要在迭代2中附加一些技術改造或低優先順序的小需求、bugfix，release日期相對會慢幾天。

2、一個迭代中包括多個產品的需求(需要各位產品經理協商，決定需求優先順序)；
a)、以保證質量為重：
忽略商業優先順序，先處理一個迭代中就能全部完成的需求。

b)、保證價值
分兩個迭代完成，一次release。

通常情況下，我們盡力保證迭代週期的穩定，但也允許例外，如：商業需求，產品上確定了釋出時間點，或者節假期間團隊請假比較多，一個迭代所能提供的有效資源相對比較少的情況。

保持迭代週期穩定，其核心是：固定Timebox和可提供的資源，讓產品經理來決定需求的優先順序，每迭代只接納(開發/QA資源)可承受的需求。