Resource planning in Agile projects

However, one might still need to micro-manage this - wrong !

Below are few suggestions that would work in your case

1. My team members used to mail me (following the conventional command and control mindset) about their planned or unplanned absence. I brought this up right after the next day scrum (we call it parking lot, to bring up some immediate suggestions or concerns without waiting until the next retrospective) and explained how it is more important for the team to let each other know of their availability rather than create a bottleneck by updating a single individual. Imagine what the topic was for our next lunch and learn session :P
2. I didn't have to do much after the sessions we did about on how to self organize using the tools at hand. The team spent part of the next retrospective meeting to figure out the best way to radiate this information to the rest of the team and agreed to post all planned ansense on a team calendar.
3. It took couple of panic modes when the person with particular skill is not available and the whole team rallied to figure out the workaround and within the next retrospective we decided to proactively share and ask for any related KT when a person is absent. 
4. Now we have a whole library of videos that we record on a regular basis for KT sessions that we have about most common remedies that we engage in our support model so even when the person is absent, any one from the rest of the team an handle this activity.

However, one might still need to micro-manage this based on individual team members as people will have vacation days and/or particular members are sometimes required for specific tasks because of their experience etc. (though this is not desired in a Scrum team, it happens).  

Why do you think these are issues which a self-organizing team would be unable to plan for, navigate, and solve?

>> However, one might still need to micro-manage this based on individual team members as people will have vacation days and/or particular members are sometimes required for specific tasks because of their experience etc. (though this is not desired in a Scrum team, it happens).  

The reason we decide to use Scrum in the first place is because of complexity, and we know that it is extremely hard to predict the future.  Requirements may be unknown, technology may have risks, and people take vacations, they leave, etc.  If you think you can micro-manage all this, then you are falling back into the old waterfall habits of a project manager.

>> Should a Scrum Master help the organization deal with this or is this a totally wrong traditional approach?

The Scrum Master should help and teach the organization and Product Owner understand planning and how it relates to empiricism.  Nothing is for certain about the future.  While we can make some decisions based on past performance, stuff happens.  That's why we use the term forecast, not guarantee..

Thank you all!

I agree with all 3 fellows but I like Uma-Venkata  response. Being a jack of all trades I spend a lot of time up front with new teams talking about "capacity planning" and self organizing teams. When teams are new to Agile\Scrum they don't buy into this right away since they are used to a dev manager telling them what to do. It takes a while. Sounds like a training opportunity. 

In the past, I have been a resource manager (200+ people) and have also had positions leading the implementation of Agile in an enterprise-wide context. Based on my experience, if you are a Scrum Master, do the following:

(1) Let your Development Team(s) self-organize their vacations and if there are unplanned sicknesses/absences, let them adjust and manage their capacity for the Sprints. Theoretically, Development Teams have to be self-organizing. They should inform you of their capacity during and in between Sprint Planning when needed.

(2) If the Development Team(s) face an impediment that they can't solve themselves, the Scrum Master should step in and find a way to remove this impediment. For instance, if a Development Team Member decides to leave the company and leave the entire Scrum Team short-handed in the current and subsequent sprints, then it may be time to collaborate with Resource Management to shuffle resources within the company or collaborate with HR to start the hiring pipeline for possible candidates.