Summoning up the other side of the debate, here are some thoughts about why business analysis might not be a profession in itself. I am also bringing in some comments and opinions by a group of people each of whom I consider to be examples of “professional” business analysts. Ironically, they all seem to have adopted the position that business analysis is not a profession, at least for now.
As much as Mr. Blais has some good points about the profession of business analysis in the last article (Don’t Try This at Home part 1), I am presenting the opposing point of view. Business analysis is not a profession for the following reasons.
A Business Analyst for Life
When you think of the “professionals” – the doctors, lawyers, engineers, etc. – you think of people who are in that profession for their entire career and then some. A retired doctor is still thought of as a doctor. In the field of business analysis, there is a constant clamoring for the answer to ‘what next?” In articles, and around the blogosphere and discussion worlds, the question is consistently asked: “is there life after a business analyst?” In a recent series of articles Cathy Brunsting posited that business analyst was not a life long profession and suggested that business analyst “manager” or “leader: are the next steps, but offered several alternatives as ‘next steps”: product owner (for organizations engaged in Agile software development), Product Manager (for retail, manufacturing or distribution organizations). enterprise architect, business architect, account manager, and senior management. The latter has been my somewhat tongue-in-cheek response to the question of upward mobility: the business analyst is the future CEO.
Today I was talking to a friend about some cool work we've been doing recently around a "basics of BA capability uplift", and were talking about the value of Business Analysis and Business Analysts here in Australia compared to overseas.
I offered the viewpoint that I felt Business Analysis is poorly understood and undervalued in general in Melbourne (my experience being mostly with large corporates). He agreed and compared it to his experience in Canada, where he did not find it to be the case.
What influenced my viewpoint? Well, the general attitudes I've experienced in my career as a Business Analyst, but more recently, some truly inspiring lines (spoiler alert: not at all inspiring) I've heard in the workplace recently, such as:
- "So, what exactly does a business analyst do?"
- "Just put the requirements into the BRD template, that'll do."
- "I've taken my notes down as a mind map, and everyone else's notes are quite linear. Ha, typical BAs!"
- "The ideation stuff happens WAY before a BA gets involved."
- "Oh you don't know how to do a PivotTable? Just give it to a BA to do." (I think this one was my favourite.)
All the above of inspire certain feelings in me, some gentle, some a little more aggressive, but in general, something along the lines of below.
Have you heard of the “3’C’s” of User Stories? It’s a heuristic to remind storywriters of the three key aspects of a User Story:
There’s quite a bit of debate as to what the most important ‘C’ is. Often in my classes I talk about “conversation” or collaboration being the most critical ‘C’. But to be honest, I have a hard time making a priority distinction between the three components of a user story.
In this article I want to explore an area that is often overlooked. It’s the confirmation-C. I sometimes refer to it as:
- Acceptance Criteria;
- Acceptance Tests;
- Mini-UAT for each story;
- Or Confirmation Tests.
Acceptance tests seem to be the most often used terminology. For example, leading to the notion of ATDD or Acceptance Test Driven Development, which can be a powerful side effect of how you approach writing your stories.