Scrum is based on an empirical control methodology. While not directly stated in the Scrum Guide, it essentially posits a roughly-constant run rate for each Sprint, allowing predictable budgeting through estimating the number of Sprints that are likely needed to reach a "good enough" target. (See Agile Release Planning for more on this.)
Generally, budgeting/billing should be based on the average cost of your Sprints (e.g. 7 people at 40 hours per week) rather than trying to get more granular. Scrum events are framework overhead, and billing them as separate line items isn't going to help anyone measure outcomes.
While your use case may be different, trying to bill framework process separately from hands-on development activities is a project smell. It strongly implies that management sees no value in planning, communication, or coordination, and will likely try to squeeze "overhead" to gain Pyrrhic cost efficiencies at the cost of essential inspect-and-adapt events. If they do that, they will likely break the process, and will get to keep both halves.
A Deeper Dive
I was asked by Executives to also track all Scrum ceremonies in JIRA.
You don't define your role in your original post, but I'm going to assume "Scrum Master." Regardless, this is a teachable moment for you, the Scrum Team, and the rest of the organization. Maybe even the customer, too!
It's a good bet that this is an X/Y problem. A good way to uncover the real underlying issue is to use the Five Why's technique. Consider this example chain of questions:
- Why do you want time spent on Scrum events tracked in JIRA?
- Why is it useful to track time spent on essential framework activities separately from other activities?
- Why would management or the customer need to distinguish between different types of activities required by our internal processes?
- Why would this information improve the development or delivery process?
- Why would this information feed outcome-based KPIs and metrics?
This chain (or one quite like it that better fits your use case, and dynamically adjusts to the answers provided) will probably result in one or more root-cause statements indicating:
- Lack of trust in the team or the agile development process.
- Magical thinking, such as the 100% utilization fallacy.
- Organizational failure to buy into the values, principles, and objectives of an incremental or iterative process.
- A desire to use Buzzword Management™ to claim agility without actually committing to the framework.
- A management style that seeks a "go faster" button without a willingness to pay the costs in process and culture change.
Scrum is not a magical go-faster button. It's a framework that uses empirical planning to create a sustainable process with a predictable cadence. It can increase efficiency, but in this case efficiency means "doing more of the right things and building more of what matters" rather than simply accelerating the pace by getting rid of all that pesky project overhead.
Uncover the real intent of this management objective. If it makes sense, involve the team in determining how best to track it. If it's an exercise in futility, educate the management team (and possibly the client) on how Scrum really works and what levers the empirical control process provides them to manage costs, schedule, quality, and change.