A brief history of User Stories

How many times have you heard about the term 'User Story'?

In modern software environments, there's no doubt you've heard about the term 'User Story', which can be interpreted in different ways depending on your background, your business scale, and your organization's level of agility. But let's ask a first question here, how (and why) this concept became so popular nowadays?

User stories are narratives they tend to tell us a story (OMG!) about the user, they can be phrased as :

As a [Some type/category of users], I want to do [some action], so that I can [be rewarded].

User stories are treated now as an essential part of Agile Software Development, they've been used alongside the other agility concepts to solve the modern software industry's problems which can be summarized into one phrase: 

 Things are getting changed so fucking quickly! 

And this is a normal in the new business places, everything is going bigger and bigger, and changes will exist.

The user stories were 'Promise of a discussion' back then when all these Agile things were new, they were being used to highlight things that need to be discussed with different business stakeholders. It's still valid that nowadays, it's also a way of communication, but becoming more and more centric piece of the Agile development traits.

What value they can bring to both business and software? 

For business folks: You have changes, right? So, you need flexibility to shift directions anytime. It's a world of chaos! And if you don't have this kind of changing in the right time, you're probably risking the durability of your business! That's why putting braking down your vision into smaller pieces helps you move slowly, with an eye on the market, how does it behave, and how does it reacts to your continuous innovation.

For software geeks: It hurts buddy, it really hurts when you see that great feature you kept working on the last couple of months vanishes and goes away! It's as bad as losing your pet, or even your coffee machine! And you know what? these business guys will always ask for changes! It's how things work on their jungle, they have to compete and be as advantageous as possible. So, accept it, changes will be there. But the good news is, user stories are also there! Building your systems in such a smaller pace is crucial for both quality and value of your software.

It's not ritual! 

Being disciplined is a good way of ensuring consistency and collaboration in your organization. But, every place and environment has a different set of rules and processes. And it's about adaption not rituality! Agility is to hire new concepts to follow the process, not the reverse! Sometimes you'll have to change a process, but it's not for the sake of change! You should have your reasons for such changes. Drafting a punch of user stories without actually breaking down your way of producing software is useless and waste of time. If don't see the value for your business, then don't do it!

Agility (and therefore user stories) is a way of thinking and managing the innovation on a day-to-day basis. Following them can be painful, especially if your place isn't so Agile, but recognizing the value in following these practises is the most important part!