Being a Business Analyst for most of my professional career, I had interaction with developers of different profiles. From the collaboration standpoint, the overall mutual experience and the way we worked together are positive. Even though it happens pretty often that we have different perspectives, that doesn’t lead us to a loss of trust and connection that is crucial in mutual work.
This blog intends to describe how this collaboration usually looks like and to present to developers the approach and way of work from the BA angle.
The post will be divided into three main chapters:
- Ideal BA – developer relationship – this is how things between us would work in an ideal world from both perspectives, what both roles would like another side to be (it is not something you can find in official documents, articles, tutorials, and other relevant documentation, it is something we know, but do not say to each other)
- Real-life BA – developer relationship – chapter based on my previous career experience, our real challenges which can set us apart or bring us closer than we both could imagine
- Conclusion: BA – developer relationship improvements – to avoid the terms “bugs” or “corrections”, I’ll use my favorite word in such cases (you’ll see that in my user stories) – improvements. In other words, the survival manual
Ideal BA – developer relationship
As an intro, in case you need it if you are not sure what a BA role is, check out this great blog written by my colleague Maja Kostić.
Basically, a BA is supposed to be a central point where stakeholders’ requirements are transformed into technical implementation. On the other hand, it requires constant interaction with all relevant parties within the project – stakeholders, PMs, POs, designers, QAs, and developers.
All of them are equally important for successful project implementation, but let’s focus here only on BA <-> developer relationship as cooperation between those roles is usually the crucial one, at least from my perspective. Let’s imagine the following situation – what we expect from each other in an ideal world with super nice stakeholders and projects with no sudden scope changes.
I would say that the ideal BA from a developer’s point of view would be the person with all of these characteristics:
- Writes flawless user stories, covering all edge cases which are briefly explained through AC (Acceptance criteria)
- At the same time, doesn’t write much AC as it can be too much text to read
- Finds no bugs during the occasional test because there are no errors in the code
- Has immediate answers and provides feedback as soon as requested
- In cases of different possible approaches, agrees with the developer unconditionally
- When solutions can require either 2h or 5MD, chooses the first option
- Understands what developers are talking about all the time
- Doesn’t ask about task status unless it is finished, tested, and confirmed
- Doesn’t question estimations and doesn’t expect that estimations will reflect actual time spent on specific tasks
Developers, would you agree? If I were you, I know I would.
On the other hand, from the BAs (or mine, at least) perspective, the perfect developer would have the following qualifications:
- Reads user stories/acceptance criteria before sprint planning and is prepared for the following sprint
- Understands everything on sprint planning, no questions asked
- No questions were asked during the sprint since everything was clear on planning, right?
- If there are discussions required, they are only related to ones to which I (BA) have an immediate response
- Communicates in an understandable manner if there is some tech issue with a task/feature
- Proposes alternative solutions on their own
- Produces codes without bugs
- If there are bugs found (they should not, because of the previous point), they do not disrupt original estimations
- Provides exact estimates which reflect actual state and all tickets are completed by the end of the sprint
From my point of view, this is the perfect acceptance criteria for developers.
Since those 2 worlds cannot function in such a way, let’s see what real-life situations bring us and what obstacles can be found in our everyday work. Let’s analyze chapter 2.
Real BA – developer relationship
OK, by coming this far, we have concluded that the above-mentioned utopia does not exist. What are the reasons? What are the differences and challenges we both need to overcome to get as close as we can to an ideal situation?
First thing I would emphasize as a difference is our mindset.
BAs need to cover a wide area of work, starting from understanding business needs and transforming them to functional requirements, taking care that the whole process makes sense and it can be implemented within a given deadline whereas developers focus more on specific tasks, how to approach them, implementation process and actions they need to undertake in order to meet criteria for specific requirement.
Why is important to communicate
Next thing – communication. Even though I didn’t put it in the first place, I consider it the most important thing. Many things in the process can go wrong from both sides, so BA and developer roles need to be on the same page as much as possible. BAs are used to everyday communication with everyone whereas developers do not need to communicate so much, they have code that communicates instead of them.
However, there are many situations when issues of any kind can appear, when the scope or expectation is suddenly changed, when an estimate is not accurate, when user story misses some AC, etc. Therefore, it is essential to establish communication as soon as possible as it is the fastest way of handling even the most difficult problems. Dear developers, please do not hesitate to communicate all of the issues you run into where you don’t know how to proceed, it is our job to deal with it, either by ourselves or by communicating further with other relevant parties.
Teamwork is the best work
One more thing occurred to me while I was writing this – team members get along. Based on my experience, the beginning of each project is the hardest part. Pretty clever, right? It means that all team members have their backgrounds, previous projects, etc. but at some point, the team needs to “click”.
It is easier to say than to reach it, but this is the point when the team members get to know each other, BA knows what to expect from developers and developers know what is expected of them and what is the actual BA role in the overall process. Even if something goes wrong (and it will don’t worry), both roles know that they can rely on one another.
That being said, we can go to the improvements section. I’ll stress the main points drawn from all of these facts I mentioned before and summarize them.
Conclusion: BA – developer relationship improvements
There is no Q project without a BA and developer, that is it, deal with it. We have to work together unless you want to cover my responsibilities to discuss and write all day long. Besides giving tasks and asking for estimates and statuses, BAs are a central place where all project-relevant information can be found. If not, well, it is again BAs responsibility, not yours 
If you ask me, I really enjoy working with developers, since you transform my words into functionality, it takes much more than coding, it is understanding what I meant/wrote and putting it as a functional process. I consider it like some kind of magic.
In conclusion, I’ll highlight the following keywords – mutual understanding, communication, cooperation, and coordination. These are essentials and it goes in both directions, from BA to dev and vice versa. We are not here to compete over who has the higher and more important role in the process, but to work together, each of us in our areas of expertise and that is the ultimate way of reaching the goal – successful project completion.
