Your management team needs to be educated on how Scrum works, and to modify its key performance indicators to be outcome-based rather than effort-based. Its current approach to metrics is not only an agile anti-pattern, but is actively harming the Scrum Team's adoption of the framework.
Analysis and Recommendations
Problems with Planned Work
What about a Scrum Team that agrees to start a new Sprint with 20 tickets...but right after starting the Sprint the team learns that one ticket is infeasible...during the current Sprint.
There are at least three key problems here:
The Scrum Team commits to a Sprint Goal, not to completing a bunch of (potentially unrelated) tickets.
CodeGnome's Scrum Tautology℠ says:
Always remember that the goal of a Sprint isn't to complete lots of backlog items. The goal of a Sprint is to deliver the Sprint Goal.
The Scrum Team can adjust the scope of the Sprint with the cooperation of the Product Owner, but only if it doesn't jeopardize the Sprint Goal.
If removing the item from the Sprint Backlog would make the Sprint Goal obsolete or incomplete per the Definition of Done, then it can't be removed without a return to Sprint Planning.
If the Developers have a Sprint Backlog item that isn't essential to the Sprint Goal or the Developers' plan for delivering it, then it doesn't belong in the Sprint in the first place.
The Scrum Guide requires that the work selected from the Product Backlog form a singular, cohesive goal for the increment the Scrum Team will deliver by the end of the Sprint. While it's natural to have architectural runway, chores, in-Sprint bugs, or other items crop up during a Sprint and end up on the Sprint Backlog, the Developers should not be committing to work that isn't related to the Sprint Goal or necessary to deliver the planned Increment.
Problems with What's Being Committed, and to Whom
The team announces it to stakeholders and everyone is happy[.]
While Scrum values transparency, the Scrum Team is a self-managing unit. The Product Owner should certainly be communicating with stakeholders about the Product Increment being worked on, and the Sprint Goal and perhaps even the Sprint Backlog should be artifacts available for anyone interested in viewing (but not kibitzing about) them, but there is nothing in the Scrum Guide that requires the Developers to commit to specific Product Backlog items, and definitely not to commit to non-Developers about specific Sprint Backlog items.
In fact, committing outside the Developers to Sprint Backlog items is such a huge anti-pattern that I would urge the team to stop doing it right now. The Sprint Backlog is the Developers' plan to meet the Sprint Goal. The artifact's contents are entirely up to the Developers, and they can change the contents of the Sprint Backlog as they see fit at any time.
What you're describing is like an outgrowth of both per-person performance tracking, as well as an expression of the 100% utilization fallacy. Since the goal of Sprint is to meet the Sprint Goal, it doesn't matter whether the Developers have one ticket, a hundred tickets, or don't use tickets at all. The only correct measure of a Sprint is whether or not the Sprint Goal was met within the agreed-upon Definition of Done.
In other words, the Scrum Team should measure outcomes, not ticket volumes or the contents of Scrum artifacts. Ultimately, management needs to measure the same thing: an outcome. That usually means asking "Did the team deliver the potentially-shippable increment it planned, or not?" It's very binary: it's true or false, yes or no.
Problems with Non-Agile Metrics
While the Scrum Team is clearly still learning the framework, your leadership team doesn't seem to think there's anything new or different that they need to do to lead an agile organization. This is a prima facie fallacy.
As a purely pragmatic matter, most organizations adopt Scrum without doing any education at the middle-management or executive levels. This often leads to new Scrum Teams like yours trying to implement a new process while their leadership is still "holding them accountable" in very non-agile ways.
At a bare minimum, the Product Owner and Scrum Master need to work with stakeholders and the leadership team to explain:
How Scrum works.
The appropriate inspect-and-adapt inflection points for management review and input.
The need to adopt a whole-team approach to measuring outcomes, rather than trying to measure individual productivity.
Tools must support a process; they should never drive them.
In this case, management is forcing the Scrum Team to build processes around legacy ticketing metrics rather than defining new and better metrics or better processes, and then finding or modifying the tools used to measure or support them. Unaddressed, this will lead to failure. Your mileage in this case will not vary.
You get what you measure.
If management wants to use completed tickets as a primary metric, then the Scrum Team will inevitably turn each work item into 120 tickets. One goal of frameworks like Scrum is to create a predictable delivery cadence, not an ever-increasing one. By focusing on ticket volume instead of outcomes, you will get ticket volumes and not necessarily useful outcomes. Q.E.D.
Core Recommendations: Education and Communication
The Scrum Team needs to do a better job of educating the leadership team about how Scrum functions, and communicate more effectively with them. Collaboration between the Scrum Team and the rest of the organization is fundamental to success, both for the team and for the company. If neither the Scrum Master nor the Product Owner is sufficiently experienced with Scrum to improve the communications outside the team, then requesting an agile coach to help the company adopt Scrum more effectively may be a good solution.
If no one is willing or able to fix this underlying dynamic, then it's probably time for the Scrum Team members to brush up their resumes. Without effective collaboration with stakeholders and leadership, the project will fail, the Scrum Team will get blamed, and the executive team will reward each other with bonuses and stock options after firing all the people doing the actual hands-on work. This is more or less what they teach in business school, so expecting a different outcome without changing the underlying parameters is basically just wishing the problem into the cornfield.
Other Related Answers