• Nnenna

Software Development: What to do as a BA

Updated: Nov 15, 2020

Its one thing to learn the BA tools and techniques, but its another to apply those tools and techniques appropriately. As a BA, I’ve curated a list of actions below, which I would take if I was asked to work on a mobile app development project/product.

1) Have a chat with the person in charge of the project (PM, DM, PM...hopefully not a Tech Lead):

I would formally introduce myself and share that the aim of the interview is to understand their expectations of me, get to know what their outcomes are for the project/product, and get a list of people involved. (There are more things you should know before this, read this to find out). With the stakeholder list, I would build a Stakeholder management tool that contains their influence (RACI), Power score, Interest Score, Communication method (skype or emails), available times, job title, Techy/Bizy... virtually, all I need to know to ensure efficient stakeholder management.

This document will help me avoid/manage conflicts, and to gauge how technical/business-ey the stakeholders are (the last thing I want is to send a VSM to an Accountant for confirmation). Finally, it would allow me to know who to chase, for buy-in (if push comes to shove).

2) Meet my stakeholders:

When I am done with the PM, I would send out an email to everyone and formally introduce myself to them, telling them the scope of my duties and encouraging them to stop by my desk if they need anything.

Like thus:

Hi Dearest Stakeholders,

I am Nnenna, the BA on this mobile app project. My job is to make your dreams come true—provided it aligns with the business objectives that is, because I can’t pay for a holiday for all of you as that doesn’t align with the vision of this product.

On this project, I will liaise with everyone of you to understand your expected outcome/desires for this app, so feel free to text me at 2am about a goal you would like to achieve with this app or a goal that you would like the users to achieve with this app. We are in this together!

Stop by at my desk anytime for a chat.


Your fairy godmother.

3) Collate all the dream goals:

I would create a spreadsheet and attach each goal to the sender's name (great for follow-ups, if I have more questions). For instance, if the mobile app is a Bank app, I would get goals like “check my bank account”, “transfer money”, “get cool Naira exchange rates” (impossible! But don’t say this to your stakeholder. Please. Let’s not burn bridges this early). While I collate goals from the users, I would perform research on competitors to know their users' goals (benchmark analysis) and include what I find in the list of goals.

4) Schedule a brainstorming session:

Now that the goals have been streamlined and I have a set number of goals to work with, I would get everyone into a room and showcase the goals that I have collated, using sticky notes. The discussion would be to encourage them to speak out or remove the post-its they don’t agree with. When I have enough to work with, I would ask them to explain why they feel those goals will be important to the users (now I have the justification for my user stories). Finally, I would ask them to prioritise what they feel is important. I would also contribute, guide and play games like Buy-a-feature, Personas, JTBD, after which I would ask them to prioritise the requirements using Moscow/Kano model (aim should be to identify the MVP). These discussions wouldn't be concluded within a single session, it could carry on for up to 3-4 sessions over the course of two weeks, all in a bid to achieve the goals (goals = requirements). Examples are:

  • The app shall allow the user to view their recent transactions.

  • The app shall allow the user to make bank transfers.

When I get my Moscow scorings, I will convert the “shall” to the agreed Moscow rating (must, should, etc). If there are any problems identified and I need to drill down, I would use techniques like the Fishbone.

5) Now I have a priority but:

The Tech Lead and Product Manager are at loggerheads. I would find out why, try to resolve it, encourage them to meet halfway. If they are still at loggerheads, that would give me, the BA, the veto to decide on behalf of the business (because my priority is always the Business first and foremost, and I must protect it before anyone or anything). I would then decide and inform them of my decision and how it positively impacts the business. To further solidify my points, I would throw in some data to support me (data never lies), perform risk analysis on their perspectives and mine, and show them how mine is better. That should resolve the issue **evil grin** (the same applies if I buy into the idea of one as opposed the other, in the case where it’s effective for the business).

6) Cost & Benefit:

A good product must satisfy the business and its users. So I would use a RICE rating to gauge the impact of the app on its users, and a Benefit Matrix to gauge the benefit to the business (I will write more about this in another article). I would also perform Environment Analysis (SWOT & PESTLE), to identify risks and constraints that might negatively impact the app. While this is going on, the Dev team would be estimating the Cost & Time of making the MVP and any services (APIs) they would need. By the time I’m done analysing the benefits to the business and its users, I would have the estimates from the Devs, further questions and instructions/constraints. I would also ask the Devs for any Non-Functional Requirements (NFRs) they would like the stakeholders to decide on.

PS: Unless I or the stakeholders explicitly request for a particular NFR, the basic NFRs that the Devs create is more than enough. If this has not been documented, I could liaise with the Tech Lead or other SMEs to identify the commonly accepted NFRs in the department, and document this for future reference.

Example: I may have noticed that my competitors apps are slower on Sundays or that the competitors apps don’t work with Canon printers. Due to this, in my requirements doc, under the NFR section, I would document that the app must be available 24/7 with prior notice to users before down-time or that the app must be interoperable with all printers.

7) Analyse, Communicate and get sign off:

I would compile the following into one document: The requirements, the MVP (a Use-case Diagram for the Devs or a List of requirements for the non technical people), the Cost, the perceived Benefits, the risks and constraints. I would communicate this document to the team (PM, PM or DM) and ask them to add anything that might have been left out or setup a workshop to collate their feedback concerning the doc. If they are ok with it, I would analyse this document and make a recommendation on whether it is worth the investment or not. Subsequently, I would communicate the good news to all stakeholders, then schedule a workshop where I would explain the high-level information and get them to agree to begin development. This is my sign off.

8) Story Writing:

I would convert each of the requirements to SMART/INVEST user stories and acceptance criteria. (1 requirement can be equal to 4 user stories). These are so important to the Devs or Testers as it guides and directs them on your behalf.

A user story consists of : The user + the goal + the justification (read more about user stories here).

An acceptance criteria is just a list of testable restrictions/features/functionalities that the app must have or must not have. An example is: Display a list of addresses to enable the user to select their address.

I will write more about user stories and rule-based acceptance criteria in the future.

9) Go on vacation!

If there is a PO, I would hand these over to the PO for further prioritisation and fine-tuning with the Dev team and go on a much needed vacay (I wish!). If there's no PO, I would work directly with the Devs, to prioritise and fine-tune the stories and ensure that they understand what I want. During this stage of development and testing, I would tick off each goal on my requirements doc that has been created by the Devs until all my requirements have been met. At this point, the app may be ready for release. I would communicate the ticked/passed requirements to all stakeholders, and set up a meeting to let them see the demo of the new app. We would share what we learned so far. Then launch and look out for feedback/change requests that can improve the MVP.

For this explanation, I mixed the role of a Strategic BA (environment analysis) and an operational BA (User Stories) and tried to keep things short by highlighting what I think is important in creating a new app. A different approach will be used if this was to improve an existing app/process (E.g. gap analysis), and I will cover that in the future. Please share your contrary opinions and questions.

#fairygodmother #businessAnalysis #softwareDevelopment


Recent Posts

See All