Je úplne logické že keď o Story Points rozmýšľam ako o čase, na konci sprintu prepočítavam SP na Man-Days, že nakoniec sú iba časovou jednotkou. Takou, ktorá nakoniec komplikuje všetko od odhadov až po porovnávanie tímov.

Tím potrebuje mať benchmark, aký typ taskov sú 3 SP a čo 5. Čiže namiesto “toto by mi zabralo 3 dni” premýšľam o ďalšej jednotke, na ktorú svoj čas prevediem. Namiesto pomenovania vecí “ako sú” hovorím v záhadných termínoch, ktorým iní nerozumejú.

Aby som vedel čo za úlohu to je, tak okrem termínov teda potrebujem akúsi tabuľku ktorá mi bude prevádzať SP jednotlivých tímov na man-day. Teda zase na čas.. Načo vkladať pred man-days story pointy?

Súhlasím. Máme dvoch programátorov. Junior a senior. Kým za jeden pracovný deň senior stihne pripraviť task až po nasadenie, junior ho bude mať akurát tak rozrobený. Man-day seniora môže mať hodnotu 2-3 MD juniora. Ako to teda nastaviť?

Budeme cieliť na to, kam sa (predpokladám) chceme dostať. Junior rastie, senior sa sotva zrýchli. Tasky ohodnotím akoby ich robil senior.
A juniorovi (alebo novému kolegovi) nastavíme laťku. 2 SP za týždeň. Neskôr 3, neskôr 4. Až je z neho senior. Pričom neprichádzame pri groomingu o možnosť “odhaliť” iný pohľad developerov na task.

Preto nepoužívame man day ako jednotku, ale kľudne aj story pointy (alebo čokoľvek čo dáva zmysel alebo znie fancy). Ale story pointy sú prepočítateľné na čas. A čas na peniaze. So zohľadnením seniority. Ľudia zvonka vedia, koľko práce si pod 5 SP predstaviť a biznis aj koľko 5SP stojí.