The question is... a bit like asking what's the best length for a piece of rope.
What are the variables that you are including in your analysis? What data do you have available? How is your work history data structured?
If you are only forecasting the total cost of the next sprint based on the overall cost of the prior sprints, for the whole package of work, then you can probably put that into splunk and get a useful answer.
If you are trying to get closer granularity than that, then you are going to need to figure out how to structure your data, and you are risking violation of the major philosophies of the agile methodology. (Non-agile-savvy managers generally hunger to do that.)
Let us know what data you have, and what you are trying to get out of it, and then we can suggest something more specific.
ON THE OTHER HAND...
Typical scrum/agile/lean project management doesn't collect estimates or assurances in advance of which people will work on which user stories, they just do ballpark/breadbox estimates of the overall LOE of the user stories, and the team learns to improve their estimation over time, as personnel change and experience accrues. Which means (on a backwards-looking basis) taht you might not even HAVE the metrics you'd need to get more granular.
So, the general answer is usually, "the entire team will work X hours a week for the Y weeks of the sprint and bill it all to the user stories they accept into that future sprint."
And, on a forward-looking basis, if you start using the estimates and past results as a metric for anything other than understanding how much total work to put into the next sprint, then you are risking a corruption of the estimation process, and will get less accuracy of estimates and less total work output as a result.
"Captain, I need four hours to fix her or she'll blew up."
"Scotty, I need it in ten minutes or we'll miss happy hour and
the Klingons will drink up all the scotch."
"Then I'll have it for you in five."
