A “business analyst” is a difficult role to define. Even the name itself is a bit of a conundrum. In the e-commerce industry, most roles come with a self-explanatory “verb” + “er” style title.
If you develop, you’re a developer. If you design, you’re a designer. If you manage projects, you’re a project manager. So when it comes to a “business analyst,” what’s in a name? It’s a bit murky.
Adding to the confusion, a BA’s role can vary from company to company, even within the field of e-commerce development.
So what do we actually do? Decoding the job from the title isn’t as simple as removing a suffix, but it’s not such a bad thing. In short, we take in business and product requirements and help build out the technical specifications needed to deliver the product.
In practice, BA’s get to wear a few hats, and we like that. We’d also like people to know more about what we’re working on, so here are the main roles of a business analyst at FortyFour.
Requirements are the stars we steer by. Before we can deliver a great product, we have to understand what we’re building and who it’s for. Since it’s the BA’s job is to bridge the gaps between business needs, use cases, and technical requirements, much of our work is gathering and documenting requirements.
Discovery is a team effort for both the client and the agency when it comes to a project, and it is often a lengthy process. Throughout requirements gathering sessions, it’s the BA’s job to define, analyze, validate, and simplify. For the BA, the product of discovery should be detailed documentation that captures functional requirements and allows anyone to grasp the intended future state.
Translator or Liaison
After requirements are written up and approved by the client, it is the business analyst’s job to hand off the requirements to the developers. The business analyst makes sure that the requirements are delivered in a way that the developers will understand through user stories or technical requirements. The developers need to be able to understand all of the requirements and have all of their outstanding questions answered before development begins.
The business analyst should be able to answer most questions, however if the question expands the scope of the business analyst’s knowledge or needs a decisions from the client, then the BA will contact the PM to verify with the client. The business analyst should be able to talk about the technical consequences of the client’s decisions to make sure that they make a informed decision. So as a business analyst it is very important to tailor your speech to make sure that both developers and clients (who are not always tech savvy) know and understand what the current status of the product is.
On maintenance-focused projects, the business analyst role is also to advocate for development time that will not result in front end changes, but will increase efficiency on the back end to make future changes possible. As development progresses, there will be hurdles that may need to extend deadlines or there may be a scope change. As BA’s, it is our job to make sure that the client understands the why behind asking for an extension or asking to prioritize certain tasks over others for the benefit of the product.
To summarize, business analysts act as liaisons between the client and the developers. The requirements that are gathered from the client and translated to user stories for developers. But the BA also translates the technical roadblocks and complexities to the client in a way that the client will understand the risks and manage their expectations.
Since the Business analyst is the liaison between development and the client, the business analyst should also use their knowledge to help the client plan and strategize their efforts with regard to the project. With a business analysts view of the technological roadblocks and risk, we should be able to help manage their effort/outcome ratio to make sure that we are delivering the best product for the state of the project. This includes making sure that certain tasks are finished in a unique order or helping the client prioritize one feature over another.
For example, let’s say a client really wants Feature A more than Feature B. Feature A includes a huge dev effort and a high financial outcome. However, the code infrastructure is not set up correctly, and we would be implementing a patch instead of a true fix. For a true fix to occur, task C and task D need to be completed first. Now Feature B is of moderate dev effort, moderate financial outcome, and we will be implementing a true fix since there is nothing blocking development efforts. At this point it is the business analyst’s job to explain how implementing feature B along with working on task C and task D need to be done before getting started on feature A. Because from a development standpoint, the team will still be accomplishing tasks and hitting milestones, but will be completing it in a way that will be a best for the health of the product.
With this mindset of prioritization, the business analyst can help the client plan for the future. The key is to make the clients think long term.
What do you see the site being able to accomplish within the next quarter?
What kind of user experience are you envisioning?
What features would you like to see within the next few months?
Once the client answers these questions, it is the business analyst’s job to help set up a plan to implement the features the client wants to see and present it in a way where the client will see gradual improvements to the site.
After requirements are gathered and we have agreed on a plan for implementation, the team is ready to begin architecting and building. In this phase of a project, a BA at Forty Four acts as a scrum master, the person holding the team to the Agile process through the project’s progress and evolution. Since we are familiar with the business and technical requirements at this point, we (Karla and I) are well positioned to help build the best product possible.
We try to be Agile at Forty Four (though often our process is a cross between waterfall and Agile methods: wagile), and this means we work in sprints towards short-term milestones while staying responsive to change. Familiarity with the backlog, the platform, and the technical requirements makes the BA a good fit for scrum master–the person who facilitates the process and ensures the team is following Agile practices. In practice, we help manage and prioritize the backlog, lead sprint planning meetings, standup meetings, and sprint retrospectives.
Again, the BA’s role can vary, even from project to project, but the core of the role is stable: we take in requirements, restraints, and risks and help provide solutions.
Karla Fleming and Bryan Zyrbes are both business analysts at FortyFour.