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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.