Create templates to quickly answer FAQs or store snippets for re-use.
Communication is key, somehow you have to make them understand that 5 days of meetings in 15 days of actual working time is insanity. Good luck :-D
Also, communication like this is best accomplished "in peace time" IMO, like, not when stress is high across the team.
It's also good to phrase it in positive terms about how much more you can accomplish on days where you get a lot of heads down time.
This is a good article on the subject, btw: paulgraham.com/makersschedule.html
Possibly irrelevant but maybe helpful in some situations: I'll add that in college I found we'd have group meetings that went on and on and on. I always made the point of letting people know when the meeting started what the next thing I had going on was. It was easier to get out on time when we have a known deadline.
I would only commit to a sprint goal that is doable in the net-working-time. So if the sprint has 15 days in total, minus 3 days of waste, I'd use 12 days as basis for the sprint-scope.
It also depends if the meetings are helping with getting the sprint done.
Issues like these are important to discuss in the retro, since they heavily depend on teams and stakeholders.
You should never ever work late, or show that this would be an option.
I agree with rhymes: communication is key. Get ahead of any issues by talking it through with your manager. Just lay out the facts, and focus on reaching an agreement as to what's expected from the sprint. Don't forget to account for travel time to/from meetings. It's not reasonable to simply swap out an hour of ticket time for an hour of meeting time, especially if the meetings have small gaps between them. It's really hard to make full use of a 30-minute break between meetings.
What concerns me more is that it sounds like your team is allocating blocks of calendar time to individual tickets, and then treating your expected coding output as a matter of simple math. "I have six tickets, each with a 4-hour estimate, so I should be finished with them by Wednesday evening. That leaves time for two days of meetings." It sounds like simple math, but in reality, it simply doesn't hold. (See Hofstadter's Law)
For example, let's say your journey home from work in the evening reliably takes about 20 minutes. (5 min. walk to the subway, 10 min. ride, 5 min. walk home.) If there are surprises on a given day, your journey might take 40 minutes, but there's no universe where it takes 10 minutes. "Typical" times tend to be closer to the lower bound than the upper.
If the team is run well, you should be able to meet your commitments reliably without working extra hours.
You can discuss that with your manager.. to find the best deal.. but still you must do it bro ^
Arrive to work late, use public transportation like trains, then do coding in trains. Get out of work early use public transportation, do some more coding on the train.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.