Scrum Master and Burndown chart

I am sorry but i did not understand why the SM needs to track the burn down chart. Is the team not aware of their progress (via stand-up)? 

Also, the phrase "So that SM can be ahead of the game", what does that mean?

It seems a very prescriptive approach.

But if a Scrum Master is expected to monitor team metrics or performance, being able to effectively coach the team is one of the better reasons for doing so.

I would be more suspicious if the Scrum Master is expected to report performance to others, or manage the team based on such performance.

In such a situation, I might ask what insights the interviewer feels the Scrum Master would learn from the burndown chart, and discuss other suitable techniques to achieve this. For example, if the motivation is to get control of flow, it may be more effective to measure cycle time and review outliers, and to supplement that with monitoring and restricting the amount of simultaneous work in progress.

I was told by an interviewer so that SM can ahead of the game

...

What is the best way to handle such questions? 

Was it a question, or were you being "told" something by the interviewer which he or she was convinced of?

I'm not sure that I agree that it's not the Scrum Master's job to track team progress. The Scrum Master has several defined responsibilities that align with this - helping the Product Owner to understand product planning in an empirical environment, helping the Development Team create high-value products, and causing change that increases the productivity of the Scrum Team. As a coach, I would encourage a Scrum Master to work with the Scrum Team to figure out the best way to do this and to come to an agreement as to who's responsibility it is. I don't think that the team should rely on the Scrum Master for this, but I see no reason to say that it's not the Scrum Master's job if that's what the team agrees to.

In this situation, it's more important that the team determine how best to monitor their own progress and who ensures that the status is appropriately updated and made visible. Depending on the tooling used, there may be anything from little effort to extensive effort to monitor and track progress of the team. If the Scrum Master is dictating to the team (or the organization is dictating to the team) how to do work and who does it, that would be an agile anti-pattern.

@ Ian Mitchell  This was a statement followed by the question...Should this not be a SM responsibility? 

@Thomas Owens From your view point if the team and the SM agree that the SM track the progress this is a a favor that the SM will do for the team to prevent them from distraction. But from the interviewers point of view tracking daily progress of the Dev team should be a SM responsibility and that is where I was not in agreement. The whole point to monitor the progress is for the SM to step in immediately coach the team if Sprint is not progressing as planned. ans he should jump in to coach the team. 

This was a statement followed by the question...Should this not be a SM responsibility? 

Not really. It would not be correct to say: "The SM needs to track the burndown chart on a daily basis to monitor Dev Teams progress, so that he can be aware of how the team is performing and coach them accordingly."

Things to consider:

• Each Sprint progresses towards a Sprint Goal. Burn rates are just a lens through which progress might be inferred.
• In Scrum there doesn't have to be a burndown chart at all.
• A burndown chart is a questionable means of assessing team performance.
• The SM should be satisfied that the team are tracking progress, since they are responsible for inspecting and adapting their own plan of work.
• A good SM will have situational awareness. This is achieved by building transparency, not by monitoring.
• A daily assessment of progress may not be enough.

If I was in a situation where an interviewer made the above assertion, I would challenge it in terms such as these, probably by open questioning. Then again, I would be unlikely to get the job.

@Thomas Owens From your view point if the team and the SM agree that the SM track the progress this is a a favor that the SM will do for the team to prevent them from distraction. But from the interviewers point of view tracking daily progress of the Dev team should be a SM responsibility and that is where I was not in agreement. The whole point to monitor the progress is for the SM to step in immediately coach the team if Sprint is not progressing as planned. ans he should jump in to coach the team. 

I believe we're in agreement, yes.

Even if the Scrum Master begins taking on the job of tracking the progress, it could be temporary. Perhaps the responsibilities shift if the tooling is configured to provide the data that is needed with less effort, perhaps even automatically. Or perhaps the Scrum Master knows how to collect and analyze the data and teaches the team. I would strongly disagree with the interviewer that tracking progress is always a Scrum Master responsibility.

Regardless of who is tracking the progress, it should be visible. After all, one of the Scrum Values is transparency. If the Scrum Master observes trends or patterns, that may be useful to guide the coaching and facilitation efforts, depending on what, exactly, is observed.

If I was in a situation where an interviewer made the above assertion, I would challenge it in terms such as these, probably by open questioning. Then again, I would be unlikely to get the job

There's a lot to be said for this kind of interview technique. If open questioning is an impediment to being employed, it's probably not the right job for a Scrum Master.

The SM needs to track the burndown chart on a daily basis to monitor Dev Teams progress, so that he can be aware of how the team is performing and coach them accordingly

In addition to the previous comments, what jumped out at me with this "statement" is the potential fear of failure culture that exists in this organization.

A key attribute for a Scrum Master is being comfortable with allowing the rest of the Scrum Team to find their own way.   Sometimes, this involves allowing failure to happen, so that the Scrum Master can facilitate discussion around it and help the Scrum Team learn and grow.   

Asking a Scrum Master to "step in" whenever they see something occurring that is not ideal or may not be according to plan seems to relegate the SM role to an active manager of the team, which is an anti-pattern.

In addition, the active daily monitoring of team progress is reflective of a culture of mistrust.   What conditions exist in the organization that cause others to not believe the Development Team can meet their forecast, or communicate when they are slowed down or impeded from meeting their Sprint Goal?

I would also be unlikely to get the job, as my response would be asking "who does not trust the Development Team to meet their forecast / Sprint Goal, and why"?

The SM needs to track the burndown chart on a daily basis to monitor Dev Teams progress, so that he can be aware of how the team is performing and coach them accordingly

What stands out to me is not the tracking of the burndown part but the rest of the sentence instead...

Since the tool is configured to not require daily maintenance, the "monitor" aspect is performed by the Dev Team during Daily Scrum at the minimum. What good does tracking progress do the for Scrum Master separately? The SM is not there to act as a Project Manager and relay status of progress to anyone external of the Dev Team, and the PO should be looking at it as well. 

The subsequent Retrospective gives the Scrum Team the opportunity to improve how they work, so the coaching opportunity here is around helping them understand the "why" of their actions and decisions, while also support their decisions, needs, and desired change to become more self-organizing.

I feel the mentality behind that sentence is less about what I've described and more about ensuring any course correction is performed and influenced by the Scrum Master early and often, which I don't agree with.

Everyone above has said most of what I was thinking as I read through this.  But one thing jumped out at me in the discussion between @Uma Tirukonda and @Thomas Owens.  This is just my opinion but I have never shied away from giving my opinion before.  

The whole point to monitor the progress is for the SM to step in immediately coach the team if Sprint is not progressing as planned. ans he should jump in to coach the team. 

My concern is the part I emphasized. Remember that no one actually plans a Sprint. The Development Team will forecast the work at the beginning and then adjust it as the work is undertaken.  It is up to the Development Team to determine if they are in danger of meeting the Sprint Goal and raise the issues for visibility.  It is also up to them to decide how to adapt in order to overcome any problems.  Remember this statement from the Scrum Guide section describing the Development Team

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

The Scrum Master is expected to facilitate the removal of impediments and suggest techniques but ultimately it is up to the Development Team to do all of the work. 

If I had been faced with this question during an interview I would have responded with a multitude of questions where they would have to justify to me why this behavior is needed.  Then my answer would be related to how a Scrum Master can help facilitate communications between the Scrum Team and external entities so that trust is built and the need to monitor is removed.  And yeah, like @Ian Mitchell, I would most likely still be looking for a job. 

I compiled the Pros and Cons of SM tracking/measuring burndown chart based on this thread:

CONS:

• potential fear of failure culture
• not allowing the rest of the Scrum Team to find their own way
• always asking the SM to step in for team problems is an anti-pattern
• culture of mistrust

PROS:

• SM can help facilitate empirical planning
• Being able to effectively coach the team
• SM would be measurement liaison to management help shielding the team
• Process improvement in Retro could be stronger based on empirical numbers 

I shared this with my other SM's in the office and it's official: we all have different brands of Scrum. 

There is nothing that says a Scrum Master does this. There is also nothing that says a Scrum Master does not do this. Whoever is interviewing you is neither correct or incorrect, they simply have their experience and the culture / structure of the organization they work within. Perhaps it is the current status quo and is open for adaptation.

As a Scrum Master, I am happy to take this on for the Development Team if we decide as a team through self-organization to do it this. Perhaps I would be helping the Development Team to create high-value in the product if they do not need to do this themselves.

Scrum Master Service to the Development Team

The Scrum Master serves the Development Team in several ways, including:

• Coaching the Development Team in self-organization and cross-functionality;
• Helping the Development Team to create high-value products;
• Removing impediments to the Development Team’s progress;
• Facilitating Scrum events as requested or needed; and,
• Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.