• Nnenna

User Stories: A BA's guide

Updated: Dec 26, 2020

As a technical BA or operational BA, it is VERY important to have a story writing skill because it is essential in communicating effectively with the development team and test team. Developers and QAs do not have the luxury of speaking to the customers (lucky them!), so you must communicate the customer's desires in a way that they would feel like they were in the meetings with the customers.

This is the trait of an excellent BA.

A user story is a short description of a functionality/goal/requirement that is written from the user's perspective, to guide and direct a Developer or Tester into fully understanding what a user wants out of a solution. It is a type of technical specification, that further breaks down a requirement, and it is mostly used when working with the technical team. Read more about the usefulness of User Stories.

The structure of a user story is:

As a <user> , I want to <goal> so that I can <justification of the goal (for the sake of giving the reader a context)>


One platform may have different types of users, therefore it is professional and essential to specify who the user is. Only use the word "user", if the platform has only one type of user. An example of a multi-purpose platform is a company's HR system that would have users such as: "applicant" and "HR".

It is important to separate and specify the different users on a platform, so you do not give a particular user some privileges that they are not meant to have, besides, different users may have different goals, e.g. what a parent would want is different from what a Child would want from an app.

The last thing you want as a BA is to confuse the development and test teams by writing "As a User..." because the next question would be, "which USER, Nnenna!"


This is what the user wants to achieve. A staff's goal may be to submit a Leave request, but HR's goal will be to Accept or Decline the Leave request. As you see, the goals are just as different as the users. The goal gives the developer the scope of that user story, to allow them to brainstorm what kind of functionalities the user may be expecting to achieve their goal. A user story must have 1 specific goal.


Let me give you an instance to describe how important the justification is:

If someone dropped their pen, and asked you to pick it up, you are likely to respond with "...what??!", however, if they asked you to pick it up and explained that they had a bad back, you would quickly pick the pen up and say, "I hope your back gets better!"

Asking the Devs for magic and telling them why you need it, helps and limits the scope of their imagination and creativity, while lessening the chances of them running wild (that is, misunderstanding how the user wants the problem solved, not how the Devs want the problem solved-- unless the solution is for the Devs, of course!). It gives the Developers & Testers the reason and context as to why you, or the user, are asking them for those crazy things. Finally, it allows the Devs + QAs to understand the user's behaviour, perspective and need.

Having explained what a User Story is, I will end this with a question that I was given at an interview.


An organisation is currently running a manual process for booking and managing training courses.

The current process includes the following:

  1. Delegates contact the team by telephone and email to book training courses;

  2. Administrators manually update the Excel spreadsheet including adding new courses & dates

  3. Administrators manually update the Excel spreadsheet including adding delegates

  4. All the course, delegate and trainer information is currently held and processed on an Excel spreadsheet


User Story 1:

As an Admin Staff, I want to add new courses & dates, so that other users can view these new courses and dates.

User Story 2:

As an Admin Staff, I want to add new delegates, so that these new delegates can have access to new trainings.

User Story 3:

As a Delegate, I want to view a list of training courses and their information, so that I can book the courses of my choice.

Test yourself and share your user story for no. 4.

This is pretty easy because I was already given the Requirements, which I then converted into User Stories. So please stop trying to manufacture user stories out of thin air, otherwise you will struggle with writing User Stories.


User story writing, like any other kinds of communication, has its rules. A user story must be:

Specific: Don't put the word "and" in the GOAL section, that's two users stories you're passing off as one.

Measurable: It must be estimable. It must allow a dev say things like "that's easy, I could do it in 1 sprint!"

Attainable: it must be achievable; don't give the developers complex stories that would make them quit.

Reliable: I don't know why a user story should be reliable, but the BA Practice insists it must.

Testable: well, this goes without saying. Writing a story that allows you to communicate with aliens may not be testable if you don't have an alien to test it on.

This is similar to INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable.

That's it on User Stories. As usual, drop your comments and leave any questions or contrary opinions that you may have. In the future, I will write about Acceptance Criteria. There are more examples of user stories here.

#fairygodmother #businessanalysis #userstories


Recent Posts

See All