←back to thread

Estimates are difficult for developers and product owners

(thorsell.io)
225 points todsacerdoti | 2 comments | 07 Dec 25 19:17 UTC | HN request time: 0.001s | source
Show context
jph ◴[07 Dec 25 19:58 UTC] No.46184595[source]▶
When teams don't need strong estimates, then Kanban works well.

When teams do need strong estimates, then the best way I know is doing a project management ROPE estimate, which uses multiple perspectives to improve the planning.

https://github.com/SixArm/project-management-rope-estimate

R = Realistic estimate. This is based on work being typical, reasonable, plausible, and usual.

O = Optimistic estimate. This is based on work turning out to be notably easy, or fast, or lucky.

P = Pessimistic estimate. This is based on work turning out to be notably hard, or slow, or unlucky.

E = Equilibristic estimate. This is based on success as 50% likely such as for critical chains and simulations.

replies(4): >>46184658 #>>46184788 #>>46185046 #>>46185692 #
1. Marsymars ◴[07 Dec 25 20:22 UTC] No.46184788[source]▶
> E = Equilibristic estimate. This is based on success as 50% likely such as for critical chains and simulations.

I've found giving probabalistic estimates to be hopeless to effectively communicate, even if you assume the possible outcomes are normally distributed, which they aren't.

replies(1): >>46196632 #
2. jph ◴[08 Dec 25 19:39 UTC] No.46196632[source]▶
Critical chain planning has a purpose for the 50%. It's not perfect-- but it's better than other ways, in my experience.

Wikipedia: "The justification for using the 50% estimates is that half of the tasks will finish early and half will finish late, so that the variance over the course of the project should be zero... Because task duration has been planned at the 50% probability duration, there is pressure on resources to complete critical chain tasks as quickly as possible, overcoming student's syndrome and Parkinson's Law."