7

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.

4
  • 7
    Based on all the related questions you've asked, I can't help feeling like your company is hell-bent on layering Scrum in Name Only℠ over traditional, non-agile processes. The whole point is that "what" is for stakeholders (through the PO), while "how" is left up to the Developers (in collaboration with the PO). – Todd A. Jacobs Dec 23 '20 at 19:11
  • But the Developers themselves don't know how to work in Scrum environment, they ask me, and I don't always have answers. The Scrum Guide doesn't provide many details. By the way, I have never ever seen a Scrum team - I have only seen ScrumBut teams in practice. – Daniel Dec 23 '20 at 21:04
  • @Daniel, "I have never ever seen a Scrum team - I have only seen ScrumBut teams in practice" - if it hurts and people don't understand the value and there's no one around with a whip - they won't do it. Scrum hurts everyone so much that people naturally lean towards more effective processes like ScrumBut. ScrumBut is actually what makes teams more agile - they find that Scrum doesn't fit their needs and they modify their process to become more effective. – Stanislav Bashkyrtsev Dec 24 '20 at 12:04
  • I think this question will eventually lead to extended discussion because it's really two questions in one: 1) Should a Scrum Team have a dedicated BA role? and 2) How does a Scrum Team handle traditional BA responsibilities?. Changing the question too much might invalidate current answers, so please don't do that, but please consider asking them as separate-but-linked questions if you'd like differently-focused answers. – Todd A. Jacobs Dec 24 '20 at 16:19
5

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.

7
  • I think this answers only what BAs are, but not how to sync them with sprints since they have to do their work upfront. – Stanislav Bashkyrtsev Dec 24 '20 at 12:16
  • @StanislavBashkyrtsev No, they don’t. Just like testing, analysis should be an ongoing, collaborative, just-enough, and just-in-time process. If you don’t agree that is axiomatic, then you’re essentially asking how to implement a mini-waterfall inside your agile process. – Todd A. Jacobs Dec 24 '20 at 14:08
  • 1
    Just-enough & just-in-time for BAs mean - before devs started to work on a task. Additionally there needs to be a buffer so that BAs don't accidentally block Devs. Since we're discussing Scrum here: by the time planning happens all tasks should've been analyzed, otherwise the planning will be... awkward to say the least. Ergo, next sprint tasks should be analyzed in current sprint. – Stanislav Bashkyrtsev Dec 24 '20 at 14:55
  • @StanislavBashkyrtsev There are no dedicated BA roles. If you want to put I-shaped people onto your Scrum Team, and the team collectively decides to dedicate them solely to Backlog Refinement or talking to stakeholders on behalf of the PO or Developers, then the framework permits that even if it’s suboptimal. BUFD is antithetical to iterative, incremental, and emergent design, so please stop blaming the framework for not mapping 1:1 to a totally different model. – Todd A. Jacobs Dec 24 '20 at 15:12
  • 1
    Not sure why you include Agile in here since it doesn't frown upon such role (though you seem to relate BAs with BUFD for some reason).. But yeah - Scrum seems to either accept BA in the role of a PO (which is shaky since BAs are rarely stakeholders), or denies it completely because such person can't be included in the list of Developers who work on current sprint. Which is interesting because there are lot's of projects with complicated domain which can't survive w/o traditional BAs. – Stanislav Bashkyrtsev Dec 24 '20 at 17:00
4

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.

4

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.

1
  • +1. I agree that it works well when the BA is not seen as apart from the other Developers and defers design to the last responsible moment. In my personal experience, though, it fails to work when the BA accountability is not shared by the team, or when development is treated as downstream from requirements gathering/analysis. – Todd A. Jacobs Dec 24 '20 at 21:43
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.

2
  • I upvoted your answer because it directly addresses the Y in the OP's X/Y problem. My answer is more focused on what the team should do, rather than how they should do it, so I think your answer adds a lot of value. – Todd A. Jacobs Dec 23 '20 at 19:18
  • @StanislavBashkyrtsev This answer addresses some of the implementation-level approaches that are possible within the framework. If it doesn't address the concerns you expressed in other comments, please open a new question, because I think you're raising legitimate implementation questions beyond the central roles-related question in the top-level OP. – Todd A. Jacobs Dec 24 '20 at 16:08
3

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.

3
  • But 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 then, so that on the Planning Meeting the requirements are ready, well-defined, clearly decomposed, etc. Business analyst becomes a proxy PO then. – Daniel Dec 23 '20 at 17:53
  • 1
    @Daniel You're trying to persist an upstream/downstream dichotomy. Why even bother with Scrum if you just want to do waterfall? BUFD can be useful in some domains, so if it's working for you, why do Scrum (which is an iterative framework) at all? – Todd A. Jacobs Dec 23 '20 at 19:14
  • 1
    @Daniel: the output of any business analyst you might want to add to the team will mostly reflect into the content of the backlog, which is a living artefact that is continuously refined, and yes, would need to have enough details for the next sprint to be able to be planned and started, but don't think of it as a proxy position. Everyone is on the same level in the team, a BA won't sit in between the PO and the developers. – Bogdan Dec 23 '20 at 19:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.