What does a Business Analyst do?
I’m Lee, and I’m a Product Consultant, or Business Analyst at Kainos. I work with our Digital Services division, working on high profile digital transformation projects. We’re professional, agile and creative, providing award-winning IT services, consulting and software.
Now that you know who Kainos is and what they do, I’ll try and explain what I do… a question I get asked daily by my friends and family! I could pitch the whole, “it’s the bridge between the business and IT” and whilst that is broadly true, it doesn’t fully resonate the type of work carried out or the importance it holds in project delivery.
Unlike a traditional Business Analyst (BA), who would have gone into a business months in advance to build a business case and requirements spec, the modern BA has a much broader skill set. Think of a Product Manager meets a Business Analyst and presto, you have the ‘modern’ BA.
Think of us as your ‘interpreters’…
A BA is the eyes and ears of the business – think of them as an interpreter. They possess the ability to ingest one language (the business) and decipher it into another (functional requirements), albeit in a much grander scale and with slightly more risk.
What does the “eyes and ears” of a business mean? You embed yourself with the client, and begin to develop an understanding of their processes and start to identify bottlenecks and inefficiencies. You take these issues and begin to understand what the business and user needs are.
Now that we know what the issues are, what is the solution? At this point we can begin working with the Product Managers/Owners to build out a roadmap of epics, prioritising those that deliver the most value upfront. Once that has been fleshed out, we start to split these epics into a format that is easily consumable by the team i.e. User Stories.
We know the features and epics we are going to be working on, awesome! BUT: how do we ensure we are building the right ‘thing’ for our client, delivering the most value for the user all while keeping costs to a minimum? By working collaboratively and through regular feedback sessions with stakeholders, it helps us ensure we are all working towards the same end goal.
We usually start at the whiteboard and being to draw out possible user journeys, drawing (excuse the pun) on inspiration from research, design and our customers subject matter experts (SME’s). Whilst these sessions are normally small, it is not unfamiliar for these to include the wider team i.e. product manager/owner (often client side), technical architect, content designer and developers.
The goal for the BA, is to feed the delivery team by creating a backlog of requirements / stories that can be picked up at the beginning of each sprint. Sounds easy, right? No. How do we get here? The BA should work closely with both the scrum team and stakeholders to create high-levels stories ensuring there is shared understanding for what we are building. We can always rework these stories going forward once we know more about them.
From stories to end users
Great, we have a journey and some high-level stories, what now? Using the designs, or in some cases prototypes, the UR team take these out for testing to validate both assumptions and designs with the end users. These activities help us understand what works well for them, what doesn’t and what could be done to improve the product.
These recommendations get collated and fed back to both the Product Manager/Owner and BA at which point they are used to either tinker, or completely re-write the stories that were initially created. The two work in tandem to define what the Minimal Viable Product is (MVP) looks like. Once defined, designs are iterated on and, in an ideal world, the product goes back out for a further round of testing. Once the stories are ‘ready’, they are prioritised by the Scrum Team before being factored into the Sprint. Given time sensitivity, stories sometimes only get one round of testing before being developed but, that’s not to say further iterations can’t happen later in the product cycle.
The BA meets regularly with the development team to carry out various ‘ceremonies’ such as refinement (i.e. looking at stories a few sprints down in the backlog to better understand the requirements and being to identify any constraints or outstanding questions,) and sprint planning, (looking specifically at the stories coming up in the next sprint). We frequently use Slack/Skype for offline conversations, have impromptu catch-ups in person, not forgetting our daily stand-ups, which we use to identify work in progress and outline any blockers or impediments the team are facing.
I’m going to quote my colleague Alison Coote’s earlier blog post, “I’m not going to lie, there is going to be travel required and it is likely to be 3–4 days on site with the client”. You may think working away isn’t for you BUT, you get to work with amazing people, gain exposure to some high-profile projects, visit somewhere new, and develop a range of skills you wouldn’t pick up anywhere else.
To name but a few:
Hopefully, you’re now intrigued. Get in touch with our recruiters today, we’re looking for BAs and Product Consultants around the UK.
View vacancies here. The Case Studies Colour is:
Sign up to the Kainos newsletter