User stories estimation for BA analysis work

It sounds like the Business Analyst is doing work more closely related to the Product Owner accountabilities from the Scrum Guide. They are discovering and documenting what is needed to improve the product.  This section of the Scrum Guide explains that as an accountability for the Product Owner.   Note that it also states that they can do it themselves or delegate the responsibility to others.  If you do not estimate the work of the Product Owner, why would you estimate the work of the Business Analyst? Refinement is not estimated. It is not work that is contained in the Sprint Backlog.  

Your Agile Coach seems to have a very strange view of the Scrum framework.  They appear to believe that adding up a bunch of numbers that represent guesses made by the Developers is a way to determine effectiveness of a team.  Your Agile Coach is promoting a false sense of security that I would not want to support.  In fact, it would make me question anything that they said. 

Recently my Agile coach advised me that we need to have estimates for the User stories which BA is working on in the current sprint.

Is the BA one of the Developers, meaning that his or her work is necessary to have a Done increment this Sprint?

If not -- and he or she is preparing work for possible actioning in future Sprints -- then estimation of it makes little sense. The only purpose of estimation is so the Developers can get their arms around how much work they can take on and complete in a Sprint.

According to him we are losing our velocity by not adding Story points for BA work. 

Ask him what he thinks velocity actually is, and what it is used for.

Velocity is quite simply the rate at which work is Done. Preparing work for possible actioning in a future Sprint cannot contribute to velocity.

The purpose of measuring velocity is to help the Developers estimate. It has no value in itself nor can it proxy for value. Value lies in having at least one Done and immediately usable increment each Sprint.

The Scrum Guide is silent on story points and velocity. Sizing is mentioned as potentially being part of backlog refinement activities and that Developers doing the work are the ones who would do the sizing. Beyond that we are getting into discussing complimentary practices.

If you are sizing User Stories, it is the story itself that is sized, not each activity that may be associated to it. I like to think of estimates in relation to the time box in which we are working. Is this work sized appropriately to be started and finished within our Sprint timebox. If not, break it into smaller valuable pieces. 

I like the Scrum.org glossary definition of Velocity as it puts focus on the amount of Backlog turned into an Increment, or as Ian put it, “the rate at which work is Done”… 

Velocity: an optional, but often used, indication of the amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Developers for use within the Scrum Team.

Velocity is not a tangible thing to be won or lost. 

Hi Ian, yes BA is preparing the User stories for the upcoming Sprint. 

Sometimes BA start working on 2 User stories and in the middle of the sprint they might add few more User stories. We keep our User stories in the Backlog.

How would you estimate those User stories

My question is: how we estimate the User story where BA still needs to do the analysis work and refinement work for next sprint. 

How can you estimate a work item when its scope is not refined ? Is there any functional analysis or design that BA does as task for backlog items/user stories that are taken for development in the sprint, then that is possibly an effort to count while sizing in Sprint planning. But preparing for refinement is a continuous process cannot be time-boxed in a Sprint. The expectation from BA is to make enough backlog items ready to be planned in the upcoming sprint. If that is not done, then the team can check how that can be improved.