Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
This question was proposed by the participants of the discussion of the previous, more general question.
The business analyst's work often implies a kind of waterfall-ish or upfront-design approach. Because of this, I suppose, it becomes controversial when considered in the context of an agile, Scrum environment.
How does a Scrum Team handle traditional BA responsibilities?
How does a Scrum Team handle traditional BA responsibilities?
A skilled analyst is a useful asset for a Scrum team.
How well they work in a Scrum team comes down to a matter of timing.
The challenge is for the BA to do the analysis in a manner that allows the team to respond quickly to change. They need to avoid tying the team in to a particular approach too early. They also need to effectively incorporate stakeholder and customer feedback at short notice.
There is no single answer to how a BA will work in a Scrum team as it will depend on the team, the domain and the organisation. As with all things agile, it is important for the team to have a good inspect-and-adapt cycle that allows them to gradually optimise how the BA works with the team.
To answer this effectively, it is important to split roles, job titles, and skills. Scrum has absolutely nothing to say about job titles, so we can actually resolve that fairly quickly by saying: as long as a particular "job" does not expressly conflict with Scrum, it is "allowed" in the Scrum framework.That isn't to say that particular jobs may frequently cause disfunction. For example, a manager is "allowed" in Scrum, but if that manager is measured by his ability to drive output from the team and then the rules of Scrum are respected, hindering the manager's ability to do so, this is a recipe for disaster.
Now, Scrum describes 3 roles (actually called accountabilities in the newest revision of the guide). The Product Owner, the Scrum Master, and the Developers (think product developers, not coders). There are some rules in place about how these 3 accountabilities interact. For example, the Product Owner is accountable for ordering the backlog, while the Developers are accountable for creating the plan for the Sprint.
Both of these require certain skills and this is where someone who is used to playing the BA role may have some challenges to overcome. In many organizations, a BA is expected to work with stakeholders, understand priorities, create transparency, etc. These are clearly skills required by the PO and accountabilities of the PO. On the other hand, many BAs are also asked to figure out what work needs to be done and how. These are skills and accountabilities of the Developers. This is where having a BA can be problematic in Scrum. Now, there is a point in the Scrum Guide that says that the PO doesn't have to do the things they are accountable for. So, one could argue that a BA is simply a member of the Development team doing the things that the PO owns. This, however, gets messy in practice. Does the PO really own it? Often not. Also, there are no subteams in the Developers - does every developer have shared accountability for those things the BA does? Not in most cases.
At the end of the day, the question about BAs for most companies comes down to this: if you are trying to half-change the way you work and half stay the same, you're setting yourself up for failure. You can improve how you develop software without adopting Scrum. You can even adopt some Scrum practices if you like them. But if you say you want to practice Scrum and get all the benefits of Scrum, you kind of have to commit.
In my 12-people team there are 2 BAs* and at the moment we have 24 tickets (bugs, new features, technical stuff) in the backlog. So I disagree that having BAs imply a lot of upfront work.
As for the Scrum, as I discussed in the comments - it doesn't seem like it allows BAs:
While it may not be Scrum, I don't think BAs prevent you from being agile in any way.
*To be fair - we aren't just BAs. I'm also a Team Lead, and the other BA sometimes does some testing. And we both take on support activities. But still both of us create future tasks. We don't use Scrum, but even if we did - we'd do the same, there's simply no other way for us to work.
Up-front caveat... I have limited formal Agile (especially Scrum) experience, however I have used aspects of Agile approaches fairly widely, and some of my teams have included people with BA skills. I would anticipate that a BA-type role could be used quite widely within a project being run using formal Agile (including Scrum) principles.
Firstly, to support the work of the Product Owner in defining the specific outputs and outcomes of the system, which may require investigation and analysis with inputs from system users and recipients of the outputs from the system. The PO may not have the specific detailed knowledge of all aspects of the requirements, so would benefit from someone helping to document these requirements in support of the user stories. (Apologies if the terminology is not quite right).
Secondly, to work as part of the development team, providing the business inputs on behalf of the Product Owner and helping the rest of the team to interpret the requirements correctly, thereby avoiding rework in subsequent sprints.
Thirdly, to work as a member of the development team to help to check the outputs and outcomes of the development (definition, design, and conducting of tests and test cases).
Let's take a closer look at the specific "traditional BA responsibilities":
From my experience, these are >90% the tasks of BA's and having BA's deal with these tasks only adds complexity and no benefits. Having BA's in your team is typically a sign that (some) members of the team have not figured out the vast benefits of applying Scrum. And as the Scrum guide states, you can either apply Scrum 100% or not. In addition, take a look at the time-boxes of Scrum events. The sprint planning, where you traditionally come up with solutions to problems and create user-stories, may take up to 8 hours - the longest of all Scrum events. At the same time, in reality, often this meeting (even if you add Refinement meetings during the sprint to it) takes up far less time. This is because the developers and PO do not take the task of solving real business problems but BA's or other people specify what "developers should code".
