Business Analysts are Important

I’ve always been convinced that User Stories are the way to describe feature requests. It just felt natural. IEEE 830 specification are just too ambiguous. Use Cases, even far more verbose, are often too large by covering all possible flows and exceptional cases. User Stories just fit the bill.
Writing good User Stories can be a daunting exercise. A proven way is to use the
AS A persona/role
I WANT goal
SO THAT business value

template with which the User Stories become much more tangible and more important of value to the customer. Watch out for ‘and‘ or ‘or‘ in the I WANT section, those often indicate a second User Story.
So far so good, but this still leaves the acceptance criteria out of the picture. Acceptance Criteria are a good guideline for developers to make sure they do the right thing right. It gives them a change to cover themselves with proper unit tests. QA also uses them as a testing foundation. Most important though, they are the definition of development done. (see ‘Measuring Progress‘) Sure, the customer still has to like and accept them!
So that brought me to use:
GIVEN context

WHEN event

THEN expected outcome
With those kind of user stories you would think you are in pretty good shape. Well, you probably are in the remote case should you develop a programming tool. What does this mean? The more the development team knows about the problem domain the better they are off. Now, consider the case that you develop software for the financial, medical, nuclear or any other foreign field. Looking at the image below you are ok for as long as you stay in the green band where the requirements are clearly understood. In case of the mentioned programming tool your programmers will.


Once you enter the red band, the team enters an unknown and not well understood territory. The User Stories might read like this.
AS A wombut

I WANT to blabalam amplituded chromioms in a shamaluk
SO THAT I can implotude the defused mobolobs

Makes any sense? If you are post-doctoral wombut it will. So, how can this knowledge be transfered to the mortal world of developers?
One option would be to have the wombuts and developers spent long hours together so that they get some understanding about the domain. The more knowledge is missing the longer it will take. Most often, however, wombuts are so busy that they can only spare an hour here and there. There might be some short hallway chats; but often those rise more questions then they answer.

Over the long run, this will lead to an information deficit and the resulting vacuum will be filled with assumptions. Don’t assume — if you assume you make an ASS of yoU and ME 😉


In the world of TOC (Theorie of Constraints) you can mitigate a constraint like this with introducing a buffer. The buffer enables you to be productive even though a upstream step is blocked. What could this buffer be? As the title already reveals, it would be a Business Analyst (BA).


Having a Business Analyst will give you two things. First, knowledge you can access all the time; usually the knowledge of the BA is a subset of the experts but in general good enough. If the BA does not know an answer or isn’t sure, she will follow up with the domain expert and report back and grow her knowledge by doing this. Second, the BA can help to bridge the communication barrier between the developers and domain experts. She is used to work with developers and understands how they think. Still, the lingua franca between both sides would be the User Stories with their acceptance criteria. If both the developers and domain expert are happy with the resulting User Stories then we have an agreement about how the customer value will be delivered.

What about the blue vertical band on the requirement image from above? The green/blue area is a well understood domain but is technically challenging. Think about the really fancy programming tool mentioned before — for that strong programmers will be able to do the job. The red/blue area is when you need both; a BA and real good programmers.

Considering I lead a project in the plain red area (not red/blue) and I had to choose between a real good programmer or a BA, I would opt for the BA without hesitation.


  1. Mark Burnett

    I totally agree that business Analysts can be very useful.
    It Sounds a little to me like you feel that a BA should be an interpreter between developers and the customer of the product.
    This to me would be a worry on a project, and something that I would want to put right. I feel like developer should wherever possible be talking the same language, and coding that same language into the domain model.
    What I like to get from someone focusing on a BA role is attention to details of stories, managing conflicting needs from multiple stakeholders, helping plan strategic ways of delivering a product incrementally and maximising business value from each incremental delivery.

  2. gerrard

    The only useful BAs are those that have worked in the business. There is growing trend to go out employ business analysts for a project. They might have the ability to produce documents but typically they create chinese wispers between the customer and developers that distort the requirements. Professional BAs cannot answer even basic questions without running back to the customer to check the rules. It would be more logically to move someone from the business onto the project and employ someone to fill their role while they are away.
    When you have someone who has worked for the business in the area being developed then developers and the BAs can have robust discussions about the requirements, and get down to real requirements.

  3. bengeorge

    In a perfect world their would be no need for a BA. Because the people from the business would have time to answer all the dev’s questions, and visa versa.
    Unfortunately it isn’t, so really a BA is just a glorified proxy for all the dev’s questions. The difference between a good BA and a bad BA, is the good one will ask some of those questions before the devs do.

Leave a Reply

Your email address will not be published. Required fields are marked *