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?

Todd A. Jacobs
  • 50,264
  • 7
  • 59
  • 177
Daniel
  • 2,729
  • 13
  • 36
  • 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
  • When I think of a business analyst's role, I don't see any implication of a "waterfall-ish or upfront-design approach", which is why it's essential that you need to define what the "traditional BA responsibilities" are and what "the business analyst's work" is. – Thomas Owens Dec 24 '20 at 20:00
  • @ThomasOwens For example, in a complex field, like fintech or banking, before the developers can take a task in development the task must be clearly decomposed, clearly defined and this is what often BA does BEFORE the Sprint Planning Meeting - BA works ahead of the developers. This is what mean by 'waterfall-ish'. The BA and the developer DO NOT work on the same tasks during a Sprint. – Daniel Dec 24 '20 at 20:10
  • Having a clear decomposition of work and clear units of work are common in many industries and I'd consider it a good practice. In Scrum, this is always done before Sprint Planning in refinement activities as a collaboration between the Product Owner and Developers. None of what you describe is, at all, "waterfall-ish". – Thomas Owens Dec 24 '20 at 20:55
  • @ThomasOwens It's the underlying assumption that Developers are downstream of business analysis, rather than active collaborators in the process, that I'm struggling to convey here. That's the "waterfall-ish" part he's referring to. – Todd A. Jacobs Dec 24 '20 at 21:23
  • @ToddA.Jacobs, such terminology is a bit confusing. It's more of "everyone-else-ish", not "waterfall-ish" :) Only Scrum insists on having meetings (including refinements) with the whole team. The rest of methodologies don't seem to care about this as much. – Stanislav Bashkyrtsev Dec 24 '20 at 21:58
  • @StanislavBashkyrtsev You see similar events in DSDM, although there are more roles so you may not have all roles in a single event depending on how your roles break down. Extreme Programming also has the whole-team concept. So it's not only Scrum. This is expressed in the Agile Manifesto: Business people and developers must work together daily throughout the project. The extent and frequency of different roles collaborating does depend on the specific methodology. – Thomas Owens Dec 25 '20 at 00:19
  • 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 07:22
  • @Erik Could you please share your team's workflow? What is the Definition of Ready for your User Stories and Tasks which aren't event clearly defined? – Daniel Dec 25 '20 at 17:04
  • Our definition of ready is more or less "We have a decent idea of what problem you have and roughly how we'd fix it". Most User Stories that go into the sprint have about 5 lines of problem statement and have been discussed with the team for half an hour. That's enough to know if we can resolve the problem within a sprint or not, From there, we work closely with the PO to resolve that problem. That usually means discussing with our BA-type on possible solutions, whipping up a prototype, and then showing it to the PO as we build it. – Erik Dec 25 '20 at 19:31
  • If the PO thinks it's going in the right direction, we build it out for real and then usually the PO tests the feature themselves in some real life scenarios, or they get a stakeholder to do it. Sometimes we pull one of the PO's stakeholders into the sprint more directly and work with them to build the thing with real data with them in the room (or digital room, given the circumstances). If we're working with a 3rd party team, we try to keep them on standby while we work. Generally between their domain knowledge and understanding of the problem, we can work without any kind of formal documents – Erik Dec 25 '20 at 19:34

5 Answers5

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.

Daniel
  • 16,867
  • 2
  • 21
  • 49
  • 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." https://www.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
  • @nik012000 - absolutely! And I also point teams at Kanban, which isn't really a methodology at all, but an approach to tune your methodology in whichever way you want. – Daniel Dec 25 '20 at 15:40
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.

Stanislav Bashkyrtsev
  • 1,046
  • 5
  • 10
  • '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. – Stanislav Bashkyrtsev 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." https://www.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. – Stanislav Bashkyrtsev Dec 24 '20 at 21:50
  • @ToddA.Jacobs What is that biggest gain? Can you provide an example from practice? – Daniel Dec 25 '20 at 17:30
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.

Barnaby Golden
  • 19,475
  • 3
  • 17
  • 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).

Iain9688
  • 6,858
  • 4
  • 23
  • 50
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".

Simon van Endern
  • 11
  • 1