I am not quite sure what is your specific question (which agile process issues?). it is also quite possible that the problems you have are not connected to agile. If I got it right you want discuss the 3 points. So lets start with that.

1. team velocity vs. team size

Indeed these are not in correlation at all. As you mention, most if the time once you hire a new team member the velocity decreases. This can be from several reasons, some of them predictable (team needs to spend time explaining things to new member) some of them less predictable (new member has personality not fitting into the team). If you would like to increase team's productivity there are other ways which can be done and are considered important. A very good short video describing the key pillars can be found on [www.scruminc.com (open videos - Scrum Best practices)][1].

Since project is a complex system, when you change something the results can have significant consequences. So it is true what you write, once you change the team, the whole process of estimates and velocity can change.

2. Team estimates

During the sprint planning the team should have enough discussion in order to enable all people estimate. Do not forget that

• the team estimates relative size not absolute time. If for one member things a story is 5 times bigger then other story and the other things that they are the same, they need to discuss why.
• you cannot guarantee that the person most proficient in that technology will in the end work on that, team should be aware of that

For sure the new person we need more time, but he would need time for each feature. We estimate relative size. If the team decides to include analysis as a subtask, so be it, that is up to them. (I am trying to avoid that though, we usually discuss what needs to be done (sub-tasks) until everyone is comfortable to estimate.)

3. Scrum Master estimates

Well, if the scrum master is also part of the development team (I do not recommend that though), s/he should estimate. But not as some super-team member but as a regular member. If s/he does not agree on the estimates s/he can do it during the planning session as any other member. Once the estimates are done though, s/he should accept that as a team decision and thats it. From the position of the Scrum Master s/he has not right to say it the estimation is right or wrong. [1]: https://www.scruminc.com/scrumlab-open/

I am not quite sure what is your specific question (which agile process issues?). it is also quite possible that the problems you have are not connected to agile. If I got it right you want discuss the 3 points. So lets start with that.

1. team velocity vs. team size

Indeed these are not in correlation at all. As you mention, most if the time once you hire a new team member the velocity decreases. This can be from several reasons, some of them predictable (team needs to spend time explaining things to new member) some of them less predictable (new member has personality not fitting into the team). If you would like to increase team's productivity there are other ways which can be done and are considered important. A very good short video describing the key pillars can be found on www.scruminc.com (open videos - Scrum Best practices).

Since project is a complex system, when you change something the results can have significant consequences. So it is true what you write, once you change the team, the whole process of estimates and velocity can change.

2. Team estimates

During the sprint planning the team should have enough discussion in order to enable all people estimate. Do not forget that

• the team estimates relative size not absolute time. If for one member things a story is 5 times bigger then other story and the other things that they are the same, they need to discuss why.
• you cannot guarantee that the person most proficient in that technology will in the end work on that, team should be aware of that

For sure the new person we need more time, but he would need time for each feature. We estimate relative size. If the team decides to include analysis as a subtask, so be it, that is up to them. (I am trying to avoid that though, we usually discuss what needs to be done (sub-tasks) until everyone is comfortable to estimate.)

3. Scrum Master estimates

Well, if the scrum master is also part of the development team (I do not recommend that though), s/he should estimate. But not as some super-team member but as a regular member. If s/he does not agree on the estimates s/he can do it during the planning session as any other member. Once the estimates are done though, s/he should accept that as a team decision and thats it. From the position of the Scrum Master s/he has not right to say it the estimation is right or wrong.