It’s simply not enough to slice up business requirements and put them on the backlog for the technical team to build. Unfortunately, this behaviour is only too common for business analysts who don’t understand the technology.
There is a notion within the business analysis profession that analysts should remain firmly focused on the “what” whilst staying completely agnostic of the “how”. As if by getting stuck into the detail, they somehow lose their impartiality (or perhaps authority?)
It’s certainly a comfortable, idealist position to take. And one that I would love to have the luxury to take at times. However, I believe the “what” and “how” separation is often an unhelpful division that can cause real problems.
I’m reminded of the foolishness of completely ignoring the implementation every time a poorly scoped user story gets carried over from sprint to sprint with a daily update of “95% done, nearly there.”
I’m not saying that every story needs to become an implementation specification containing pixel-perfect screen designs, API signatures and database fields. I still want empowered developers to have good conversations.
But what I am saying is that it’s not cool to be a completely “hands-off” business analyst, especially when you work in the field of software development.
It is not okay to have zero practical experience of building software if, at the same time, your software developers look to you for good quality, technically feasible, appropriately sequenced stories.
Everyone can write their own “hello world” application, install docker and run Linux, read some technical books and take online courses. Hell, even ChatGPT will give you high-quality code snippets to compile for anything you can think of.
You don’t need to know precisely how to implement each story, but you should have enough of an understanding of the tech stack and implementation patterns the team uses to inform your work as the business analyst. If nothing else, include the most technically able team member in your own BA work from time to time to sanity-check what you are doing.
If McLaren were looking to hire a business analyst, would they choose the person who tinkers with their petrol go-kart on the weekend, watches Formula 1 and can talk about different fabrication techniques for lightweight composites? Or the other candidate who openly says they aren’t interested in cars but doesn’t believe they need to be to do the job.
Be the analyst who takes a healthy interest in the domain they work in.
Frank Ray Consulting. Software requirements for agile development teams, particularly distributed, remote and offshore development teams working in financial services.
Get in touch if you need our help