Misuse of User Stories
You can use User Stories for pretty much everything you do today.
But you shall never use them to write down software requirements.
Hi My name is Lukasz. I started creating requirements back in 2008 when I helped Motorola to save 1.5 million USD. My biggest achievement is creating an algorithm which translates requirements specification into a complete list of Unit Tests. As you see I am a software requirements geek.
I was writing my first User Stories back in 2010. I changed jobs without changing job’s address - Motorola and Sabre had both rented different parts of the same huge office building. I had new colleagues and new bosses who told me to start writing User Stories. What? Why? Really? I knew back then how to write requirements. That is why they hired me - to write some requirements also for them. Why the hell do I have to write them as User Stories? I felt like a poet who was told he has to write each and every poem using the same pattern: As a user … I need … so that…
Doesn’t it make you yawn? So boring. But there are good reasons why people wanted it like that. However this has nothing to do about communicating requirements and there is where our conflict lies.
To INVEST or not? Why I don't like acronyms as a marketing method.
Actually most of the work with writing User Stories is around Acceptance Criterias. To me it sounds exactly like the atomic requirements but who would argue too much if they just joined a new company. I just started to create them one by one. I know them inside out. I know INVEST criterias and I know patterns to split User Stories into smaller ones. I know there are two templates: 1) As a … I want .. So that.. 2) In order to … As a … I need …
I also know there are many, many people who advocate using User Stories. However you would be better off not following this crowd blindly. User Stories have their dark side and you shall beware of it.
Fast forward to September 2023. About a month ago I created a list of 100 companies who are looking for Business Analysts.
I went through two popular job boards: pracuj.pl and indeed.com. I was reading many job offers and wondering if there is a match between their needs and my skills. ‘Writing User Stories’ was a must have on many job offers. Also most of the offers mentioned Agile Software Development which you could treat as a synonym for applying User Stories. What most people do not realize is that User Stories have a huge negative impact on IT projects.
The benefits of using User Stories are huge. It is all about delivering working software to end users. User Stories make you chunking all your scope into pieces which shall meet INVEST criteria. Independent, Negotiable, Valuable, Estimable, Small and Testable. You probably have heard about INVEST and know what it means. Once your User Story actually meets those criteria very interesting things start to happen. You now have a chunk of functionality that is working and is valuable to your end user. It is small so you can develop it in a few days - well maybe in a few weeks. It means every few days or every few weeks you are releasing a new version of your software to the production environment and everyone is happy. You get direct feedback from end users very often which help you learn how to meet your customer needs. Life is great and finally there is no more stress.
People really started thinking naively that User Stories will solve all the problems which they had in waterfall projects. If only everything would be so great.
You see, I think most of the time you can not determine a portion of functionality that would be truly valuable and small. There is a huge problem about this word: ‘valuable’. It is an ambiguous word because it raises a series of questions which most likely will be answered in different ways by different people. To whom the User Story shall be valuable? To the end user or to the software developer? Does valuable means that the end user can now generate more value? Maybe that would be too much to expect. Ok, so maybe valuable means we are getting closer to actually build something valuable. The story just needs to be done together with a few other stories which then allows the end user to generate more value? Valuable is a tricky topic here. This means that achieving INVEST criteria all the time is not possible. I think it is possible only under very specific conditions when your project is extremely easy to do. We do not want to have such philosophical discussions during our IT project. We shall just move forward with our jobs. But what job? Ideally the one described in requirements.
I will store my requirements in JIRA when programmers will store their code in JIRA.
Do you agree with my observation that most IT projects use User Stories? You have probably seen hundreds of them already. They are everywhere. I think that every software development company was using them and most likely still is. And this is ok. I have no problem with it but … it has a problem with me. You see, I refuse to write down requirements inside User Stories. I think spreading documentation across User Stories is just a very bad idea. I want to show you that you shall rather link requirements with User Stories. Don’t worry - you will still be able to do Agile software development. I am not a Waterfall die hard.
What I want to stress out in this article is that software requirements have to be done in an accurate way. They have to satisfy end user needs and they have to organize knowledge in a scalable way. What does it mean? Well, you shall always be able to find out what the software does just by checking the requirements. You shall also always be able to add new features or modify existing ones starting from requirements and not from the code. I want to prove to you here that there are far too many problems when you do not have concise, logical, easy to understand requirements.
The problem is that people do not know most of the time how to get there. IT people know how to write source code, how to test it. But they do not know how to organize the knowledge about functionality outside the source code.This is why User Stories are so easily welcome in so many places. This is just an easy way to move forward with development without actually having to write high quality requirements.
This would be fine if software developers would never change jobs. When they do, you lose the knowledge. You always have source code but it may not reflect the business needs anymore. Business is changing, organization charts are observing changes of names - your Product Manager is no longer here -when he/she was present you could always find a workaround and an easy way to fix the system. Now he/she changes projects, might be promoted or would simply retire. Your source code is no longer relevant and nobody can clearly see it because business people do not read the source code.
When you stick with User Stories for writing down requirements - you are doing an ill service to documenting the knowledge. Instead of documenting the current state in one place you document each and every small change in a different place. Let’s use an example:
-first User Story was to send notification email to customer when they subscribe to a newsletter
-second User Story is to prevent sending notification email to customers when they subscribe to newsletter
-third User Story to send notification emails when customers selected an option to get marketing emails.
These 3 User Stories could be done in a timespan of a few months. They were done in different releases. The problem is that they are contradictory - each of them tells you to do something different in this specific situation. They might still be partially relevant because some of their acceptance criteria are still met - e.g. content of the notification letter could be described in the first User Story. It is not possible anymore to maintain documentation of the system. You can only make new changes - but you can never really clean up requirements.
You see the problem is not in writing User Stories and not in software development for User Stories. This is manageable. The real problem starts when someone actually needs to find documentation for an existing system. Such a person will have to manually open multiple User Stories and read them one by one. Even by doing it this person can not be sure if what he/she reads is still relevant.
Having documentation in one place makes it easy for new people to pick up work on your project. This is something that every big company shall think about. They will be updating and migrating legacy systems - sometimes so big and critical that they will have to postpone adding any new services for customers. If this takes too much time they will start to lose customers to other companies who do not have to spend months and years on fixing IT systems.
Idea.
Let me ask you this question - how much work on data and functionality migration is your organization doing right now? How many legacy systems need to be replaced because the technology is no longer supported or it is just too expensive to continue using it? How many old mainframe systems are there in large financial institutions? How many applications are taking data from your System of Record - all of them? Even for your top notch cloud based systems because they are all using the data coming from mainframes.
Never heard of mainframes? You are lucky. What about your current systems on-premises? Aren’t you planning to migrate some of them to the cloud? Well of course you still have the source code - but would you migrate it one to one without listening to your users? That might be tricky - there are many people in your organization and they can influence others to get what they need. You will end up redesigning the user interface and adding features - it would help if you could just update existing requirements and build on top of those requirements instead of giving developers a long, never ending list of changes to be done.
Does it all mean that User Stories shall be abandoned because they prevent us from having proper documentation? In fact there is a very simple solution which allows you to have both: User Story based software development and also separate and up to date specification.
You only need to split requirements from User Stories and keep them separately. You need to move them into some version control system like Google docs, Sharepoint or Confluence.
Example.
Let’s now switch to actual examples. On my website there is an example requirements specification for a small and simple system which allows people to organize amateur sport games like football, volleyball or basketball matches. We do not implement this system but only show how requirements shall be written for it. That is why originally we didn’t plan to write any User Stories. Does it mean that we are stuck in a Waterfall kind of mentality? No, we are actually ready to start it anytime without any delay. I will explain to you later how to do it. Now let’s actually see some User Stories.
Here is a list of a few possible user stories for the same system. The purpose of this IT system is to help people organize themselves - mainly to join other people who also play your type of game in your city.
User Story: Select a discipline
As a player
I want to select a discipline I am playing in
So that system remembers that I am interested in playing this discipline
User Story: Select city
As a player
I want to select a city where I want to play
So that system remembers that I am interested in playing in this city
User Story: Display players
As a player
I want to see list of players who play my discipline in my city
So that I know if it is worth to register in this system
User Story: Display games
As a player
I want to see list of games
So that I know if there are some games close to me
User Story: See game details
As a player
I want to see number of players and other details of specific game
So that I know if I could join this game
User Story: Join a game
As a player
I want to join specific game
So that I can play my favorite sport with other people
I haven’t specified any acceptance criterias yet because I want to first talk about what we have here. There are 6 User Stories and they seem reasonable. They help the end user to find people and places where he or she could go and start playing. So what is the point of saying that User Stories are not the right tool for writing requirements? The requirements are here and they are pretty obvious. Well yes, but … Let us check what will happen next to these 6 User Stories.
Right now you can see titles and descriptions of all User Stories next to each other. However it is not so in the tools which companies use to work on IT projects. In JIRA or Azure DevOps each User Story is a separate screen and you can only see one at a time. You could see titles of them next to each other like this in your backlog or query view:
User Story: Select a discipline
User Story: Select city
User Story: Display players
User Story: Display games
User Story: See game details
User Story: Join a game
However when I used those tools I was never able to see the full description together with acceptance criteria on a one screen. I actually would also prefer to be able to edit multiple user stories in this way. However, here lies the problem. Take a close look on this diagram:
User Story has a relationship with various things which happen during software development. For example when a software developer wants to change source code he needs to do it in the version control system: usually in git. Now we have a new git commit which needs to be somehow traced back to the requirements - it is done by linking this git commit to a specific User Story. Everyone is happy but then there is a sudden conflict which I had a number of times. Suddenly a Team Lead of the development team tells me that I shall not update requirements which are linked to User Story that was already implemented. I can not agree with it because I need to keep extending and improving requirements all the time. Very often I am specifically asked to update requirements by a software developer who is working on User Story. So I tell the Team Lead that the User Story is a change which is described by historical requirements - namely by a historical version of the requirements. It makes the discussion more heated but there is no way around it. Perspective of Team Lead and mine are just different but we can and we will solve this conflict.
Here is a final solution that shall make everyone happy.
Inside the user story you add a hyperlink to the requirements document. Once you go to the requirements document you will spot atomic requirements and the ones that are relevant for you have the User Story number next to them. e.g.
Repository of User Stories:
User Story ID: 45678
User story name: Send notification email
Requirements documentation:
Req ID: Registration.Notify
Req body: Upon registering as a new user system shall send notification email only when the user has set ‘Send marketing emails’ to ‘Yes’.
User Stories: (45678 - Send notification email)
Simple but somehow people try to still keep requirements under User Stories. There was a long period of time when I was allergic to the User Stories. Knowing how to deal with it has made my life simpler. You shall also try to work with requirements this way. Trust me it will pay you back sooner than you expect.
About me
I have been a requirements engineer for 15 years.
I'm here to help you communicate software requirements.
Social Media
Strona www stworzona w kreatorze WebWave.