Whether you call them business analysts, requirements engineers or proxy product owners, this material is about the person who knows and understands the project functionality best, and who, in one way or another, is in charge of the specs. Moreover, this material highlights how a project could benefit, at full potential, from having this kind of person on board.
Whether it is writing requirements from scratch, reformulating, summarizing or clarifying them or it is just managing their changes, this person does it all, and can do much more, the very things that will be detailed throughout this article. For easier reference, let us call him the BA, even if, depending on the project context, this work might be done by other roles (e.g. a tester).
This is the person the client is comfortable talking to, the PM is comfortable delegating to, the tester is comfortable asking questions to,the developer is comfortable explaining technical complexity to and the UX designer might stand a chance in convincing when nobody understands why a navigation tab is better than a list one. It is quite a challenge to get somebody to understand all those people, right? Still, how many of those who have a BA on board think they are using that person's skills the right way?
From my experience so far, I have learnt that BA skills are more than a bunch of written or oral communication competencies, and much more than the curiosity of understanding functionality. Also, most of the times, the persons doing the BA work are doing more than that.
They are making the difference between delivering business value and delivering working code, they are juggling with interests from all stakeholders, trying to keep them happy and manage expectations. At the cost of always getting someone upset, BA people are keeping things together at overview level, so that, when everybody else forgets or begins tearing things apart, the project components can be prioritized in meticulous plans that could ensure getting the most for the money spent by the customer. BA people can still find the time and willingness to take a dive into more technical aspects and learn how to understand development better.
Many projects are reluctant to having a BA on board from fear of giving too much power to the customer. In turn, this makes communication in the team more difficult or adds unneeded complexity to the delivered functionality. What people are not considering is the real value a good BA, namely the benefits these persons can bring to the development team and their projects.
Here are 7 things to start with, which good BAs can do for your project if you trust them:
Translate requirements
Although we might think we are speaking the same language, we are not.
Due the different roles we fulfill, we speak tech at different proficiency, which makes it hard for the development to understand the same business requirement at 100% proficiency.
The BA knows what knowledge level each role has and can usually "translate" the requirements for all proficiency levels, so that proper understanding is ensured.
Keep things together
There are many stakeholders in each project and all of them want at least one slice of that tasty pie you are delivering. While trying to get it, each stakeholder keeps focus on the desired outcome and, most times, forgets the big picture.
Here is where you BA comes in, to put the puzzle pieces together while looking at how the end picture should be like. The BA can signal any size- or complexity-related deviations, as the BA can also spot the parts that do not belong or do not fit.
Empower the development team
Many of our customers think that giving exact technical details on how something should be implemented helps in bridging the gap between what was requested and what development is delivering. This, however, is not quite true. No developer wants to be a blind follower of explicit demands when developing code. People want to make choices, to have a chance of being better than others, to create, to learn and play around with challenging tasks until an outcome they can sign off as their own is delivered and they can take responsibility for it heart on. Furthermore, when people are specialized in certain tasks, it is wise to let them do their job as they know best or consider fit. It is like when you go to a doctor and you rely on their knowledge and experience for correct diagnosis and treatment. The same should apply to developers who implement a software solution.
A smart BA can make sure the requirements are specified in a way that explains the needed functionality without getting into the technical details of it, thus leaving room for development to be motivated and creative when developing the technical solution.
Know your team's needs and make sure they are understood by the customer
To the surprise of many, it is not always enough for development to have a nice summary and some designs of how a feature should look like in order to develop it. Things can take a wrong turn once somebody starts challenging the estimates provided for it.
People need to know you have thought things through, anticipated milestones, foresaw the impact and tried to understand the complexity of the things you are demanding, before placing them on their plate. It is a tacit sign of respect towards their work if you make things as clear as possible and if you trust their estimates.
When regular communication fails to send this message to the customer, your BA can filter the message, so that development does development and development only. The BA can fill in the missing details, discuss proposals with the team, go back and forth to the customer, make the customer aware of the readiness state, ask, clarify and update specifications until things are clear enough to work on and complexity becomes so obvious that nobody would consider challenging the estimates.
The BAs can even take one extra step and ask to have a glimpse in the customer's crystal ball, so that they are able to tell the team what the most likely course of action will be, so that the team stay committed and motivated to do their work.
Know the customer needs and make sure they are understood by the team
There are many cases when a long project results from the fact that the team does not understand why a certain feature is needed in a certain way. Not having somebody who can explain why the feature is needed might lead to the team not having faith in the product they are building. In addition, the team might be doubtful with regards to the capabilities of the people working on the customer side. In the long run, this attitude will become harmful to both the project and the product. Instead of collaborating with the customer, as one team, a silent war against the customer will be started.
By getting to know what the customer needs thoroughly, and what their inner drive consists of, BAs can provide sound arguments to the team, arguments that convinces the development team that the customers know what and why they are doing a particular thing. The BA does not have to reveal all nooks and crannies. Instead, the BA must provide just the right amount of information to keep collaboration on the right track.
Let your customer know your team has alternatives they should consider
When some requests might seem unsound or unrealistic, you do not want to tell your customer you cannot or will not do something about those requests.
Your BA is the person who can get the feedback from development, filter out the unconstructive parts, prepare better alternatives with the team and then go back to the customer and change what could be a discouraging "no" into a "yes, and here is how we suggest doing it".
Keep the focus on delivering value
When planning a backlog or the features to be delivered at each sprint, many times, the end value of the items in scope gets lost due to size-related problems.
You get a list of things added by the product owner, all having the same priority. Next, you start placing things in the sprint, considering pace and available capabilities. The sprint grows full at a point. This is the moment you should ask your BA to join the crowd.
The BA could take the proposed goal further, so that it brings more business value for the same effort. At this stage, the BA may provide a more efficient roadmap planning and may make the customer happy with the progress, while still giving you time to ensure proper delivery quality.
In the end, your BA should be your main ally in delivering a successful project, while the team should be kept uninterrupted, so that it may focus on the quality of their work.
The BAS could be your friend in succeeding and the enemy of failing, as there is one thing the BA should always care about: truly contributing to your customer's success through what you are delivering.
So are you using that person's skills the right way? Are you enjoying the benefits that person can bring to your project or are you wondering how to get them?
If so, then your starting point is to get a good BA on board of your development team and trust them.
By trust, I refer to truly give them the freedom to change things, to be creative, to ask the uncomfortable questions and to get the relevant answers, to find the real need behind each request and to turn it into a valuable delivery, by arguing for it in the team and by presenting it to your customer the right way.
Allow your BA to be that "common language" you are searching for when communicating to your customer and the benefits will follow soon. Here is one takeaway: an engaged customer with whom you can work as a team.
by Vlad Ciurca
by Marius Span
by Octav Florescu , Vlad Tamaș
