Why You Need a Scrum Business Analyst for Your Team?

What exactly is the role that a Business Analyst plays in Scrum?

Yes, you read that right. Business Analyst is a role in projects running Agile methodologies including Scrum. And no – the BA isn’t dead in the Agile world.

In this post, we’ll look at some of the misconceptions associated with employing an Agile Business Analyst in a Scrum team. We’ll discover any dissimilarities between the BA role in Waterfall projects and a Scrum Business Analyst on Agile projects.

While at it, we’ll also uncover how the Scrum Business Analyst and the Product Owner coexist and complement each other to the betterment of the Scrum team and the project. Oh, and yes, you should have both the Product Owner and the Scrum BA on your Agile project running Scrum.

With that, let’s jump right in…

Do you need a Scrum Business Analyst?

Short answer: Yes.

To understand why, let’s look at the role of a Business Analyst in general. A quick internet search throws up this definition (among many others, I must say):

“Business analysis is a research discipline of identifying business needs and determining solutions to business problems. Solutions often include a software-systems development component, but may also consist of process improvement, organizational change or strategic planning and policy development.”

That, in a nutshell, describes the traditional role of a BA.

The Business Analyst traditionally performed the important role of understanding business needs and identifying solutions. Not all by their own, of course, but on traditional IT projects, the Business Analyst ‘owned‘ Requirements Analysis and Requirements Management.

The BA also played an active and significant part in Solution Analysis and Design, given the wealth of ‘business‘ knowledge and perspective they build with Requirements Analysis.

The BAs, therefore, took on a certain level of accountability to the Business, in ensuring the business needs were understood and well represented.

On Waterfall projects, this approach is fraught with problems.

Some of them are down to the nature of Waterfall itself, yet a number of the problems can be attributed to the fact that the BA, after the Requirements phase is complete, becomes more or less the Business Representative on the project.

The BA is expected to answer on behalf of the business, support requirements related discussions during design, development and testing phases of the project. And then comes the UAT (User Acceptance Test) when the ‘real business’ (or ‘users’) get to see the product, and this is when hell freezes over.

The business (more often than we’d like) express suitable consternation at how the product doesn’t represent their ‘expectations’, and the dance begins. The product meets the requirements, but it doesn’t meet the business sponsor’s vision for it… you get the drift.

Requirements Ownership on Agile projects – Enter the Product Owner

So on Agile, we’ve laid the responsibility of defining clear requirements and frequently signing off product iterations squarely on the business’ shoulder.

We’ve asked the business to appoint a Product Owner, who will report directly to the business sponsor (or double up as the business sponsor as the situation demands it).

• The Product Owner (PO) works with the business and IT/other teams to define a Product roadmap
• The PO defines Minimum Viable Product (MVP)
• The PO takes direct responsibility for elaborating Requirements (user stories)
• The PO then ranks and prioritises requirements so the Scrum team can just blindly pick the top priority and top ranked requirements for delivery, every single time
• The PO is present more than ‘business’ ever have on Waterfall projects, to lend support and guidance to the Scrum team
• The PO validates and approves Scrum delivery at the end of each Sprint
• The PO frequently reviews and proposes any changes to product vision

In summary, the PO, and the business they report to, take direct responsibility for everything the Scrum team delivers. Good. We all know the benefits this approach brings.

Where does this leave the Business Analyst?

Very much in the thick of the action.

The Product Owner, while responsible for defining the MVP, building and prioritising a Product Backlog and signing off Sprint deliverables, needs the support of experienced BAs to help them keep the Sprints chugging along.

Scrum Business Analysts complement and support the PO in a number of ways:

• They carry the brunt of the Requirements Elaboration effort, while still deferring to the PO for final decision making.
• They elaborate Acceptance Criteria for user stories prioritised by the PO.
• They (usually) bring good product and systems understanding, and advise the PO on Requirements Analysis, Scope, MVP, User stories and Prioritisation.
• They work with extended stakeholder teams to understand and analyse any customisation needs.
• For instance, if you are deploying a mobile app to a number of markets where your company has a presence, the BA would work alongside the PO to discuss market specific requirements and practices that need to be catered for before the product launch. Typically, I’ve seen a PO appoint Lead BAs to support customisation and implementation of a product in each of their markets.
• During Sprints, BAs provide everyday Requirements and Solutions support to the Scrum team and step in for the PO where the PO isn’t immediately available.
• Scrum BAs take on the additional System Analyst dimension, amalgamating (rightly) two key Analysis functions (more on this later).
• Scrum BAs regularly conduct Analysis into a number of activities including Sprint Planning and Backlog Grooming, and recommend next actions and decisions for the PO’s approval.
• A lot of the time, Scrum BAs go on to become Product Owners – given sufficient product ownership and involvement and business and market acumen among other factors.

Does Scrum allow for the BA role?

Ken Schwaber and Jeff Sutherland gave us the seminal Scrum guide, a one-stop resource for everything Scrum. And in the guide, Schwaber and Sutherland mention the three key parties to Scrum delivery: Product Owner, Scrum Master and the ‘Development Team’.

Do we interpret ‘development’ team as a team of just developers? Do Schwaber and Sutherland mean that all you need in Scrum are the PO, Scrum Master and a team of people that can write code?

If that is true, you wouldn’t need Testers, Release and Implementation teams that work to push the product to customers, would you? Then why assume you don’t need the BA?

Scrum references the ‘development’ team as cross-functional; that it has all the skills – not just coding skills. And, one of the skills is – you guessed it right – the Business Analyst.

Let us therefore put to rest any further pointless discussions about the need for BAs on an Agile project.

Waterfall BA vs Scrum Business Analyst

There are similarities to how a BA functions on projects running Waterfall (and other traditional software development methodologies) and Agile methodologies. And there are dissimilarities as well.

To be clear, the core skills as defined by the BABOK guide are:

• Business Analysis Planning and Monitoring
• Elicitation
• Requirements Management and Communication
• Enterprise Analysis
• Requirements Analysis
• Solution Assessment and Validation

These skills are essential to anyone playing the BA role – and on projects running any methodology.

So are the underlying competencies such as Critical and Analytical Thinking, Problem Solving, Behavioural and Communication skills.

Business Knowledge and in depth understanding of the systems, system areas are extremely desirable as well, while not indispensable. A skilled BA can be cross-domain, i.e., move across different domains like Banking, Telecom, Travel, eCommerce, etc. while staying effective.

Now on to the differences:

On Waterfall projects, the bulk of the Business Analyst’s work happens up front during the initial phases. Initiation, Business Case, Requirements Analysis and Solutions Analysis and Design are when BAs are engaged in droves (on big project initiatives, ‘droves’ carries actual meaning).

I’ve noticed that the BAs’ involvement on Waterfall tapers down as a project moves into detailed design and development. A sub-cadre of Analysts, called ‘System Analysts’, usually take over from the BAs at this point (I’ve always maintained that these are also just BAs whose primary focus is to deliver the intended solution rather than business needs analysis).

Typical BA time allocation on a Waterfall project looks something like this:

• 100% during the Initiation and Requirements phases
• 75% during Solutions Analysis and Project kick off
• 50-75% during Solution Design
• 25-50% during Development and Test (with support from System Analysts)
• 10-25% during Implementation and post-implementation support (System Analysts play a major role here)

This example doesn’t include any Training, Operations and Business Readiness activities of course – just the IT side of the project. But you can see how the BA is involved less and less as the project moves to its critical phase – implementation.

As you probably already know, this is a recipe for disaster. BAs on waterfall projects carry in depth understanding of the business requirements, and so not to have them around full time doesn’t benefit the project team.

We’ve spent countless dozens of hours discussing the right allocation of a BA’s resource during various stages of a waterfall project, and there is no single answer that everyone agrees with. But there is universal acknowledgement that the individual(s) who wrote the requirements should be more or completely involved during development, test and implementation.

On the other hand, let’s look at Agile projects and how BAs work with them.

Agile methodologies (and specifically Scrum) expect every project team member (including the Scrum Business Analyst) to dedicate their time entirely to just one Scrum. Obviously there are exceptions (e.g. IT Architects usually support and guide multiple initiatives at the same time), but these are expected to be well justified and far and few in between.

Scrum Business Analysts deliver a bit of their work during every Sprint, rather than up front like on Waterfall projects.

Scrum BAs are heavily involved in Solution Design and support Development and Testing extensively.

They sit with the Scrum team day in and day out, and are on hand to provide any support necessary.

Scrum BAs take on a lot of the System Analysis responsibilities, and so take on an end-to-end perspective of and involvement in the project and its requirements.

As you can see, there is a lot more direct involvement throughout the delivery of a project for Scrum BAs as opposed to Waterfall BAs.

Without getting into which of Waterfall or Agile methodologies is better (the answer is ‘It depends’), how a Business Analyst interacts with the project team varies significantly between Scrum and Waterfall. And on Scrum, having the Business Analyst around full time brings a host of benefits as described above.

Bringing It All Together

Redundancy is good.

Throughout history, man has striven to rid himself of activities and chores that can be delegated, automated or eliminated:

• Walking and running delegated to animal-driven and later machine-driven vehicles
• Automation has replaced a lot of manual labour
• Autopilot is a thing – on the sea, in the air, now on the road
• AI is emulating and replacing human interaction, and rapidly

So it makes sense that we continuously look for redundancies in our workplace, and life in general.

In the quest to build a highly efficient IT project team, we’ve tried a lot of things over the past four to five decades. We’ve tried quality metrics from Lean Six Sigma to Kaizen, Iterative development methodologies, and as their offshoot, Agile-driven practices of late. It’s true that a lot of project roles are being eliminated – especially at the ‘managerial’ level.

The Business Analyst isn’t one of these, however. We’ve today seen why the Scrum Business Analyst is a real role, and how the Scrum BA adds value to an Agile project team. We’ve also reviewed how the BA works differently on Agile compared to Waterfall projects. And how they complement and support the Product Owner.

There is tremendous demand for fulfilling the BA role on Agile projects today, and that is mainly due to ill informed decisions to not resource for these roles made by people that don’t understand Scrum.

Persevere in your quest to build a career as a Scrum Business Analyst. The fruits of your labour will be sweet.

If this article helped you realise the significance of the BA role in Agile and Scrum, why not like or share it with your friends and colleagues so they can benefit too?