Scrum questions

Firstly, scrum isn't a methodology, its a framework.  :-)

The Developers forecast their capacity based upon past performance using empiricism.  I don't think there is a formular for this, as the Developers determine how many PBIs they believe they can complete during sprint planning. 

Why do you want to measure velocity and capacity?  Please remember that if you do start measuring to ask the Developers what they wish to have measured and also remember that the measurements are only for the Developers and should not be used by management. 

I believe that capacity and velocity are two different things and should not be measured against each other. 

The Developers decide what engineering practices they wish to use in order to create the increment.  No one outside of the Developers can tell the Developers how they should be doing their work. 

Please review and understand the current version of the scrum guide in order to gain further insights into this framework. 

I am new to scrum methodologies,  I had the below three questions

Let's start with this. If Scrum was a methodology, and prescriptive answers to such questions existed, the value of Scrum would then be lost. Can you see why?

. I wanted to understand how capacity is planned in scrum, is there any formula to calculate it ?

Capacity is planned at each Sprint Planning event.  It is based upon the Developers opinion on what they can complete in the timebox for the next Sprint.  They will use empirical evidence from past Sprints as examples. But the real determination is based upon the knowledge they have of the Product Backlog Items and their expert knowledge of the domain.  Are there formulas?  You can find a lot of formulas with a simple search using your favorite web search portal but there is nothing prescribed in the Scrum framework (not methodology).

Also what is the ideal gap which should be maintained between sprint velocity and capacity during a sprint cycle ?

Velocity and capacity are two completely different terms.  From Merriam-Webster dictionary those words are defined as:

Capacity:  the maximum amount or number that can be contained or accommodated

Velocity: rate of occurrence or action : RAPIDITY

Notice that one measures an amount while the other measures activity.  There is not commonality between the two of them. Also I want to point out that the word "velocity" does not appear anywhere in the Scrum Guide and that "capacity" only occurs once.  So before you put too much faith into those data points you should really research and understand what they mean and how they could be used.  Personally, I don't track either one of them for any team that I am part of.

What are the best engineering practices from scrum master point of view which he/she should adopt during a sprint cycle ? 

As a Scrum Master your primary concern is not best engineering practices and you would not adopt any of them.  Engineering practices are the domain of the Developers and they are the ones that would adopt them. As a Scrum Master your concerns on helping Scrum Teams and the organization outside of the Scrum Teams understand and appreciate the Scrum framework.  The technology and engineering practices are the things you should care about the least. 

Since you say that you are new to the "Scrum methodology" I am going to suggest that you start your journey by focusing on learning and understanding the Scrum Guide (www.scrumguides.org).  Start there and spend the majority of your time there.  Don't start with any "guides" that you find anywhere else on the internet.  That is the definite guide maintained by Jeff Sutherland and Ken Schwaber. It can be found in multiple language translations on that site. The free assessments on this site are great ways to validate your understanding.

Scrum is a framework that provides some structure, but minimal prescription of activities.

1. I wanted to understand how capacity is planned in scrum, is there any formula to calculate it ?

There's no formula. Although one of the considerations in Sprint Planning is the forecasted capacity of the team, there are a number of different ways to determine it. Some teams may use Velocity and Yesterday's Weather. Other teams may count Done Product Backlog Items from previous Sprints. Other teams may estimate work in ideal hours and check that against the number of expected working hours in the next Sprint. There are probably other ways, too.

2. Also what is the ideal gap which should be maintained between sprint velocity and capacity during a sprint cycle ?

This is up to the team. I'm a proponent of always keeping some slack in the Sprint to account for the unexpected. However, the ideal amount of slack should be left up to the team. It may even change, Sprint-to-Sprint. The important thing is to have a valuable Sprint Goal that is achievable before the Sprint timebox ends.

3. What are the best engineering practices from scrum master point of view which he/she should adopt during a sprint cycle ?

I'm not sure how you define "engineering practices", but a Scrum Master should focus on teaching, coaching, and facilitation. The team should choose the appropriate engineering practices and find ways to implement them into their process.

Mate, you're not gonna get a positive reply from the community here, not because the people are rude but because your questions are intentionally not answered by Scrum. In other words, any methods of calculating capacity and velocity are fine with Scrum as long as you can reach your Sprint goals better with them, and the same is true for the engineering practices. The reason is, every team has its own unique situation and it is impossible to prescribe for them what to do.

As per capacity calculation, e.g. mature teams have their own ideas/practices while new teams would probably accept the advice of the Scrum Master. There are lots of great resources written on this topic and it is really not up to Scrum to decide which method you would consider best fitting your team. If you wish to calculate capacity at all.

As per engineering, that is a way harder area. Ideally, this is up to the team, however, when a team has no reasonable depth of knowledge in agile engineering, honestly, you cannot expect them to change their practices entirely on their own. I believe, it is unfortunately impossible to give concise advice on this topic as every situation is different. Even if we put aside technology, a lot depends on organizational culture, team culture, the background of the developers and of the Scrum Master, the maturity of middle managers, the support from the management in general, etc. We can borrow ideas from XP and DevOps but there is no 'best way' or a universally fitting generic way.

On the other hand, the Scrum Guide gives valuable guidance on these topics, e.g. for both capacity calculation and engineering practices it makes the developers responsible for the area, while the Scrum Master is responsible for guiding the team - though rather through consultation/inspiration and not through telling what to do.

I understand if you feel a bit empty-handed, however as said, Scrum is intentionally left incomplete.