In Scrum, who does a high level estimation scenario to give to the client?

Well, the main thing in an agile context is that the people who do the work are the only people who should be involved in estimating it. What I’d add to that is that
– guesses are not estimates
– estimates are not forecasts
– forecasts are not promises
The second key thing is just how you go about creating the work for the product backlog. My counsel would be to use the User Story Mapping approach that Jeff Patton describes in his book, on his website, and so on. In this
– you co-create with the customer what they want
– you split it into a “spine” (look up “walking skeleton”) and subsequent releases
– you size the work as a group, with the customer involved
The key thing about that sizing is that you uncover different perspectives and unknowns; these drive “research spikes” that help you refine the work, while negotiating with the customer. In that way the process is co-creation, rather than a transactional approach.
The second key thing is to avoid adding too much detail too soon. You need to do that for the most important thing (the “spine”) but not things that are further off. By the time you get to those, you and the customer will know more. Maybe they will change?
I tend to get the team to estimate those things in Sprints, using Fibonacci and asking them for a range they are 85% confident in. We’ll also surface a lot of unknowns there, and identify potential research spikes or things the customer needs to think about before we get there.
So now you have :
– micro-scale estimates in points for the first thing you need
– meso-scale estimates in a range of sprints for the next priority items
You can turn that into a forecast in a few ways; summing the midpoints of the ranges is the worst. Including the range as a variable is better(*). Monte Carlo modelling is better still.
if you ignore the worst way (just summing the midpoints) that gets you to a range of dates, in a cone of uncertainty. But remember those assumptions? They go along with the forecast.
Then I reforecast often; as we complete a big item we’ll user story map in detail the next one.
As we uncover new information, we’ll revisit the meso-scale forecasts.
As we discover more about the team throughput, we’ll adapt again.
Mostly that gets us to a point where we can collaborate on decision making with customer in a useful way.
(* this requires a bit of stats knowledge, but what I do is
– make a table of the items in excel
– put in the low and high estimate ranges in columns
– calculate the midpoint in a new column
– calculate the error bar (midpoint – low estimate)
– assume the error bar approximates the standard deviation
(remember that 85% confidence limit)
– create a column with the standard error (standard deviation squared)
– create a column that is the cumulative sum of the midpoints (M)
– create a column that is the cumulative sum of the standard errors
– create a column that is the square root of that cumulative sum of standard errors (S)
– create a column that is M-S; call this 16% chance of delivering, the early forecast in Sprints
– create a column that is M+S; call this 84% chance of delivering, the late forecast in Sprints
– convert Sprints to Dates with a look-up table.
If you want 5% – 95% confidence, then use M-2S and M+2S instead
Now that’s a pretty crude model, but it is capturing the team’s uncertainty in a realistic way.
As you uncover more, so you can refine the model.
Where there’s too much uncertainty, you know where to do research spikes to clarify.