Timeline for Developer keeps underestimating tasks time
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Jan 25, 2021 at 13:04 | history | suggested | ericjose | CC BY-SA 4.0 |
fixed grammar
|
| Jan 25, 2021 at 12:30 | review | Suggested edits | |||
| S Jan 25, 2021 at 13:04 | |||||
| Jan 25, 2021 at 10:56 | history | edited | MCW | CC BY-SA 4.0 |
added 1141 characters in body
|
| Jan 24, 2021 at 20:25 | comment | added | me22 | On the same theme of quantifying the risk, it can help communicating both up (to stakeholders) and down (to developers) to clarify the level of risk desired in estimates. I don't know if your project wants the "if everything goes well" estimate, the 50/50 "as likely below as above" estimate, the "if things follow long-term averages" estimate, or the "we're 99% confident in this one" estimate. They're very different values for the same task/story/epic/project. | |
| Jan 23, 2021 at 16:30 | history | edited | MCW | CC BY-SA 4.0 |
added 765 characters in body
|
| Jan 23, 2021 at 3:02 | comment | added | Frank Hopkins | good answer, I'd add one thing: many devs feel a need to be fast when management types ask for times even if you don't want to pressure at all. For them it feels easily that they are behind and they want to make that up and keep giving optimistic estimates because they tell themselves they make up their mistake to be behind (or that they were so slow last time and will be faster this time). Encourage them to double their estimations by default until they regularly overestimate and only then start to reduce their estimations again. Thy may need to clearly hear long estimates are fine. | |
| Jan 22, 2021 at 12:46 | vote | accept | JM_2021 | ||
| Jan 22, 2021 at 11:38 | history | answered | MCW | CC BY-SA 4.0 |