Initial time estimate of work

I was wondering how can we provide upfront initial time estimate of a project, assuming that a high level product backlog has been prepared. Consider that the client is interested in overall time it will take to build the entire thing, while being open to incremental shippable deliveries.

@Ghulam Rasool, Good question. The short answer is you can't really provide an upfront estimate/completion date without any empirical data especially in a complex product development environment. It is interesting how the client expects incremental deliveries yet asks for an overall time. Honestly, I don't think they are wrong in asking because thats how we may tend to react but it would be better if we could exhibit the scrum value of courage and position ourselves to inform the client that we can start the work,and as we gather data we can provide a forecast. That reminds me, can you with any level of confidence predict tomorrow's weather? 

What does Scrum say about it ?

Scrum doesn't say anything. It is not meant to be saying anything. It only says what you need to do, to get to "Done". How you get to "Done", that is your choice.

Is referring to historic records the only way? what if the organization do not have a similar work done before.

Historic records if relevant to the current situation may help or else it is all about empiricism i.e. the essence of Scrum. Inspect, Adapt, make transparent and repeat till you reach your desired outcomes.

Hope this helps.

I was wondering how can we provide upfront initial time estimate of a project, assuming that a high level product backlog has been prepared. Consider that the client is interested in overall time it will take to build the entire thing, while being open to incremental shippable deliveries.

@Ghulam Rasool, Good question. The short answer is you can't really provide an upfront estimate/completion date without any empirical data especially in a complex product development environment. It is interesting how the client expects incremental deliveries yet asks for an overall time. Honestly, I don't think they are wrong in asking because thats how we may tend to react but it would be better if we could exhibit the scrum value of courage and position ourselves to inform the client that we can start the work,and as we gather data we can provide a forecast. That reminds me, can you with any level of confidence predict tomorrow's weather? 

What does Scrum say about it ?

Scrum doesn't say anything. It is not meant to be saying anything. It only says what you need to do, to get to "Done". How you get to "Done", that is your choice.

Is referring to historic records the only way? what if the organization do not have a similar work done before.

Historic records if relevant to the current situation may help or else it is all about empiricism i.e. the essence of Scrum. Inspect, Adapt, make transparent and repeat till you reach your desired outcomes.

Hope this helps.

Consider that the client is interested in overall time it will take to build the entire thing, while being open to incremental shippable deliveries. What does Scrum say about it ?

Does the client believe that more is known about the product than is unknown?

I've discussed the cone of uncertainty with clients before but the fact of the matter is that most organizations have traditional management practices in place and will ask for timelines. If that is the case here, get the team (developers, solutions architects, Product Owner, Service Delivery, etc.) in a room and whiteboard the vision of the Product and its essential features. For instance, Google is a very large company with everything from a search engine to autonomous vehicles. But without Google search and advertising revenue from placement, there is no Google. So if you have to deliver a long-term timeline, you can work with the team to forecast a roadmap for the essential features and give a timeline for v1.0.

Steve, Ian, Mark.. Thank you all for your kind responses. 

@Ian The client knows that most of the things are unknown, but at a higher level they know what they want to achieve. They are looking for cost and time estimates based on the known things.

So as far as I understand essentially we can provide the estimates based on the feedback of the Development Team about best-known and most important features, start the work and provide better estimates as and when we learn more while delivering releasable increments. 

They are looking for cost and time estimates based on the known things.

That’s great. Once throughput and velocity become known, the Product Owner might be in a position to provide the estimates they are looking for, with evidence to back it up.

In the mean time, it could be a good idea to focus on maximizing the value to be derived from the first Sprint by collaborating closely with the Product Owner. Remember that in Scrum there might not necessarily be any further Sprints at all.

@ian 

Thanks a lot for your input. It is quite clear.