本文是敏捷開發產品管理系列的第五篇。（序言及設立迭代目標，產品版本規劃，產品使用者群規劃，新產品研發，預估會議，product servant，product owner團隊，產品線管理）
粗估會議是乙個較少使用的敏捷實踐，但其作用還是很明顯的。
scrum裡邊，有兩個關於需求的比較頭疼的問題。
乙個是po不太懂技術，不知道故事大約需要多久才能完成。為什麼po要知道？因為如果劃分的顆粒度不好，會導致有的故事太大或太小；而且如果不知道故事的大小，就比較難大致**未來的幾個迭代能做完哪些故事，版本計畫不好做。
二個是如果只依賴短暫的sprint planning meeing，往往團隊對故事的理解不夠深刻。人的思維方式往往是分為兩種的：一種是集中思維，就是現場的講解問答；另一種則是分散的思維，就是「回去以後越想越不對勁」的那種，後者如何利用呢？
開乙個預估會議把。
有一家遊戲公司，會在每次sprint planning meeting前一天，先把整個迭代要開發的大致內容講解一下。這次講解，未必是按照故事條目來的，更多的是整體的介紹。因為遊戲的需求相對複雜，而且關聯關係很重，所以有必要整體把握以下。這很像拍攝電影，導演會把下乙個場景整體介紹一下，才會分解鏡頭拍攝，否則整體感和連貫感會很差。
有乙個日本企業，則是在30天迭代的第10天左右，開下乙個迭代的預估會（或稱為**會也行），整體就是提前20天介紹一下下個月有什麼事情要做。這個目的，則是讓隊員在剩下的20天裡邊，都會潛移默化地思考下個月的事情；另外就是在開發本月內容的時候，如果成本很低，會提前做一些準備工作（比如預留點介面。「過度設計」很容易造成浪費應該避免，但是為20天後的工作內容做準備，則極少會浪費，所以值得）。
在預估會上，po給大家講解整體需求，和他對下個迭代的期望，以及他提前拆分出來的幾大塊或幾小塊內容（看工作習慣了）。
團隊會分析這些內容的關聯性、實際工作內容、工作量規模等內容，必要時拆分故事，描述故事的依賴性，並進一步幫助po形成條目化的使用者故事。
po在形成有工作量預估的使用者故事後，會重新計算和規劃下乙個迭代的工作內容，讓其能更完整地組成乙個發布。
當然這次估算不一定準確，力求做到條目化和拆分即可，準確性由參會者在直覺上保證都可以，畢竟在計畫會上還會細化。
有時候整個團隊參加，尤其那些對完整性要求比較高的產品，比如遊戲。
有時候只讓小組長或骨幹參加，他們會把參會的內容傳達給自己的隊員；更少的參會人員，可以降低對其他無關人員的工作量占用影響。
這取決於產品和團隊的情況，試著開幾次會議，自然會發現怎樣才是合適的。
po開完會議後，可能有這樣一些工作要做：
1. 記錄下來最終被條目化的故事。
2. 在計畫會之前，把會議上似是而非的一些內容敲定。
3. 根據故事的大致規模，規劃下乙個迭代的內容。應本著相對完整內聚的原則，組織成乙個使用者能真正拿到並完整工作的產品。
4. 按照moscow排序出下個迭代的內容。（moscow請參考 ）
敏捷開發產品管理系列之四 新產品研發
本文是敏捷開發產品管理系列的第一篇。序言及設立迭代目標，產品版本規劃，產品使用者群規劃，新產品研發，預估會議，product servant，product owner團隊，產品線管理 這裡所指的新產品研發，不是指自己企業的新產品，而是特指那種在行業中初創，前途不明，尚需市場檢驗的新產品。敏捷開發可...
敏捷開發產品管理系列之二 產品版本規劃
本文是敏捷開發產品管理系列的第二篇。序言及設立迭代目標，產品版本規劃，產品使用者群規劃，新產品研發，預估會議，product servant，product owner團隊，產品線管理 本文是一篇舊文，原名為 迭代期內無變更 與敏捷開發產品版本規劃 因符合本系列內容，做相應修改後重新編排發出。支援派...
敏捷開發產品管理系列之二 產品版本規劃
本文是敏捷開發產品管理系列的第二篇。序言及設立迭代目標，產品版本規劃，產品使用者群規劃，新產品研發，預估會議，product servant，product owner團隊，產品線管理 本文是一篇舊文，原名為 迭代期內無變更 與敏捷開發產品版本規劃 因符合本系列內容，做相應修改後重新編排發出。支援派...