Interview questions for an Agile Business Analyst
A friend recently asked me if I had any good interview questions for a business analyst position in an agile team, so I thought I’d write about it.
When I interview an analyst there are a few key things I’m looking to probe:
What methodologies are they comfortable with? What do they think are the pros and cons of agile vs say waterfall, which do they prefer and why? Astonishing as it may seem there are people out there who are better suited to working in a waterfall way, and they’re likely not the best fit for an agile role.
What level of agile experience and knowledge do they have? There are plenty of companies out there who think they’re doing agile but aren’t really. A good way to tease this out is to ask a few basic questions about how the teams they’ve worked on before function. What’s their iteration length? What sort of planning process do they use? If someone gives vague answers to this it suggests they don’t really know agile - saying their iterations are three months long or ‘vary according to the piece of work’ would be classic gotchas. There’s nothing necessarily wrong with being inexperienced, but it helps to know.
Are they just a documentation monkey? For me a lot of traditional analysts are just glorified typists - people who write a lot of stuff down without much understanding and who don’t supply a lot of ideas. You can often figure this out by asking about how they work with other team members. Have they had the common experience of working with a Product Owner who wasn’t very available or great at detail? How did they handle with it? If they make whiny statements about ‘unclear requirements’ or ‘“the business” couldn’t make up their mind’ it’s an instant red flag. It’s an analyst’s job to deal with this. Similarly how do they feel about a constant stream of developers and QAs arriving at their desk? If their answers imply that they find this a problem or distraction from the important business of documenting then that’s another huge red flag - this is not a distraction from the job this IS the job, indeed for me it’s often the most enjoyable part.
What level of business awareness do they have? This is easy - ask them to describe how their current or former employer makes money, what markets they are in. You’d think every employee knows that - but many don’t.
What kind of tech skills do they have? It isn’t always necessary for an analyst to be very techy, it depends on the particular role. But again asking about their current situation is a handy gauge - if they know what their current tech stack is and can maybe draw the odd diagram to show how the pieces fit together then that’s encouraging. Some amateur dev skills in HTML, CSS, PHP or whatever may be a bonus.
What else do they bring to the table? It’s not unusual that people are looking for analysts to double up as para-project managers, or perhaps UX designers. If that’s what you are looking for then ask about it. I’ve covered both those roles in the past, neither with particular distinction.
What are their written communication skills like? This is the one and only thing that you might want to apply some sort of test to find out. Asking them to write a simple story for a commonly understood feature like ‘forgotten password’ might do it. If circumstances permit them to show you a past example of their work then that’s ideal.
Of course there are also the standard questions about career journey and ambitions that you’d ask of any vacancy. Reputedly companies like Microsoft and Google like giving applicants brain-teasers like the old chestnut about crossing a river with a tiger, a goat and a bag of feed - a load of old rubbish, IMO. You’re not looking for somebody to appear on a game show or run inane management training courses.
A good agile analyst is someone who is quick on the uptake, an eloquent communicator, can form a bridge of understanding between different team members and thrives on the liveliness and short turnaround times (I wouldn’t call it ‘pressure’) inherent in the agile process. If you want to find one within your existing staff one tip is to try the QA team - I think there’s a lot of overlap between those skillsets and have seen a couple of people successfully make that transition. People in a business department who’ve become increasingly close to and interested in the technical side of things are also prime candidates.