Estimation VS Guesstimation
While working for PayPal I’ve noticed that it is common for Product to set expectations with leadership through high-level estimations. But we as engineers are responsible for correcting those expectations on time.
The featured image above is a real two-person Gantt chart from one of my latest features at PayPal —at the time of writing—.
Product estimation: January 18, 2022.
Engineering estimation: March 31, 2022.
A difference of 5 sprints of work. Let that sink in for a bit… FIVE! Roughly, around two and a half months!
The estimation by Product was calculated dividing the scope into tasks and subtasks and then “reasonably” separating the tasks by sprint. But this isn’t accurate, and it adds up in the end.
The actual effort estimation by Engineering also revealed design gaps, missing dependencies, and integration issues which were not accommodated in the original plan.
What does this really mean?
It means that from Jan 18 to March 28, leadership would have had weekly meetings asking why the feature was not delivered on time, “as promised”.
See the problem here? The original timeline wasn’t promised by Engineering but by Product.
In the end, it all translates to a stressful environment with Engineering trying to meet impossible deadlines and delivering buggy features.
Conclusion
After the Engineering estimation, we sat down with Product and simply adjusted the timelines or reduced the scope to align with leadership’s expected ETAs.
No hurt feelings. In fact, delayed deliveries trigger —what I call— a “justification chain reaction”. From engineering to management, management to product, product to leadership, leadership to executives, executives to shareholders. Said in a different way, providing accurate expectations makes everyone happy as they don’t have to explain why the feature was delayed.
So, even if you are forced to “guesstimate”, take the time to run an actual effort estimation based on manpower and task complexity. After that, sit down with Product to adjust the timelines early and often.
At the end of the day, having the entirety of the context makes the difference:
I’ll keep you posted on whether the engineering estimation was accurate or not after we deliver the feature.
Update: March 31st, 2022.
The application is currently undergoing end to end (E2E) testing, and we achieved 95% code completion today. The missing 5% is due to scope increase that couldn’t be trimmed for later releases using progressive enhancement.
This scope increase was obviously not considered in the initial estimation but that is okay because when the scope changes, we must obtain a new estimation for each of the features requested and provide the new delivery date to the directly responsible individual (DRI) [see also].
