How to use data to come up with estimates for tasks?

The easiest heuristic here is just to pattern-match on historical data. If you're doing project X, find something that looks similar to project X in the past year, and that should be the starting point for your estimate. See Alex's great answer here.

The question of a reasonable time to come up with estimates is what I refer to as "a date for a date". This is a great practice of doing some legwork to better scope and understand the project. A few inputs for how long this should take:

• It's directly correlated with the length of the project. e.g. if the project takes 6 months, it's reasonable to spend a few weeks to feel better about the estimate. If the project takes 1 month, you shouldn't spend more than a week.
• How many people are you reliant on for the work? If there are many teams that need to approve the code, for example, or you're waiting on some migration by another team, you should accommodate time for that.
• Understand how many unknowns there are, which will likely be revealed once you start implementation. Add buffer for these.

If you feel like you don't have enough context, check out this detailed discussion.

How to use data to come up with estimates for tasks at the initial stages?

As Rahul mentioned, use historical data (go through past launches and their retrospectives + ask around). So for example if your project requires building 5 new microservices and it usually takes 1 week to add 1, this portion will take 5 weeks.

What's a reasonable time to come up with the estimates themselves (if there's research involved)?

From my experience at Meta (another Big Tech company), allocating around 10% of the time for planning worked out well for me. Here's some examples to clarify:

1. Project has a quarter to complete (13 weeks) - I would allocate around 1.5 weeks for planning.
2. Project has a half to complete (26 weeks) - I would allocate around 3 weeks for planning.

This will vary based on organization. Some orgs care less about quality and want to move fast, so you have less time for planning. Other orgs are extremely careful and want to move more steadily (this is common with orgs that are mature and have lots of compliance requirements), so you will have more time for planning. I would ask your manager what a reasonable timeframe is to come up with the overall plan/estimate and again use historical data (i.e. how much time your more senior teammates used for planning on prior projects) to figure out a reasonable timeframe.

Here's some other good resources:

• "How do I create proper timelines and roadmaps for my projects?"
• "How can I get better at estimating long-term projects?"