When the sprint starts, you give it a day or two and then you start monitoring it. It’s basically observing and aligning the team, their work, and their progress with each task they do.
You can monitor Per Assignee or Per Priority Level in descending order.

For instance, for developers who require more of your attention, it might be best to start with their tasks first.
This way you’ll see what they are struggling with, and how to guide them with more focus.
Eventually, you’ll release them and let them swim on their own in the deep water.

Blocker or Critical issues – you’ll need to handle them right away – I advise you to monitor them from day one. However, you don’t want to create an unhealthy stress situation instead of resolving the issue as fast as possible.

Step 1: Time Estimation vs. Spent Time

Each task has its Estimation and its Spent Time.
Monitor twice or more:

• When the spent time has reached half of the estimated time.
  
• When the spent time has reached almost to its end.
  
• After passing the estimated time and the overtime that the developer gave you when you last monitored him.

When reaching out to the developer, use the following questions:

• “How is the task going – Is it going as expected or are there any setbacks?”
  
• “Will the task end as we estimated?” – If not, check if it justifies the newly added time.
  
• “Are there any cases that we didn’t take into consideration?”

They might answer that everything is fine, for instance, avoid telling you about a problematic issue, which is okay. Moreover, sometimes it’s better to advise with other team members or even with you.
Pay attention – this might be the cause for setbacks, misunderstanding the task, or getting out of focus.

Don’t get cold feet asking about their struggling issues, it’s good to hear the technical explanation. Above all, you might help bring the developer to see other aspects that he might not have considered.

Step 2: Questions & Comments

From day one, always take a sprint glimpse. You should review the task’s comment section, and look for questions and other issues that the team is discussing there:

• Recognize which questions should get higher priority from the others.
  
• Know which question can get a short & quick answer vs. the ones you should discuss in person.
  
• If there’s a dialog between the team and the QA – read it. Moreover, it can be an indication of how the team/QA understood the task itself. Also, it might raise new test cases or new end cases that the team will be handling as well.
  
• Design your answers to be calm and detailed when needed (bullets, or space between lines).
  
• Lower-priority questions can wait for the next round of monitoring – you don’t have to handle everything right away. Less stress will make you think more clearly.