Role of Business Analyst in Scrum and Best Practices for Analysis Process

In my current team, BA is not a part of the scrum team. BA is a separate team and they flesh out the backlog items identified, by doing the analysis work in advance. This helps the team to have a better understanding of the story and in turn helps to create a better DoD. They also work with PO to create the priority list which helps PO to decide which stories to take in the sprint elaboration meeting. 

Of course, if there is a clarification needed during the development or testing, we reach out to BAs and have calls with the BA team and get the clarifications. Due to the product knowledge my team have (we are working on the same product for close to 2 years now), many times, my dev team or QA team can contribute to the analysis and we capture this in the story but gets it validated by BA team before we act on it. 

In short, they are not a part of the scrum team and do not take part in daily scrum calls, but we have close interaction with them and they are present in sprint elaboration meeting and sprint retrospective (and sometimes during the sprint review\demo also) and also have multiple meetings with the team during the sprint as and when required.

Anyone whose work is needed during a Sprint to meet the Goal, and to create a Done increment, should be recognized as a member of the Development Team.

If Business Analysts are essentially involved in Product Backlog refinement, and in maturing items to a “ready” state in advance of Sprint Planning, then any further input from them during the Sprint in which that work is actioned might not be critical. In this situation, they could essentially be stakeholders assisting the Product Owner, rather than Dev Team members. The PO would be accountable for that relationship and any refinement done.

+1 Ian

Scrum makes a clear distinction between the "what" (business value, requirements, acceptance criteria, etc), and the "how" (potential solution).

The Business Analyst could be involved in the "How" portion through acceptance criteria verification (thoroughness, accuracy, testing, etc).  However, if this is not your approach, then the Business Analyst is aligned most closely with the Product Owner in the construction of the "What".

Hi Semih,

In my current experience as Scrum Master, we have integrated two BA into the Scrum Team as Proxy Product Owner.

They work with the PO and help him in on all its tasks (manage PB, write US and acceptance criteria, etc.) and they also test.

Can you define what is a proxy PO and its accountability ?

Olivier,

In my experience, a "Proxy-PO" is someone who substitutes for the actual PO due to either capacity limitations or an unwillingness to perform PO duties.   

Per LeSS (where I believe the term originated from), it is recognized as an unnecessary organizational layer, and is not a part of Scrum.

However, I do believe that BA's can work very well with PO's in initially creating and defining items for refinement discussion with the Dev Team, as well as working with the Dev Team to develop acceptance criteria and execute testing of such items.

Ian, I like your recommendation above and I'm faced with the same issue currently.  I like the idea of having them as PO stakeholders and the PO manages their relationship. 

What I'm seeing in my current environment is our scrum team consists of 2x BA's, 2x Dev, and 2x Testers, collectively called the 'do-ers'.  Because of this, we have confusion over what is needed for a story to be considered ready for development and what analysis can occur within a sprint.  If analysis does occur in a sprint, it pushes the start of any development work out because the developers end up waiting for this to occur before they start working on anything, in essence they've created an internal dependency within the team.  

What I've suggested is we have a BA attached to the PO to perform any upfront analysis needed to have a requirement or item conform to the definition of Ready, and another BA to support the development team in regards to requirement clarification activities, any mapping activities that need to be done, and to assist with ensuring any documentation created as part of the output is done in a consistent manner.  This seems to have alleviated the confusion a little, I'm hoping I've solved this in the right way though.  

clarification of my post above: the first BA is helping the PO from a business perspective, the refinement process needs to still take place to ensure the dev team have the opportunity for clarification and to add more detail as necessary.

confusion over what is needed for a story to be considered ready for development and what analysis can occur within a sprint

As a BA I've had this come up several times.

Does the Definition of Ready include enough information for the team to get started on the PBI?

One common piece of information that we often don't include in the definition of ready is the specific text to show to the user. This is something that can be worked out during the development of the PBI. So I've seen in teams that it's OK to not have this and for a PBI to still be "ready".