Being a Business Analyst, In Words and Pictures

Summer must evoke the need for me to write about being a business analyst, because the last time I posted about it was just about a year ago. In that post, I wrote things that I believe to be essential to the BA (business analyst) mindset. Well another year has gone by, and that means another year of being a BA. I still believe that what I wrote a year ago is accurate, but I have found myself summing it up a little more eloquently these days:

A business analyst goes between the business and the developers, translating business needs into functional requirements or user stories, which the developers when work off of to create software in meaningful, measurable chunks.

Here’s a “real world” scenario of what a BA does:

Business: Build a new version of our software. It has to do the same thing the current version does, but better.

Developers: We need detailed directions on what to build.

Me (Business Analyst): I need to understand what the current software does so that I can provide those detailed directions. Developers, let’s start with a very basic thing the software does. How about adding a new entry to the system. How do you do this currently?

Developers: We have a base object in the database. We instantiate the object then create a type for the entity, which has varying attributes based on what entity type it is assigned. *insert even more technical details here*

Me: No, from a user perspective.
Developers: Well no matter how the user does it we do the same thing behind the scenes.

Numerous conversations later, I develop the understanding I need to write the requirement.

I then writes user stories that detail all of the functionality. Here is a simple example for adding a record to a system.

User Story 1: Create Record

  • User only sees “Add Record” button if user has proper permissions
  • User clicks “Add Record”
  • Form appears containing the following
    • Form name: Add Record
    • Label: Record Name
    • “Save” button
      • Button disabled until Record Name has >=1 character
    • “X” button allows user to cancel at any time
    • Text input field for Record Name
      • Max length 50 characters
      • Do not allow the user to type beyond 50 characters
  • User clicks “Save”
    • Record is saved to database with unique identifier
    • Confirmation message is displayed “Record Saved”
    • User clicks “Exit” button to exit create record dialogue
The BA or the UX person does a mockup of the screen, here is one for this example:
Inline image 1
Then the story is discussed with the developers and is further refined. After that process takes place, it is assigned story points and given technical tasks. It can then be placed in a sprint to be worked on. I hope this gives you a better idea of what a BA does. We develop an understanding of either the current or desired functionality, break it down into smaller pieces that can be worked on in a sprint.
Lastly, here is a sketch I made that sums it up:

So, what do you think ?