15 tips for a Junior Business Analyst
Hello dear Medium audience!
I’m a BA with 8+ years of experience. And for the past few years I coached a few junior BAs. Really enjoyed it! Especially I liked that not only they learned from me, but I learned from them as well. One of these BAs told me that I not only taught them new things or helped them to better understand the already learned but that I helped them to find inner peace and helped to understand that they’re not the only one who faces problems. So in some way my coaching was a therapy for them. That inspired me to write this article.
The listed below tips are based on my personal experience, treat it as a source of inspiration. I have only one goal — to encourage junior BAs.
- Don’t be afraid.
Really don’t be. It’s OK not to know everything. It’s OK to make mistakes. Though it’s better no to do them but still, no one is perfect.
Once the BA, whose course I attended to get the certification, told us — the worst, you’ll ruin the project but as a result you’ll get an experience. Sounds terrifying. Right? However, don’t be discouraged. It’s not that easy to ruin the whole project.
2. Ask! There are no stupid or irrelevant/inappropriate questions. Only the questions that hadn’t been asked. Remember that managers, developers, QAs and even the client are all your partners. Make it work. Ask them everything you don’t know. However, be mindful, organized and respect other people’s time. Tips:
- Whether you’ll choose to ask the questions via email, messenger or through the meeting — make sure that you don’t disturb the person from their work and tasks
- Try to keep a positive attitude. Even when your partners behave hostile towards you or ignore you, try to be persistent and smile. In most cases they are not against you as a person. It’s just that they have their own problems, tasks and worries
- Ask different types of questions: context-free questions, open-ended questions, closed questions, multiple choice questions, compound questions, leading questions, why-questions
3. Learn about the domain of your client — Crunchbase, LinkedIn, Facebook, etc. Find information where you can. Play a spy.
4. Keep records of your team members, stakeholders, clients. It will help to build proper communication with them. Example: create a table which will include — Name, Job title, Role on the project, Background info, Communications. Think about how close you should communicate with them and how often. To define this you can use R.A.C.I. approach.
5. Don’t write requirements in isolation. You’re not a developer, you don’t own the business, and you may lack domain knowledge. However, you have people with whom you could collaborate (yes, the partners mentioned above — #2) to make sure that you collected/documented all the necessary requirements. Collaborate until you reach shared understanding, then document.
6. Don’t rush to document the requirements at the very beginning. Instead of starting to document the requirements, try to collect as much information as you can. Use different elicitation and analysis techniques that facilitate dialog — diagrams, mockups, visual models, matrices and brainstorm meetings.
BTW, all the outputs from the elicitation phase can be later used in your user stories as supportive material or additional information.
7. Create your inventory — collect your templates, documents, diagrams. Remember to collect only the best example from your experience and only in one copy.
It’s even better to create a generic template which you could update to use on any project. For instance, I have a generic template for the user story which I update depending on the project and team needs. It will really save your time.
8. Create your checklist for a project — think about what tasks/documents are a must for any project. That checklist could include the list of tasks or the list of documents.
While creating this list pay attention to the project phase. Different phases of the project need different documents/artifacts. For example, the project conception and initiation phase doesn’t need fully detailed user stories but it needs to have documented project vision.
9. Learn how to write emails, facilitate meetings, hold demos — books, articles, learning platforms (Udemy, Coursera).
10. Learn how to estimate your work. It would help you to plan your activities. Start with writing down the planned time on the task and then check how much time you spent in reality. Pay attention to whether you did this task alone or you depended on someone else (i.e., design).
11. Read a lot! Find the resources that will help you to keep up with the industry news. And of course read books. Books can help you to gain experience without making your own mistakes.
12. Don’t hesitate to suggest ideas/practices that you think could improve the process or will benefit the project. Tips:
- If you have an idea how to improve the development process for the whole team, discuss it with the PM and only then suggest it to the team. Of course, if your team culture allows you to share the ideas freely, then just share it with everyone on retro or after the scrum
- Before changing anything in the way you document/present the requirements try to understand what exactly the current way of document/present the requirements is lacking. Talk to the team and the client(s)
13. Be creative! Learn not only about business analyses but about project management, user experience or software architecture. Even though it’s not directly related to you right now, it would definitely help you in the future.
And as a bonus you can use best practices from any other roles — QA, PM, UI/UX. Examples:
- UX — not every project has a UX person but knowing that personas, empathy map or user journey map could add more value to the project understanding you could create them and introduce to the team and stakeholders
- QA — checking QA document, understanding on what they wrote in the acceptance testing, check list or use cases will help you to understand what details your requirements are lacking
- PM — understanding on how the project is being managed will help you to understand your own place within the team
14. Collect feedback on your work — performance, documentation, communication, etc. It will help you to find the area for improvement (both — project improvements and personal improvements) and you could use this data on your salary review.
Just select what metrics are important for you and collect the data. Surveys, emails, messages, meetings — you choose how to collect the feedback. Don’t forget on what I mentioned in #2. And if you choose to go with a survey, make it anonymous. It will allow respondents to be more honest with their feedback.
15. Challenge yourself. Take each and every opportunity you have. Even if you think that the project is too difficult for you or you’re lacking knowledge/experience. Just dive into this new ocean and row with all your strength. The worth result, you’ll just waste your time but the best — you’ll level up your career
The list could be endless. I decided to narrow it down to 15. Hope that these tips are useful.
P.S: dear junior BAs, every time you face the problem, remember — you’re not alone and as long as you want to learn you’ll find a way to do so. Just treat your failures and mistakes as experience that will help you to build a successful BA career.
