Role of Business Analyst in Scrum and Best Practices for Analysis Process
I am wondering the role of Business Analyst in Scrum Team. According to my previous experience and personally I believe Business Analyst must be in Development Team and Development Team should be form like Developers,Testers and Business Analyst. Business Analyst worked for the analysis of the next sprint's PBIs according to the information that taken from the Product Owner. He/She analysis the bug,new features and ext and made detail analysis. Product Owner created the user story and acceptance criteria and after that BA will ripen the User Stories and acceptance criteria as well.Personally
In my new organizaton, the structure is little bit different. Business Analysts group is different and they are seperate from the Scrum Team. But they are making analysis of the PBI but development team(Developer and Testers) also make analysis sometimes during the sprint. That is what I have to change once I would like to ensure the best practices. Because my previous experience migh be wrong :)
I will be appreciate if you can share your ideas and best practices as well regarding what is the best way to form Analysis process in Scrum ? Do you agree with Developer or Tester can make analysis during the sprint ? Can BA seperate from Scrum Team or they should be in Development Team?
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.
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".
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 ?
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.