One of my first assignments as a business analyst was to turn several pages of notes into user stories and acceptance criteria. The task gave me a feel for a foundational skill, in much the same as aspiring writers will copy established authors’ work. But to think the job to just write requirements is a mistake. Being a business analyst is not about how many words one writes.
Too many organizations measure business analyst by the number of users stories written. Stop doing that.
In this data-obsessed economy, business analysts are reduced to requirement clerks and programmers to code droids. Analytic thinking is disregarded, business analysts become scribes for top-down directives, and coders have no freedom to innovate. Teams are monitored for their throughput rather than the value of their work.
There are only two metrics when it comes to the quantity of stories:
- Are there a bunch of small stories?
- Conversely, are there only a few big stories?
Each of these indicates a problem. Many small stories, items that can be completed in less than half a day, is likely caused by not understanding the product. Requirement updates become difficult and work is time-consuming to manage. Only a few big stories, those that take more than a day to complete, is likely due to cramming too much dependency into a single story. If one part of the story can’t be delivered, the whole thing is blocked. Try to make them smaller and independently valuable.
Business analysts, and the complete development team, are successful when users are happy the product is valuable. You can have one without the other: managers may obligate users to work with a thoroughly unpleasant product, and users might find a product helpful that cost more than the business finds it worth.
The business analyst’s job is to understand the why, find the value, and make delivering that valuable easy and enjoyable for everyone.
How do you identify value and delight users as a business analyst? There is no magic answer, and one could spend their entire career mastering that skill. IREB’s foundational skills are a good starting point. Empathy, communication, analytical thinking, to name a few. Understanding the system thoroughly, insatiable curiosity and the ability to share ideas are critical.
Business analysts need to be superb communicators, but at no point should their value be measured by how many words they write. We don’t say writers are brilliant because they write long books; to the contrary, we are likely not to read such screeds. Great writing gets the point across in as few words as possible. Don’t measure your team by how many they use.