5

Linked Question

This question was proposed by the participants of the discussion of the previous, more general question.

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?

14
  • 4
    Can you share what you think the "traditional BA responsibilities" are for you? I was writing an answer but then realized I might be having very different expectations from one than you do.
    – Erik
    Dec 24 '20 at 18:24
  • I'd like to keep the question as general as possible, to allow many different approaches be captured and discussed.
    – Daniel
    Dec 24 '20 at 18:29
  • 2
    I agree with @Erik - unless you define what "traditional BA responsibilities" are, this question is too broad to be answerable. Different organizations have different definitions of what they consider to be the responsibilities of a business analyst.
    – Thomas Owens
    Dec 24 '20 at 19:25
  • @ThomasOwens The question was proposed by a participant of the discussion of the linked question, so let's adress your comment to him. But, nevertheless, I've described (in this question) the main concern related the BAs - they need to work in a waterfall-ish way, meaning that they need to analyse the scope, the requirements BEFORE the developers start working on them.
    – Daniel
    Dec 24 '20 at 19:56
  • 1
    @Daniel if one of the requirements is "cannot be allowed to do things the Scrum way", that's going to be the only answer you'll get. That said, one of the projects I work on is in a complex fintech-like field, and we don't clearly decompose or clearly define tasks before the sprint, we do it during the sprint.
    – Erik
    Dec 25 '20 at 7:22
0

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.

8

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.

6
  • Nicely said! I upvoted this because I think your third paragraph gets to the heart of the matter. I also think your last paragraph is essential, although I'd be inclined to make it stronger than (emph. mine) "kind of have to commit."
    – Todd A. Jacobs
    Dec 24 '20 at 21:12
  • Regarding roles, for future visitors (emph. mine): "Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master." scrumguides.org/scrum-guide.html#scrum-team
    – Todd A. Jacobs
    Dec 24 '20 at 21:14
  • 1
    This is a fantastic answer given the ambiguities in the question. The last paragraph, about half changing a way of working, really pulls it all together for me.
    – Thomas Owens
    Dec 24 '20 at 21:36
  • 1
    "But if you say you want to practice Scrum and get all the benefits of Scrum, you kind of have to commit." You can also commit to adopting other Agile project development methodologies that might work better for you than Scrum.
    – nick012000
    Dec 25 '20 at 11:39
  • There are no (formal) subteams in Scrum, but the idea that all the "developers" have identical abilities to address every development issue that arises is obviouusly nonsense. A developer who has specialist knowledge of "BA stuff" (however the OP's organization chooses to define what that is) is no different from a developer who has specialist knowledge of database design, nanotechnology, or anything else.
    – alephzero
    Dec 25 '20 at 15:25
2

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:

  • You can think of them as POs, but most of the time BAs aren't stakeholders
  • If you think of them as Developers - then it would mean they don't work on current Sprint goals - instead they prepare tasks for future Sprints.

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.

6
  • 'instead they prepare tasks for future Sprints'. This is why I used the term 'upfront'. Why do you disagree?
    – Daniel
    Dec 24 '20 at 18:24
  • @Daniel, because 24 tasks isn't a lot of upfront work. You do need upfront work in any case. Even in Scrum you have a PO who's preparing product backlog, refines stuff for the next sprint - that's the upfront work which you can't eliminate. But we certainly don't want to do a lot of it. And some people for some reason associate BAs with a lot of upfront work. Dec 24 '20 at 19:39
  • @StanislavBashkyrtsev I think that's the heart of it. The whole Scrum Team participates in Backlog Refinement, but the Developers are accountable for Sprint Planning (emph. mine): "This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value." scrumguides.org/scrum-guide.html#sprint-planning The point is that the PO owns the Product Backlog ("what"), and the Developers are accountable for "how."
    – Todd A. Jacobs
    Dec 24 '20 at 21:19
  • The goal is to avoid mini-waterfalls and BUFD, and the accountability for typical BA work is spread across the Product Owner and Developers. If the whole Scrum Team isn't participating in design and specification planning, you lose out on the biggest gains Scrum has to offer.
    – Todd A. Jacobs
    Dec 24 '20 at 21:20
  • @ToddA.Jacobs, well "gains" is a relative term. Scrum offers "gains" only when compared to very ineffective teams. It just introduces too much waste. I don't want the whole team to participate in tedious design/specification planning since this can be done (most likely - better and faster) by 1-3 people. I like people to stay focused and they are usually thankful for that. To your 2nd point: Scrum is a mini-waterfall since it has time-based increments. The difference is quantitative, not qualitative. Though Waterfalls can be very different, some of them may differ qualitatively too. Dec 24 '20 at 21:50
0

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

0

Let's take a closer look at the specific "traditional BA responsibilities":

  1. Clarifying bugs/bug requirement analysis: The developers analyse/fix bug tickets created by users because they have the most knowledge about how the system should behave. If you add an additional layer of BA's analysing bug tickets, from my experience it takes them sometimes hours to come up with a clarification that is often not even correct. Because they do not know the codebase. Bugs should be handled by the developers because this way you also leverage the developers' knowledge and creativity. Developers should not be given "coding tasks" but business problems. The same as user-stories should deliver real business value to the customer of the product.
  2. Gathering requirements for user stories/features: The developers work together with the product owner to understand the problems of their customers and come up with creative solutions. Doing customer surveys, prototypes, etc. is more the responsibility of the PO while coming up with solutions for real customer problems or features you evaluated as useful for the customers is more the work of the developers. Also, check out the book Inspired by Marty Cagan which provides great input on how to work within the Scrum framework.

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

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.