In Agile project management, how do we estimate the completion date to win a contract?
Let's say we want to get a contract. A customer describes what he wants and asks us for when we provide them a completed product.
We are going to use Scrum. How do we calculate the amount of time we need to complete the work?
There are two parts to this answer. The first is how you estimate and the second is if the premise of your question is inherently problematic.
First, the estimation. Generally speaking, there are two broad types of estimation: relative and absolute. Absolute is what we think of in traditional project management. You take a list of tasks and guess at how long they will take based on past experience. Of course, the problem with this is that most knowledge work is very different from task to task making absolute estimation an educated guess at best and a shot in the dark at worst. The fact that you say there are a lot of research tasks means it's probably closer to the shot in the dark.
The second is relative estimation. This is no more accurate than absolute. It is basically using statistical distribution to get "close enough". The potential benefit of relative estimation is that it makes the fuzziness of the estimate obvious and clear.
This desire for a clear answer in estimates matched with the near-impossibility of providing it has gone on as long as there is knowledge work, it's why most people pad their estimates, and it's why projects almost never finish on time. Pragmatically, I can only say that if the only way to win the contract is to give them a date, then give them a date. It'll be wrong, just like every other project. Ideally though, you have a customer who values transparency and prefers to talk in rough forecasts, not absolutes.
Why Use Scrum?
So, the second half of this is basically, why would you use Scrum for a fixed date, fixed scope project? The entire point of Scrum is that you learn what you need as you go. Each sprint has the potential to be a small pivot or a complete re-imagining. Scrum, as a framework, was designed for those types of projects. You will pay a lot of overhead for no value if you plan to create a plan and then simply follow it to completion.
Now, that said, if I were running a software company, I'd use Scrum, but I'd probably only take on contracts where I was able to get the customer into an effective conversation about why they want a Scrum company. That's a choice for your company though.