We need to decide project delivery date before starting sprint

Unless this is a brand new Scrum Team, you should be able to use past behavior as a forecast for current. If you are using relative estimation anything new can still be estimated relative to past work, even if for a different client.  And past throughput and cycle time is still relevant when starting new work if the work is still refined and broken down in the same manner.  

If you have a newly formed Scrum Team then everything changes. In that case you should work with your client to help them understand the methods you use to satisfy the Scrum Framework in order to do iterative delivery.  Explain that process will deliver value as you go and that adjustments can be made faster and easier so that the customer can decide when enough is enough. In that case they are in full control of the costs and time associated to receiving a finished product.  Arrive at a "cost and materials" form of billing so that each Sprint can be paid for instead of the usual model of "total project expense".  

By the way, I would still suggest that you do use my second suggestion with clients even if you do have the ability to forecast as I mentioned in the beginning.  Agile development practices provide much more flexibility to the clients and once they understand that I have found them to be much more appreciative and cooperative. 

I would be very cautious about using Scrum in this setting without further conversations. If the client has in mind some fixed bucket of scope (even if the details may change) and is effectively looking for a date (which may easily become "fixed" in stakeholders' minds), then there may be some key misunderstandings of the intended use and benefits of Scrum, the goal of agility, the need for and value of learning, the importance of product teams, etc.

That said, if you wanted to answer the client on their terms, I would first ask you: is the current scope (as reflected on the Product Backlog) "ready"? Has the team understood the PBIs enough to estimate any/many/all of them?

Client is asking for the approximate delivery date before even starting sprint.

Why not do better than that, and assure them of a very precise delivery date, which will be in exactly one Sprint’s time? Or is there no appetite for incremental delivery and validated learning?

Yes it is a brand new project and brand new project. 

@Daniel, I will discuss the same with product owner. It's basically coaching the product owner. I will share my experience with regards to this. 

@Andrew, Requirements are not many. Entire team had couple of sessions with BA and the team is still in the process of understanding requirements. Requirements are in PPT. Need to be translated in User stories. We do not want to give the estimation now immediately. But most probably by next week.I will make sure we don't give it until and unless team understands requirements clearly.

@Ian, As you have previously also said in some other post that the project duration is one sprint in SCRUM. But the problem is they need timeline for ALL the functionalities. 

...the project duration is one sprint in SCRUM. But the problem is they need timeline for ALL the functionalities. 

What value is Scrum expected to add in this situation? Why isn't the focus on what will be delivered each Sprint, and the lessons about any remaining functionality that might be learned from it?

I strongly agree with Daniel and Ian's points.

In my opinion, it is not evident that your client has a sufficient understanding of Scrum to be able to use it. Scrum is "a framework for developing, delivering, and sustaining complex products" (straight from the first line of the Scrum Guide).

Given that your client seems to think that this brand-new team–which has yet to even begin building this product, and which only has PowerPoint-level "requirements"–can nonetheless still estimate a final delivery date, then they (the client) must think things are rather simple, and not complex at all.

If you or the client still want to use Scrum (and Ian's suggestion to provide the date of the first Sprint Review doesn't fly), then the closest you could get to providing a final delivery date would be to get a backlog full of Ready items, estimate all of them, and give hypothetical dates based on hypothetical average velocity (since there is no track record yet).

If all parties had the right understanding of Scrum, this might be moderately useful information. But given that the client may not understand Scrum, the result more likely would be to create unrealistic expectations and put undue pressure on the Development Team to meet some sort of average velocity goal.

@Ian and Andrew,

It's true the client does not seem to have good understanding of Scrum. As a scrum master I would do my best to coach the product owner who is from client side. 

Noted your views. I would update this thread about how we finally managed to get through this.

Thanks a lot for your valuable time.

Vishal, in my opinion, you are looking at it from the wrong perspective. As the truism goes, take a step back and see the whole picture.

• It doesn't look like a fixed scope project. Would your client be comfortable signing a contract according to which the scope they share with you, say, by May 1st is fixed, with no further changes allowable?
• What's of most value to them? Put the 80/20 to work. 
• Don't waste time estimating everything (or most). Have as many conversations as possible and decide, TOGETHER with your client (through the PO), what is of biggest value/importance to them. Understand all you can, accept that even the most valuable requirements could change, and estimate what has to be estimated.
• Think about maintenance and support (SDLC), training, etc - where are they supposed to sit?
• Advise the PO and BA to start building a backlog, review it daily (as often as needed), order it as they see fit, refine often, release constantly (where?), etc
• Remember it's all about cyclicity. Work, learn and act accordingly.
• etc, etc

In case of a completely new team, what I can suggest to try is to globally estimate what you as a team can do in the next 3 sprints. Collaborate with the client to figure out what is the absolute most important to do in these 3 sprints, what is realistically achievable. Really involve them in the how and why of the Scrum framework. In the meanwhile, have the PO work together with the client, stakeholders and users to form a more prioritized, detailed backlog. Of course, the longer the features/stories are in the future, the less detailed there are. This period of 3 sprints generates some insights about your velocity. As a team, roughly estimate the items in the backlog. Together with the past velocity, you can now give the client a biiit more confidence about when what piece of the backlog potentially will be delivered. 

Also I can recommend taking a more detailed look into the Scrum values. Respect is a value that is very relevant here. Respect for both the customer and team to not take up to much time trying to promise what will be delivered when, because the change that this date changes is rather high (based on research, not per se your team. Maybe your team is reeeeaaally good at exact estimation, which generally is not the case). But also the respect to put value for the customer first, which is more likely to succeed if there is not big design up front planning. 

You could use a cone of uncertainty with a large uncertainty margin. An answer like "somewhere between sprint 8 and sprint 17" is still better than "i have no idea".