如何更改故事點以便在Scrum中使用估計

Question

使用「days」作爲Scrum中任務估計的單位後，我發現很難更改爲使用Story Points。我相信故事點應該被使用，因爲它們彼此之間更具可比性 - 不太依賴任何處理任務的人的資格等。但是，當團隊習慣使用故事點時，開始使用故事點並不容易以天計算。

那麼，如何讓團隊變成故事點？什麼能激勵團隊成員這樣做，我們應該如何應用轉換？

Answer 1

如果你想改變爲使用故事點而不是持續時間，你只需要開始估計故事點。 （我在這裏假設你有權爲你的球隊做出這樣的決定。）

選擇一個比例尺，可以是小的，中等的，大的可以是斐波那契數列，可以是1到5，無論選擇哪一個並使用它爲幾次衝刺，這會給你你的速度。如果你開始改變從一個到另一個的尺度，那麼尺度之間的速度就不會是可比的（即不這樣做）。這些估計值應該包括你所有的Scrum團隊。

說了這麼多，你仍然需要知道這會花費你多少錢。沒有許多會計師會接受答案：「我會告訴你6個月內會花多少錢」。所以你還需要估計項目的持續時間，這會給你帶來成本。這個估算可能會由團隊中的高級人員完成

然後每個月你的速度會告訴你和會計師第一次成本估算是多麼準確，你可以相應地進行調整。

Answer 2

首先讓一天等於一點（或一些嚴格的比例）。這是一個開始的好方法。在幾次衝刺之後，你可以開始鼓勵他們使用更多的相對點（即與這件事相比有多大）。

Answer 3

問題是故事點定義了努力。

天是持續時間。

這兩者有一個幾乎隨機的關係。 。該功能基於實際工作人員的技能。

一個人知道他們將花多長時間完成這項工作。這是持續時間。在幾天內。

他們不知道這個抽象'努力'的事情。他們不知道平均技能的假設人需要多長時間才能完成這項工作。

你可以做的最好的是兩個故事點（努力）和天（持續時間）。

你不能用另一個替換一個。如果您嘗試僅使用努力，那麼您最終需要花費數天才能進行規劃。你必須將一個人應用到故事點，並通過努力來計算持續時間。

Answer 4

當我轉向積分時，只有當我能夠滿足以下兩點時才決定使用積分： 1）發現和論證，證明切換，並說服團隊2）找到一個簡單的方法來使用它。

說服

我花了大量的閱讀關於這個問題，但一終於找到了說服了我和我的團隊的說法：這幾乎是不可能找到兩個程序員，將在時間的任務達成一致將採取，但同樣的兩個程序員幾乎總是會同意在顯示兩個不同的任務時哪個任務是最大的。

這是您需要'估計'您的待辦事項的唯一技巧。在這裏，我使用「估計」一詞，但在這個早期階段，更像是將積壓從艱難轉變爲簡單。

在積壓

將點放在這一步與整個Scrum團隊的參與下完成的。

開始在一個新的電子表格中逐一放置故事，同時保持以下順序：最上面的故事和最下面的故事。直到所有故事都在列表中。

現在是時候在這些故事上加分。我個人使用撲克規劃量表（1/2,1,2,3,5,8,13,20,40,100），這是我將用於這個例子。在該列表的底部，您可能會有微型任務（需要4小時或更少的時間才能完成）。給每個微任務1/2的值。然後繼續向列表中提供值1（規模的下一個），直到明確故事更大（2而不是1，所以兩倍大）爲止。現在使用值'2'，繼續列表直到你找到一個應該明確具有3而不是2的故事。繼續這個過程直到列表的頂部。

注：儘量保持絕大多數點在1和13之間。第一次你可能有一堆大故事（20,40和100），你必須將它們制動成大塊小於或等於13.

這就是爲了積分和原始積壓。如果你有一個新的故事，將它與該列表進行比較，看看它適合哪裏（更大/更小的過程），並給它的鄰居的價值。

速度&估計

估計將需要多長時間，你要經過積壓，做了第一個衝刺計劃。使團隊挑選的故事和VOILA！的總點數相同，這是您的第一個速度測量。然後，您可以將積壓點中的積分總和除以該速度，以知道需要多少衝刺。

那速度將有所改變，在第2-3衝刺定居所以它總是好的，盯緊該值