A typical task for a Business Analyst (BA) in IT projects is to take a list of client needs and turn it into a list of features that need to be developed.The goal of BA is to deliver business value to this information. The result of this is the list of features that will be implemented. The way to do it is through a backlog and  user stories. Here’s how that works.

Every Feature Needs a Story (or Two)

A feature can be mapped to a single user story. Or, depending on its size, it can be split into a set of stories related to each other under an Epic (a way to relate stories that belongs to a particular feature). In both cases, the goal is to deliver packages of functionalities that end users would generally expect to receive bundled together.

What a Feature Look Like and How it Should be Applied

There are two main characteristics of what a feature should look like and how it should be applied:

1. Business Value. First and foremost, it should provide business value. This concept expands the idea of value beyond economic value to include other kinds of value such as customer value. These are not necessarily measured in terms of money.
2. Estimable. Secondly, a feature should be estimable. This means that it should include enough of a definition for developers, to provide an estimation of the necessary amount of work needed to implement what is defined.

But how to do this? The first step for a BA is to carefully read the provided information to get a first look at what is required by the client and map that into a requirements list. In most cases, this first step serves to provide a big-picture perspective, which is crucial to understanding client needs as well as their business.  

Next, it is a good idea to discuss with the entire team the features included in the list. Since the information was provided by the Client as Product Owner, it’s important to ensure the info gets translated properly and carried over to the team. That helps to keep everyone on track.

In some cases, it’s at this point that a first (but for sure not last) version of the backlog can be created. This is done by creating Epics and Stories.

User Stories, the Basis for Feature Development

Just some details in relation to user stories:

• Granularity is important. User Stories should be small enough to fit within one iteration  
• They should be easy and accurate so that they can be estimated
• They allow you to track progress on the related feature
• They should deliver value. This is crucial and this is the reason why it is not easy to break down features into stories.

During the following steps, BAs will need to have several discussions with the client to fully and deeply understand their needs. This will enable them to complete the initial set of user stories with detailed information. In most cases, another set of stories is created as a result of the conversations with the client because additional information is gathered.

Another common scenario is to discover new features or ways to treat features that the client was not aware of. More often than not, since agile methodologies are flexible, this set of new stories can be added to the backlog to be tackled by the development team.

How to Format a Story

All stories follow this format:

1. Title
2. Description
3. Story Points – A relative estimation system, usually estimated by team as a measure of complexity, that will provide an overview of the required effort to complete a feature story.
4. Requester and owner (developer assigned to the task);
5. Descriptive text (acceptance criteria, conditions of satisfaction) that define the details of the work to be done and determine when a story is completed, ready for tests and working as expected.
6. Wireframes of mockups that shows how the feature should look like.

As Always, Communication is Key

Developing a good feature and dumping it into a user story is not an easy task, especially for new projects and for members who are used to different approaches and methodologies. It is very common to incur errors. Therefore, communication between the team and the client is an essential part of our work to avoid (in the worst case) implementation of the wrong deliverable.

So if we had to summarize in one sentence, it is a good idea to follow agile methodologies’ best practices and discuss thoroughly every feature before starting to work on it, and then again during the development as many times as needed. That is how you build a feature from scratch — carefully and with much discussion!