User stories describe software functionalities that are valuable to either a user or purchaser of that software. In other words, they describe what the user can do with the software.

User stories also allow business guys (product owners, stake holders, business analysts ) to describe what functionalities the software has to cover. At the same time they allow the developers to analyze, decide on how-to, and estimate time for development. 

Almost every software project nowadays is developed in an agile development style. Depending on the team, each has its approach to be agile, sometimes they are truly agile more often they are not. 

The two main groups that participate in project development are the tech guys (developers) and business guys. Sadly,more than often, they don’t speak the same language, though they have one goal, the success of the project in hand. User stories help the communication between the two.

One of the most common problems I observe, when working on projects, is misunderstanding the INVEST model of user stories. Failing to craft user stories following the INVEST model has many consequences. Delivering a wrong functionality, duplicating the work by two or more developers, blocking one developer during development, etc … are all examples of such consequences. But what makes a good user story?

User stories have a common form that they follow, though it is not mandatory. 

As (user)/(admin)/(someone who will user the software) I want to be able to (some action), so that (the outcome value) 


As a user I want to be able to store photo, so that I can view it later. 

The INVEST model of user stories. 

The INVEST model stands for (I)ndependent (N)egotiable (V)aluable (E)stimatable (S)mall (T)estable. 


A story is independent when its implementation doesn’t depend on other stories. Consider the following stories: 

As a user I want to filter books by name 

As a user I want to filter books by ISBN  

The first story depends, and duplicates, the second story, the path to implement the first story is pretty much similar, if not the same, to the second story. 

Dependencies between stories lead to prioritization and planing problems, efforts duplication during development, and difficulties during merging codes. 

Many times I have been forced to delete my code or my colleagues code because our code was 90% the same and the only thing we really needed was to parameterize some methods and refactor some classes. For each story you are writing, ask yourself if developers would block each other. if so, this two stories are highly dependent and they should be made as one. If merging these two stories seems to be impossible for some reason (like the business analyst, or any author of user stories, thinks he is the chosen one and his stories are prefect) it is highly recommended for those two stories to be linked and implemented by one developer. 

Recently me and my colleagues were working on the following “user stories”:

Fetch vacation from X system to our application.

User should see fetched vacations in his calendar.  

Apart from the fact that the first “story” looks like anything but a user story, they depend on each other. And here is what happened. 

I implemented a service that fetches these vacations from X system and saves them to our database. We implemented saving these vacations by a Repository interface, for some reason I needed to have not only save method but fetch method, here is what happened :

When the time to merge our ‘stories’ came, we had to remove one of the repositories and it`s implementations, than refactor the remaining one. This added extra effort to our original work, which also made our original estimation of stories wrong, in the eyes of project manager and product owner. One of us implemented a repository that we later deleted. Apart from the fact that we needed additional work to finish our task, I was a bit disappointed, and demotivated when I had to delete the code I’ve written with passion and covered by tests. The team should pay extra attention to avoid user stories coupling. 

Sometime, however, it is tricky to decouple user stories. If this is the case, in order to avoid code merge conflicts, it is advisable one developer to implement all dependent user stories. 




Stories must be valued by users, software purchaser, or some 3rd party software. When writing user stories it is important to ask the question what value it adds for the mentioned groups. 

Consider a bookstore application and the following story: 

Users should store books in MySQL DB.  

Now, what value does this story, for the users,  have ?, no value ! First, the user, most probably, won’t know what MySQL DB is. Second, even if he knows, there is no value in  merely storing books in some storage engine that is MySQL? What the user actually values (needs) is probably to be able to retrieve a stored book and explore it or download it. The story can be written as:

User should be able download a stored book.


User should be able to explore a stored book.  

These two stories in them self include storing the book. 

In general, avoid stories that only developers value like: 

A connection pool should be used to connect to DB. 

Sl4j logger should be replaced.

MySQL database should be used  

At the end of the day, developers should add value to the software that solves users problems not developers problem ! 


Developers should be able to give time estimation for the story, or at least take a guess. A couple of reasons developers may be unable to do so. 

Lack of domain knowledge. Domain knowledge is gathered from users and domain experts thus developers should sit and question. 

Lack of technical knowledge. 

System can authenticate users using their social profiles. 

If none of the team members has ever done that before, the team should split the story into two, a spike and the actual story.Spikes represent small exploratory and research actions for gathering some technical knowledge. Developers give spikes maximum amount of time called (time-box). After the spike developers should be able to give an estimation.

The story is too big. In this case, the team should split the story into smaller stories, without introducing dependency between stories, or at least try not to.    


Small may be not the so proper, in my opinion, I prefer the term moderate. If they are, developers will find them hard to use in planing and estimation. 

Big stories fall into two categories, compound stories and complex stories. Consider the following story, as an example of the first type. 

User can create a personal profile. 

A story for a social media application. Creating a personal profile can include adding personal information, adding a photo, connecting the profile to other social media, verification via email, SMS, and so on. 

An example of complex is a story that, for some reason, developers find it hard to implemented. Introducing new technologies and adding new algorithms to the projects are an example of complex stories.

User can update his membership by paying with credit card. 

Maybe none of the team members have ever implemented credit card payments.This is a complex story, that the team needs to split into spike and implementation. In our case one or two team members can start a spike to learn how to implement payment via credit cards. 

Sometimes things go to opposite direction. Stories become too small. Too small that developers don’t even want to estimate them or even write them down. One of the teams I was working with created stories so small that I was taking more time to go back and forth to Jira than doing real job.

Stories like:

User can add his birth date.

User can add his name.

User can add his hobbies.

 Are very small and they actually fall under one user story. 

Use can add personal information to his profile. 

The most problematic issue when creating small user stories is that usually they are dependent. More frightening is distributing these stories among the team. There for sure, will be more work to resolve code merges conflicts than to implement each story.



Stories must be testable. Otherwise how can developers tell that they have done the job right?! Untestable stories commonly come from non-functional requirements.

User should find the software easy to use.

User should find the software fast to use.  

Easy and fast are relative, what I find easy and fast may not be the same for you.  Instead, one can reform stories to:

90% of the new users should be able to find how to do “something work” without any previous tutorial. 

The UI should respond in no more than 1 second 99% of the time. 


Writing user stories is not complex neither easy task to do. But at the end one should try to come as close as possible to the INVEST model. It is not always possible but at least try it. 

I rarely spot well written user stories. However, what scares me the most is the fact that , most often, worst stories are written by people with at least two titles in front of their names. 

When writing user stories ask these questions: 

User stories INVEST model

User stories INVEST model


References: UserStories Applied 


Leave a comment

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