敏捷估計階段

我身邊有敏捷估計下列元素困惑：敏捷估計階段

應在每積壓的故事，故事點來估算？如果是這樣，誰提供這些估計值。
或者，故事估算應該是Sprint Planning的一部分嗎？
什麼時候故事會被分解成技術任務和由誰來做？
技術任務在幾小時內就可以估算出來嗎？如果是這樣，誰提供這些估計？
如果故事和任務是以不同的單位進行估算的，那麼您是如何測量速度的？

在許多情況下，這些問題的答案是您需要找到適合您團隊的工具。雖然這是有道理的，但很高興聽到其他團隊的作用。

2014-01-19 ceej23

太多的方法來剝皮這隻貓。選擇一個流程，然後根據反饋進行改進。說故事點必須是相同的單位。從點到點的轉換非常有爭議，因爲故事點表明數量和複雜性以及知識水平。建議您獲得Scrum資源。我的經驗中的關鍵是要記住他們是估計，所以不要掛在準確的任務/故事級別。 –

至於我已經試驗：

Grooming backlog會議可以用來估計故事點的故事。建議您這樣做，before the sprint planning，這樣我們就不再需要在這一點上重點估計了（主要是）。

Planning poker可用於讓開發人員評估故事。產品擁有者shouldn't estimate因爲The development team members need to make a commitment about how much functionality they will complete in the upcoming sprint。

關於分解技術任務，恐怕我仍然在自己尋找答案。

來源

2014-01-19 10:59:53 gturri

以我的經驗，下面的效果很好，但它是不由要麼敏捷或Scrum的規定：

你的確可以估算每一個故事在產品積壓，其他比尖峯，在故事點。開發團隊提供了的估計，因爲他們將會做這項工作。
故事估計通常是產品Backlog提煉或 Sprint計劃
用戶故事的一部分期間，Sprint計劃，偶爾在產品Backlog提煉
任務通常以小時爲單位估計，通常得到分解成任務。開發團隊提供估計，因爲他們是會做
用戶故事是用來測量速度工作的，因爲速度是數量故事點的被「搞定」內的衝刺

來源

2014-01-19 11:10:34

敏捷估計階段

回答

相關問題