Scrum Master being asked to carry out Team's effort & capacity estimation

...he told me that efforts need to be tracked because vendor team-members contractual billing gets calculated based upon that. For the internal employees, their efforts should match the hours they book in the company timesheet & any significant deviations need to be looked into.

This makes sense.

For the vendor team members, this is the reality of the agreements between the organizations. Although there may be better ways (at least in theory) to structure those arrangements, this is something that is difficult to change since it requires two organizations to rethink how they reach agreements and contracts.

For the internal team members, I've seen this in two cases. One is when the company is a contractor, similar to your vendor, and the contract is a time-and-materials or cost-plus contract. The other is when an organization can capitalize some expenses.

However, the Sponsor has recently asked me to start estimating the effort spent by the team members and to do their capacity estimation as well. Before starting with a Sprint, he wants me to estimate the Capacity of the Team (total hours availability minus the planned leaves & holidays). The capacity needs to be calculated member-wise.

However, this part doesn't make much sense.

Regardless of the reasons why you need to track the time, why do you need to estimate the effort? It would be more robust to track actual values. Tracking the actual time spent on work would not put the team in a situation where estimates are being mandated, but an outside entity is also setting the estimation methods. The team's flexibility to define their way of working would be increased.

Estimating the team's (or individual's) capacity going into the Sprint also doesn't affect tracking the actual time spent on specific types of work. However, this is a relatively easy thing to do. Working days are typically fixed and people know time in advance. I've worked with teams that estimated time, calculated available time, and checked their Sprint Goal and proposed Sprint Backlog against the forecast available working time to ensure it's reasonable. Although I prefer avoiding estimates entirely, this isn't a terrible way to plan.

Then, during the Sprint Planning, he expects us to create sub-tasks under each of the User Stories and plan the estimated effort to be taken against those. When members start working on those sub-tasks, they need to put the actual effort in terms of hours & minutes spent. The sub-tasks, themselves, should be created for the different stages, like one for development, one for testing, one for deployment etc.

This makes sense, especially since some types of development work may be capital expenditures while others are operational expenditures. The concern that I have here, though, is the excessive focus on up-front decomposition and estimation rather than tracking actual time. It would be preferable to cearly define what types of work can be capitalized and what type of work cannot be and allow the teams to track actuals with the appropriate level of granularity as they are doing the work.

I need guidance on how to convince the Sponsor in a logical way to make him see how useless these things are & would distract the Team from creating value. Also, how do I convince him that this is not a Scrum Master's job to do. We do not have Project managers for these Teams, so naturally these things come on to the Scrum Masters. And, if, eventually, this needs to be done, how do I get this done so that the team members doesn't end up losing their focus while taking care of these administrative activities? Kindly suggest.

These things aren't useless. The information is essential to executing the agreements between the organizations and as input into accounting processes. You probably can't convince anyone that the information isn't needed. You can highlight the fact that this overhead will take time away from value-added activities. You should look to find ways to push this work down to the individuals on the team. Instead of you, as the Scrum Master, taking on additional responsibilities, you can help the team find ways to provide the information needed in the least impactful way, reducing waste and maximizing value delivery.

if, eventually, this needs to be done, how do I get this done so that the team members doesn't end up losing their focus while taking care of these administrative activities? Kindly suggest.

Since it will cause them to lose focus, you will just have to make sure that these beans are also counted.

All of the administrative activities will therefore additionally have to be tracked for each team member, plus a further task for time lost due to context switching when completing any and all of them. To stop your own heads from blowing up, you might consider charging a standard rate according to Gerry Weinberg's context switching ratios:

Weinberg's Task Switching Ratios
One Task: 100% productive time.
Two Tasks: 40% productive time each, 20% lost to context switching.
Three Tasks: 20% productive time each, 40% lost to context switching.
Five Tasks: Up to 75-80% lost, with only 20% productive time per task. 

Offer this helpfully as a proposal, then wonder whether or not there might be simpler and cheaper options. A good Scrum Master is good at wondering.

Thank you @Thomas Owens for your response! Your points are all valid, but it gets a bit more complicated here than what I elucidated in my original question. The Sponsor and the Leadership are still very interested in using Story Points as the basis for measuring how many Story Points the Team has delivered as compared to the estimated capacity (put in both Total Hours as well as Story Points).

Although Story Points are not mentioned anywhere in the Scrum Guide, I generally like the approach of relative estimation as it quickens the estimated capacity of the Team and to plan Sprints as per that. However, I seem to have inherited an awkward system wherein management asks to use both Story Points (at User Story level) & Hours/ Mins at Sub-tasks level. They previously had the odd notion of equating relative with absolute estimation (1 Story Point = 6 Hours). I worked with the Team to get their Velocity history (in SPs) and equated that with their historical capacity to come to a more realistic correlation (although it still doesn't make much sense, since we're still comparing absolute with relative, but this is the set practice). I am against this whole notion of doing estimation on two different ways (absolute & relative). To me, relative comes much naturally, but then it cannot be used in project budgeting & all, so I'm really perplexed here how to proceed.

I also didn't get your point of only tracking the actuals. We usually track both estimate & the actuals to compare how much is the actual versus the initial estimate. It is the basis of making the hours more realistic going ahead in the vendor contracts. So, both needs to be tracked - effort estimate versus the actual efforts spent.

Thank you Ian Mitchell for your response!

The context switching ratios from Gerry Weinberg is really very interesting and although I know that we lose productivity due to the context switching, but was never able to see its effect so specifically in terms of numbers & percentage. 

In most of the Organizations that I have worked for, I generally see a tendency of measuring team's productivity rather than measure the outcome of what they deliver. Teams can deliver in half-time and still be very valuable with respect to the Product specs & at times not been able to deliver the requisite value in working full-time for the whole duration of the Sprint. This is why I am looking for some narrative to build around this so that I can make my Leadership & Sponsors aware of the fact that they're stressing upon measuring the not so important thing (delivery productivity) while ignoring the crucial thing to measure (delivery outcome).

I believe your sponsor has mixed two different aspects: billing tracking requirements and Scrum planning.

I hope I am not oversimplifuing the problem, but as I see it if vendor contracts require timesheets, that can be done. However, it should not be mixed in with the team planning. Developers can record their hours separately (just like normal timesheet requirements), and the team continue with their sprint planning as per the Scrum Guide.

A suggestion is to approach the sponsor and explain to separate the two issues of time tracking and team planning.

Scrum: (as you described, and would like to implement)
Allow Developers to forecast their own capacity on past velocity indicators and team judgement, not hour-by-hour task estimation. PBIs should not be broken into some defined subtasks just for time tracking effort, but broken down for what makes sence for the team. 

A compromise is:

Keep Scrum planning as is, the team forecasts based on their experience and Sprint Goal.
Let team members track hours independently for billing or HR needs.
Do not tie those hours to the Sprint Planning, story estimates, or velocity.

This can give the sponsor’s billing time tracking without damaging Scrum or turning the Scrum Master into a task assigning project manager.

On the question on how to convince the Sponsor, some thoughts. Assigning capacity for the team and tracking hours in Sprint Planning undermines self-management / empowerment, which is a core Scrum principle, and will errode team motivation. It shifts decision-making away from the Developers, reducing ownership, and accountability, with a like reduction in engagement. It also harms predictability, because teams begin overcommitting, inflating estimates, or hiding problems to match imposed numbers. Finally, it locks the Scrum Master's time down in this administrative work, and distracting the team from value-creating work.

The Sponsor and the Leadership are still very interested in using Story Points as the basis for measuring how many Story Points the Team has delivered as compared to the estimated capacity (put in both Total Hours as well as Story Points).

The sponsors and leaders shouldn't care about the estimates, much less about story points.

Consider that a team estimates before doing the work. Although they may have spent time doing analysis, or some people on the team may have done similar work in the past, it's generally accepted that there's always going to be uncertainty in an estimate. This uncertainty could go both ways. Sometimes, the team will discover additional work needed to move the Product Backlog Item to Done. However, the team could also discover a more straightforward solution that meets the needs in less time and effort. Once the team is done, they will be able to tell you how many hours they spent on the work, including different aspects of it. At this point, what value is the estimate?

Estimates very quickly lose their value after planning. Once a team has planned their work, the value of using that estimate for anything else quickly drops to valueless. Once work begins, the only value would be work item aging and the actual time spent. Even work item aging loses value once the work is Done.

Goodhart's Law is relevant here. If the sponsors and leaders want to measure how many story points the team is delivering, then the team can very easily inflate their estimates. Something that is 1 story point now becomes 3, 3 becomes 5, 5 becomes 8, and so on. Even if the team estimates in hours, they can become more conservative and introduce more room for error, or inflate their estimates. When I work with teams that choose to estimate, I encourage them to avoid sharing their estimates outside the team to ensure the estimates can't become targets, and the team can make the best possible use of the estimating process.

Although Story Points are not mentioned anywhere in the Scrum Guide, I generally like the approach of relative estimation as it quickens the estimated capacity of the Team and to plan Sprints as per that.

Story points add unnecessary overhead to the process.

There's a lot of historical baggage with story points. I'd recommend reading Ron Jeffries' post on the creation of story points. Originally, story points were an ideal time estimate multiplied by a load factor that accounted for overhead and context switching within the organization to get a rough approximation of the actual time work would take. The team initially talked about "days", which was confusing to some stakeholders. A lot of problems could have been avoided by simply talking about "ideal days" versus "real days" or "actual days". In my experience, at least in the 2010s and 2020s, this concept is well understood by many business stakeholders. The idea of relative estimation, effort, and complexity was introduced much later.

Unlike hours, people don't know what a "story point" is. When the team changes, you need to invest time in (re)teaching people what "1 story point" means. From time to time, you may also need to set time aside to recalibrate what "1 story point" means as your anchor. Doing this takes time away from other, more valuable work, like delivering work from the Sprint Backlog or refining the Product Backlog.

However, I seem to have inherited an awkward system wherein management asks to use both Story Points (at User Story level) & Hours/ Mins at Sub-tasks level. They previously had the odd notion of equating relative with absolute estimation (1 Story Point = 6 Hours). I worked with the Team to get their Velocity history (in SPs) and equated that with their historical capacity to come to a more realistic correlation (although it still doesn't make much sense, since we're still comparing absolute with relative, but this is the set practice). I am against this whole notion of doing estimation on two different ways (absolute & relative). To me, relative comes much naturally, but then it cannot be used in project budgeting & all, so I'm really perplexed here how to proceed.

This would be solved by my points above.

Management only needs the actual time spent, whether that's to compare the time and cost against perceived value or to capitalize expenses. Getting management out of the estimation practices would go a long way.

Estimates aren't needed for budgeting. The best way to budget for an agile team is to take the team's cost per Sprint (or a few Sprints, such as a month or quarter's worth of Sprints). That is the most you'll spend on people's salaries. Tool costs are much more stable. The biggest variable may be infrastructure costs, but that is affected by the architecture and implementation.

Moving from relative estimates to time-based estimates would also reduce waste. Going to a no-estimates approach and focusing on right-sizing work, tracking flow metrics, and forecasting with throughput and cycle time would require even less effort from the team.

I also didn't get your point of only tracking the actuals. We usually track both estimate & the actuals to compare how much is the actual versus the initial estimate. It is the basis of making the hours more realistic going ahead in the vendor contracts. So, both needs to be tracked - effort estimate versus the actual efforts spent.

There is no value in comparing actuals and estimates. The only purpose that could serve is to improve estimates, and of all the activities to improve, that would be the least valuable to downstream stakeholders. Tracking the actual time spent and finding ways to identify impediments and bottlenecks to improve throughput and optimize value delivery would be much more useful.