Does a business analyst fit into the Scrum framework?

Question

Question

Let's consider a software development project made for an external customer. The development company (the vendor) has the usual positions and specialists: developers, testers, business analysts, managers. The project is going to be done using Scrum. What is the way a business analyst works within a Scrum Team? How do they fit into the agile workflow of the Scrum Team? Should a Scrum Team have a business analyst at all?

Concerns

How can the business analyst's involvement be continuous and synchronized with Sprints?

They need to go ahead of the Development Team by at least one Sprint, so that in the Planning Meeting the requirements are ready, well-defined, clearly decomposed, etc. The business analyst (BA) becomes a proxy PO then. But in this case, the Developers will be asking the BA how to implement the product, instead of asking the PO, stakeholders, or users.

If they discuss the requirements together with the Developers in the Planning Meeting and then write them down as the Developers are implementing them, then the BA's become more like technical writers.

Answer 1

TL;DR

The canonically-correct solution is to put someone with business analysis skills onto the Scrum Team in a Developer role, and then cross-train the whole Scrum Team. Cross-pollination of skills enhances the capabilities of the Scrum Team and the Developers, and builds T-shaped people.

Including someone skilled in business analysis on the Scrum Team also facilitates collaboration in analyzing requirements and identifying pragmatic engineering/architectural solutions, rather than stove-piping your process and treating development as "downstream" from big, upfront design (BUFD). BUFD is inherently antithetical to Scrum's empirical control process, where iterative development, emergent design, and just-in-time planning are critical components.

Don't Conflate Roles and Skills

The Scrum Team section of the 2020 Scrum Guide says:

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.

That means you are welcome to add someone skilled in business analysis to your Scrum Team, but from a Scrum roles perspective they are simply one of the Scrum Developers. There are absolutely no other roles on a Scrum Team other than Product Owner, Scrum Master, and Developers.

Externalizing Roles

Another answer suggests that business analysis could be externalized. From a purely pragmatic viewpoint, you might be able to do this, with two caveats:

1. The Product Owner would then be accountable for business analysis because:

   The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

2. When the workflow contains external dependencies, the Scrum Team no longer has all the skills needed to self-manage the work, and this can reduce agility and adaptation.

Unavoidable externalities are...well, unavoidable. However, deliberately creating an external dependency seems counterproductive.

Answer 2

There are two answers here - the Scrum answer and the my practical answer.

In Scrum, there are three "accountabilities" (prior to the November 2020 revision, roles) on a Scrum Team - Scrum Master, Product Owner, and Developer. A team has one Scrum Master, one Product Owner, and everyone fits into one of these buckets. However, if there are multiple teams working on a single product, the Product Owner would be aligned with the product and shared across all of the teams. Based on your description, it sounds like the Business Analyst's work and the things that the Product Owner tend to do have a lot of overlap, however the BA isn't in a position to have their decisions respected by the organization and someone else is ultimately accountable for the decisions regarding product direction.

Based on the definition in Scrum, I believe that Scrum vastly underestimates the amount of effort required for product management and discovery.

The Scrum Guide says that the "Product Owner is one person, not a committee". Given the nature of product management and the vast scope - market analysis, competition analysis, business analysis, requirements engineering, commercialization, sales, scheduling, budgeting, and more - I don't believe that it's reasonable to expect one person to be able to handle this. This is compounded when you consider human factors and user experience as a part of product management. The idea that there should be a singular voice making product decisions is sound, this person needs to be supported by a variety of people that, together, have all of the skills necessary to carry out product management.

Business analysis is one of the skills that may be necessary to support a Product Owner. This could be a specialist individual or it could be someone who performs business analysis along other work.

Once you realize that there is a team performing discovery work, you can look at dual-track agile (1, 2, 3), where the discovery work feeds into the Product Backlog for the Scrum Team. There isn't a hard wall or hand-off between the two teams, there has to be collaboration to make sure that both aspects are doing the right thing. However, there's a clear distinction between understanding and defining the problem (discovery) and delivery (technical understanding and definition, prototyping, design, implementation, test, and deployment).

The team behind the Product Owner becomes the source for answers to questions that the developers have. This could be the Product Owner, or the Product Owner could defer to one of the specialists supporting the product.

Answer 3

I have seen many business analysts work well in Scrum teams.

The three biggest challenges for them are typically:

• Reaching a clear understanding of roles and responsibilities with the Product Owner
• Adjusting to the just-in-time nature of Scrum - looking to add detail at the latest possible moment
• Becoming good at responding to change - taking feedback from the stakeholders and incorporating it quickly into their analysis

One often overlooked value of a BA on a Scrum team is that when they collaborate well with the Product Owner they form a really good backup for the PO role. For example, I have often seen the team BA step in when the Product Owner is on holiday or off sick.

Answer 4

I usually see BAs work in one of two ways. Sometimes they assist on items being developed in the current sprint by providing their domain expertise to developers, helping to fill in any missing details and working with users and testers to understand any problems. Requirements don't have to be fully defined at the time of sprint planning - they just need to be sufficiently ready so that the current sprint goal is achievable.

Alternatively, teams will sometimes create analysis-only stories - stories which will define further work that gets completed in future sprints. This is reasonable for example if the PO needs certain details to be worked out in order to create or prioritise new backlog items. It's a very common thing to do at the beginning of a new product or workstream. This still doesn't have to mean every detail is defined before sprint planning because the BA should still be able to contribute during development and testing. As the team works along a narrowing cone of uncertainty the instances of analysis-only stories should tend to be fewer.

Answer 5

Scrum just says that the team needs to have all the skills needed to build the product and all the product increments leading up to the final result. Although no other role than "developer" is identified in Scrum, teams often contain specialized skills, like front-end developer, back-end developers, testers, designers, etc.

So if the product you are building needs business analysts, then you can have people doing this job in supporting the work of the Product Owner. The role might be needed in more complex domains like law, finance, insurance, banking, etc, or in a more complex project with multiple Scrum teams, where the PO needs some help in defining the product and its details (the PO remains responsible and accountable).

As activities, the business analyst in Agile performs similar functions as in more traditional methodologies, but the involvement differes and it happens continuously throughout the development of the product, in every sprint, not just at the beginning stages of the project.

Answer 6

BA can be a part of a Scrum Team but it depends. In Scrum, there are three roles - Scrum Master, PO, and Dev. BA's work overlaps with the PO's work but PO has the final say. Product management requires a team effort with skills like BA, market analysis, and more. Once you have a discovery team, you can use dual-track agile for collaboration. The team behind the PO can answer Dev's questions.