The Trouble with User Stories
Are you sure that you do know what the user story is? It is a vital part of the Agile manifesto or scrum guide, but what is it? Why is it so important? A dozen definitions say that user story can be a feature, high-level requirement, a unit of work, functionality, capability, or anything else related to the project. These definitions come up from Agile gurus, influencers, and bloggers – but no one defines what user story is.
The user story’s primary issue is that even people who are working in the same team don’t have a common understanding of it. And here comes the immediate trouble of every software development project – disagreement between team members leads to chaos during the process. Moreover, massive stacks of user stories that are created for business goals, requirements, specifications, development tasks, solutions of problems, and so on drive into the project documentation.
What is wrong with user stories?
User-story in every team member’s life looks like a real hell. Why? Because they are too different. Let’s look at the following examples:
John: “As a user, I want to use my social media credentials to log in to the system. So, I don’t need to create and remember more usernames and passwords.”
Hanna: “As a user, when I log in, I want to be redirected to the login page of the Identity Provider I selected. So, after entering my credentials, the IP will be able to redirect me back to our system with a valid SAML token.”
Do you see the difference? These user stories describe the same thing. But the primary difference is the scope. John’s case is scoped at a high level, for example, the sponsor’s one. And Hanna’s case is scoped at a much lower developer’s or tester’s level. Yet, they are both user stories.
There are a lot of things written about user stories, and a lot of teams are using INVEST guidelines and are trying to scope their stories using this approach. But the main objective of these guidelines is that they are open to interpretation like user stories. Yet, some stories cannot be interpreted using INVEST.
User Stories are hiding real value.
Dan: “As a blogger who codes, I would like the chosen blogging system to integrate with Github. So, readers can see my GitHub activity in my profile.”
The story answers questions: What, How, and Why. It has an objective, yet, how will it help the blogger to reach his goal? No one can tell it since the story doesn’t tell us the purpose. The goal is hidden behind the objective. Moreover, the objective is not the goal, and the tactic is not the strategy. Additionally, the output is not the income, and the tactic is not the strategy. If we rephrase this story, here is what we can get:
Dan: “As a blogger who codes, I would like my GitHub activity to be displayed on my website, so my readers can see that I’m a professional coder and read my posts.”
This user story is much better. We got everything we need to know. Yet, most people will accept the first version.
Another guideline called 3Cs suggests to have a conversation around the user story. It’s good advice for an experienced analyst who can quickly determine a user story’s actual goal, but most people will be happy with any story that is at least clear.
User Story can mix up problems and solutions
Tony: “As a reader, I would like to bookmark pages. It will help me quickly find relevant content in the future.”
At first glance, this user story is completely fine. We have a role, activity, and, most importantly, goal. But the story describes not only a problem but also provides a solution. Yet, is it the only solution to this problem? Is there another better solution? If we use this story as a requirement, we will never find out if there is any.
It is challenging to prioritize user stories
Backlogs are full of user story cards. Most of them are well-written, following the same template; they describe a broad range of problems and solutions. They are even widely scoped but provide a little context as to the business behind them. But how to prioritize them? Do we need to do that by value or by cost? If we have a specification for a story, we may try to make an educated guess.
But like most people in the same situation, we follow “planning poker ” estimation. We are going through lots of stories to assessing their value and cost.
It is challenging to classify user stories
Most of the user stories are difficult to organize for your backlog. Of course, we can classify the story by user or value it gives to our software, but this cannot be applied to all stories you might have. The good idea is to map your stories. At the top of your map are big stories that involve many activities and can be divided into various steps. It’s a good idea to divide such user stories into smaller ones and put them under this “big” story and so on.
As a result, your story pool will become more classified, and you’ll get rid of duplicate stories you might have at your backlog.
So, what is the user story?
We use user stories for more than 20 years already. And how it comes that we have not defined it yet? For developer’s user stories are the requirements and should be designated as such. But how do we classify requirements? Here is the model you can use as a basis, and in the end, you’ll get rid of messy user-stories and still follow the behavior-driven development approach.
Requirements model
The requirements model is aimed to answer four primary questions for each user story or a stack of stories:
- Why – a business goal: the benefit you get from the software.
- Who – stakeholder: some person who is influenced by our system.
- What – capabilities: system ability that allows the stakeholder to achieve their business goal.
- How – feature: a piece of functionality that helps to get the capability.
This model helps us represent and narrow down our functionality, creating a clear backlog, and still developing for users.
We, at Efisco, hope that you enjoyed reading our article on user stories. If you would like to find out more about what we do, please visit our services page. Stay tuned!