Have you ever joined a new project as a Business Analyst (BA) and have straightaway heard something along the following…
“can you write us some user stories”
“we have requirements we just need some stories and epics”
“our backlog is non-existent can you quickly create some stories in it”
“you’re BA can you write us some stories and epics”
and so on…
This is usually the welcome that a lot of new business analysts receive on a brand-new project/team/product-team. We would never ask a new incoming architect to quickly draw up some technical designs, would we? So why should this be any different for a BA?
BAs are expected to hit the ground running — this I understand as a reasonable ask. However, the goal of a BA is not to just ‘write user stories’. They will not be a very good BA if all they can do is write user-stories or epics in a RMT.
The ‘goal’ is to:
1. Understand how the current world works
This is the key step that requires understanding:
Why was the new product or service or piece work sponsored in the first place?
What are its goals or benefits that it needs to deliver?
Who will use this new product or service?
How do the users use the product or service today?
What pain-points they face and how they overcome these pain-points today?
The processes and touch-points in their current journey and how long these things different steps take
What is the wider industry, market or competitors are doing?
Not all of these will be carried out by a BA, but they will need to understand the outcomes thoroughly.
2. Understand why and how the current world needs changing
A BA needs to collaborate with multiple capabilities to define “how” these user-needs and pain-points can be addressed. This usually consists of various user-design, user-research or architecture design workshops and discussions. The outcome of this will be a lot of things — future user journeys, design decisions, non-functional agreements, high-level epics/ themes, skeleton user stories and a plan for on-going research or design.
3. Create a backlog that the developers and business can understand and follow
Creating a backlog does not just mean writing user stories. It requires you to engage with multiple capabilities and teams (such as designers, content, legal, marketing, architects, sponsors etc.) to create all the necessary artefacts that makes a story complete. Here again, you will see a good BA working on whiteboards/virtual whiteboards to draw up and understand the big picture that needs development, cross-referencing to user-needs, questioning and understanding the future design and negotiating the scope with various capabilities.
4. Manage the backlog on an ongoing basis
This is probably the most important part of the BA’s role. Managing the backlog on an ongoing basis requires the BA to carry out steps 1 to 4 (above) on a continuous basis. Depending on the nature of the product or service, the BA will also be managing and prioritising bugs, defects in prod, spikes and tasks on a continuous basis.
User stories are a just way of compiling our notes into something the developers and team can complete in single sprint. One of the underlying reasons for why a BA gets asked to just write user stories as soon as they arrive on a new team is because — a lot of the teams and projects are still designed to operate in a ‘wagile’ format. Designers, business analysts and architects are operating in a ‘waterfall’ format whereas the developers are following a 2week sprints. But this is a whole another discussion and warrants another post.
