which fields in jira are absolutely essential for BAs to fill to track the project performance

[Ash]

which fields in jira are deemed absolutely essential for BAs to fill to track the project performance and keep track of their workload and capacity

[Nic Brough -Adaptavist- · Accepted solution]

Welcome to the Atlassian Community!

That depends entirely on what methodology your teams are using to work on stuff.  It is a very vague question, one that we can't start to talk about unless we know whether you are broken (waterfall), partly or fully Agile, using Scrum, Kanban, Lean, etc etc etc

[Ash]

understand, i want to understand both in fully agile methodology and Kanban methodology

[Nic Brough -Adaptavist-]

This is still quite a vague question which could easily turn into a huge essay on history.

A brief summary from me would include 

Agile is a framework for getting stuff that people need doing, rather than spending years building something that is not going to be what people need when you finally deliver it.  Compared with "waterfall", you reduce the planning so you can get more done, you iterate, checking that you're delivering actually useful rather than vague promises, and you collaborate with everyone.  Have a skim of https://agilemanifesto.org

Scrum and Kanban existed before Agile was framed by that team.  I was introduced to Scrum by one of the authors of the manifesto, in the late 1990's, a few years before the manifesto was written, but I don't know how old it is.  Kanban methods are about 80 years old - Toyota started doing it in the 1940's

But they both fit very well with Agile - they emphasise delivery over planning.  If someone thinks they want a car today, Waterfall will deliver one that matches today's requirements in 5 years, which probably won't be valid requirements any more.  Agile delivers roller skates in a few weeks, which isn't a car, but may be an improvement on walking, and gives the end-user the opportunity to tell the developers what is right or wrong about them, so the next iteration is maybe a basic bicycle, then one with gears, then one with power, then a couple more wheels, etc etc etc.

Comparing Scrum and Kanban is an odd one - they're both Agile because they a) deliver and b) take iterative feedback, but they do work very differently.

You need to think about how you want to work.  The short version of the differences is that Scrum should be used mainly when you need to be able to plan, and Kanban is more for "drinking from the firehose".  In an IT environment, in my opinion ,Scrum is better for development projects, and Kanban is more for support and recurring tasks that always need doing.