This is more a theory and correctness of the process more than practical. I am curious to know if the Scrum Master will have to answer the three questions below in the stand up meeting.
I would think from the point of view "the scrum master is a part of the scrum team" the answer would be yes.
IMO, this depends a bit on if the scrum master has other roles that make this worthwhile in answering or not. Just to give an example of each case:
Where it isn't worth answering: If the scrum master is working on other projects and has nothing to report, is it worth stating that there isn't anything new to report over and over? I'm inclined to think no. An example here could be if the scrum master is a manager or team lead with other duties that are taking priority.
Where it is worth answering: If the scrum master is working on the project and moving things forward, then it is a different story and worth answering. Granted this may be a more normal case, I don't think it is always going to be the case.
Yes. It's useful for everyone on an Agile team to know what others are doing, both because they often can provide helpful suggestions, and so they don't end up re-doing work someone else is doing.
Also, there's morale value for developers and testers to know that a scrum master is not just "overhead" but is actually doing work too! :-)
The scrum master should use their judgement about how much detail to share-- in general, keep it short and relevant to the team, not just talking about project management details that most folks won't care much about.
I've worked in situations where they did, and worked in situations where they didn't. Situations where they didn't had a lot to do with them being Scrum Master for a bunch of Scrum teams, and so their work was generally disjoint from the work of the team. That said, I think even in those situations, it is useful to hear from them. Generally, I think situations where the Scrum Master reports are better, because there isn't the implied sense of superiority that nonreporting brings.
Do what makes sense. The process is there to give you structure, but no process is a Golden Hammer.
In an "ideal Scrum situation" the Scrum Master would not be responsible for any tasks committed in the sprint, if they were, on occasion there would be a conflict of interest between them needing to complete their task and needing to remove an impediment that a team member has reported.
The Scrum Master should be a faciliator not a manager and during the Daily Scrum team members should report to each other not to the Scrum Master.
The Daily Scrum should be seen as an opportunity for team members to synchronise their work.
So in the ideal situation I would say no, the scrum master wouldnt be answering the standard 3 questions.
I did the Scrum Master course last week (so obviously now I'm an expert!!) we went through the situations of holding multiple Scrum roles and the possible conflicts that could arise.
It was suggested by a number of people that it is ok to be 'coding' on the team and also the Scrum Master. This was a role they were currently fulfilling (although this was not something our Scrum coach necessarily agreed with). If this was the case then they would be answering the 3 questions as a team member, not as the Scrum Master.
One of the main roles of the Scrum Master is to remove obstacles reported to them by the team at the Daily Scrum, it was suggested on the course that the resolution (or what is being done) to these obstacles should be communicated to the team as soon as possible, it shouldnt wait until the next Daily Scrum.
While the Scrum Master role isn't part of the Scrum team (the Scrum Master role doesn't commit to work on the sprint backlog), it can be helpful for the Scrum Master and the Product Owner to answer the Three Questions at the end of the standup.
As a Scrum Master, I report on team-related items, e.g., impediments I'm working on, work with team members or the Product Owner on backlog grooming, etc. By modeling accountability (the team can judge me by whether or not I'm making progress on my work items), I encourage the team to be accountable for their work items. Similarly, the Product Owner should report on his team-related work items as well (backlog grooming, work breakdown of epics into user stories for upcoming sprints, resolving ambiguities with user stories in the current sprint, working with SMEs to help the team, etc.). Again, if I as a Scrum Master do this, it makes it easier to get the Product Owner to do this, and again the team will judge both roles by their effectiveness and accountability.
Note that the daily standup is not a status-sharing meeting as much as it is a public declaration of accountability and an issue-airing meeting (ensuring impediments are noted if they weren't brought up outside of the meeting). We can get task status information from the sprint board. As each team member answers the Three Questions, they are reaffirming their commitment to the work and to their fellow team members. These sociological/cultural reasons are key to team cohesion and effectiveness, and the benefits cannot be obtained if the team replaces the daily standup's face-to-face communications with email notifications.