What [the hell] does a BA do?

I get asked this question a lot. Mostly from non-ThoughtWorkers - friends, family, potential ThoughtWorkers I’m interviewing, new clients, and the like. Here’s my attempt to answer the question as inspired by the subreddit “Explain Like I’m 5”.

Sometimes I think the real description for my job title should be "monkey in the middle."

At a high level, a business analyst at ThoughtWorks serves as the liaison between the product owner and the rest of the team (mostly testers and developers) who are building the product. Now that’s vague...really vague. So let’s use an analogy. Imagine that a building is being planned. An architect has the vision and domain expertise for what the building should look like. He or she puts that in a blueprint, which when finished, is passed onto construction workers to actually build the damn thing.

Following me so far? Good, because here’s where my analogy starts to fall apart. You see, software is hard to build in just one blueprint (that’s what we at ThoughtWorks refer to as waterfall development. We’re not big fans of it). Object models and test suites are often more fickle and volatile than good old brick and mortar. As a result of code constantly evolving and changing, there’s lots of STUFF that can get very lost in translation along the way. That’s where BAs like myself come in. We are responsible for minimizing that STUFF. We do so by capturing bite-sized blueprints for one piece of functionality at a time. We call these small blueprints “user stories.” Itty-bitty blueprints are advantageous over one huge ass document because a.) we write them for the very near future, so big changes that happen do not result in a buttload of lost work and b.) we shorten the feedback loop with our customer by developing in small bites. There are c.)’s and d.)’s that I could go on and on about, but that’s for another post.

So, a business analyst’s job is to make these bite-sized stories. In doing so we must work very closely with the product owner, or the visionary, and we’re also in constant communication with the development and testing team. A business analyst thrives in that dichotomy between the panned out, high level, hallelujah! vision of the application and the zoomed-in nitty-gritty of what data needs to be displayed in what div after what click. It’s a role that frequently overlaps with those of Project Managers, Experience Designers, Product Owners, and Testers. Sometimes I feel like my brain is a revolving spice rack in a kitchen of many cooks - during one conversation, my knowledge about X and Y might be brought out to the counter, but as soon as I turn around they will get replaced and instead I’ll need to pull out some M and N instead.

You’re probably thinking, “Ok, all of this is nice. But what do you actually do on a day-to-day basis?” The answer, as many ThoughtWorksian answers end up being, is “It depends.” It depends on the project, on the team, on the client, on the time within the iteration, and on what impending crisis our team is facing (just kidding! Mostly). My first experience as a BA was completely different from what I did on my second project - and not completely out of ineptness, I’d like to add. The role just changes. *shrug*

I can however, answer that question in the context of my current project. I probably spend 75% of my time in the team space. A lot of that consists of talking to the tech lead and product owner about requirements - soliciting them, nitpicking at them, trying to figure out how to frame them smartly and capture them in right-sized portions. A lot of other times I am working with developers and testers - playing with new functionality on their local machines, estimating new stories, or doing kick-offs on existing ones that are about to get picked up. And of course there’s the time spent at my desk actually writing the stories. For this project I am using a tool called Rally to write stories and my favorite med-fi wireframing tool, Balsamiq, for pretty pictures and diagrams.

What I look like when I'm writing a user story.

As for the 25% of the time when I’m not in our team space, it’s usually in a meeting of some sort. Most of these meetings are good/productive, like our check-ins with users and community BA meet-ups. For the few where I don’t get a lot out of the meeting or do not contribute much to them, I make an effort to un-invite myself. Based on what previous experience has taught me, the longer you are on a team, especially in a BA or Product Owner capacity, the more meetings you will gradually be invited to or expected to attend as a representative of your team or application. It’s dangerous to fall into this rut of what an colleague once joked as “MDD” - meeting driven development. Therefore it’s important to turn a scrutinizing eye to new meeting invitations. Ask yourself: do I really really really need to be there? Is this the best use of my time? Will the world end if I don’t? If the answer is no to all of the above, skip it. Politely make yourself available for answering questions afterwards and then decline the invitation. It feels like a small miracle every time that happens, but it really shouldn’t.

No truer words to live by than these. Source: Zazzle

I like being a BA - I really do. I have my bad days and my good days, just as all jobs do. But on the whole I find it rewarding and challenging. It lines up well with my skillsets and interests. It’s also a great gateway role into other ones; as a BA you get to get a taste for so many flavors for the type of work that needs to come together to create working software.

It’s hard to believe that my three-year review at ThoughtWorks is coming up and that I’ve been in this BA gig for three years. At this point I definitely feel that I have a strong “BA arsenal” of tools and experiences that I can bring to new project teams, whatever they may need of me. But I also relish the feeling of being a complete noob to the domain and technology whenever I show up on the first day of a project. The challenge is accepted - always!