Capacity planning

Well velocity is the average number of points DONE over the last 3 Sprints. So if the team completed 30, 35, & 25 points over the last 3 sprints, the target velocity for the next sprint should be 30 points to forecast.

I need to determine per person story points every day so that we can then come out with a collective number.

Um, why do you think it's beneficial or wise to determine the points per person when Scrum is all about working as a TEAM, not individuals?

Lastly, the title of this asks for Capacity planning yet you focus on velocity throughout your post, so I'm a little confused.... 

Capacity is just a simple calculation of the number of available hours for the team for the next sprint. Remember to account for vacation or holidays. Also, don't overplan! You've got 10 working days at 8 hours per day and 5.5 team members (how you have a half person is another question haha) so that comes out to 440 hours. You must consider the unknown so take away 2 hours every day for meetings and other stuff that comes up. Then take away 2-3 days to account for the Scrum Events, people getting sick, or other emergencies that WILL happen. That goes down to 8 days and 6 hours a day to an estimated capacity of 264 hours. That is a big difference in capacity between 440 and 264 hours! This will allow your team to have more time to focus on quality and deal with the unknowns and if the stars align and you finish the forecasted work before the end of the sprint, you can always pick up more work. Better to underplan and finish than overplan and be unable to finish.

The use of "coming up with" and "pick" with respect to Velocity seems unusual to me. You don't choose your Velocity - it's a characteristic of your team, the work, the way of working, and capacity. Applying Yesterday's Weather is generally seen as a good way to compute your Velocity - take the average of the past few (~3) Sprints. As long as your capacity isn't dramatically different between these Sprints past Sprints and the upcoming Sprint, this will get you a reasonable idea for how much work to take on. Of course, if one or more of these Sprints had more or less capacity than your upcoming Sprint, you need to adjust. Even in this case, you don't need a lot of math - you know if you can take on more or less work based on your capacity and don't need any complex math.

I would like to know if any of the scrum masters help in coming up with the velocity number, a team should pick keeping the past numbers in mind.

It sounds as though the team can plan based on evidence. Why isn’t that enough?

The team I am working with, tends to stretch work for days.

What are they doing to limit work in progress, so they jointly focus on items of one day or less?

I have a team of 5.5 developers, they usually commit 70-80 pointer to be delivered in 10 days

What about their commitment to the Sprint Goal?

I think I can contribute to effective planning if I can somehow mathematically calculate a number they should target every sprint. I have heard from other SMs that they drive that and it helps since the team won't be able to efficiently drive that. 

@Rhea Pillai, Should the Scrum Master contribute/participate during Planning or should the Scrum Master facilitate? Why can't the Scrum Master teach the team how to calculate their own capacity and trust that the team will be capable of doing it themselves? Wouldn't that be a step towards enabling teams to be self-organizing?

I need to determine per person story points every day so that we can then come out with a collective number.

Why? Does this not sound like you are trying to manage the team? Should a Scrum Master manage a team or even go this level?

Should the Scrum Master contribute/participate during Planning or should the Scrum Master facilitate?

I should have been a little more clear with a follow up question; When you say that you can contribute to effective Planning, are you both the Scrum Master and a member of the Development Team? i.e. playing two roles at once?

I need to determine per person story points every day so that we can then come out with a collective number.

Does this number out of this calculation reliable for your future sprint planning ? will it remain same each day or each sprint for your team members ? 

The team I am working with, tends to stretch work for days. I have a team of 5.5 developers, they usually commit 70-80 pointer to be delivered in 10 days.

As @Ian rightly mentioned above , What do you think about team's commitment towards the Sprint Goal ? How team collaborates on achieving this at the end of the Sprint ? Do think you have correct Sprint length for your product ?