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.
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".