5 Biggest Agile User Story Mistakes
Posted on Wed 30 January 2019 in Teamwork
Sometimes, teams feel that agile user stories are not worth the extra work. I think I know the reason why.
Today, I wanted to share the five biggest mistakes teams make when adopting user stories. Let’s recap what a user story is. It is a requirement expressed in user’s terms, and it usually has three parts:
As some role,
I want to be able to do something,
So that I can achieve some goal
The concept is brilliant. I would say it’s the best thing that has happened to requirements management in the last few decades. However, user stories are so deceptively simple that it’s easy to get them wrong and ruin all the value. So here’s my top-5 of common mistakes teams make.
User stories != developer stories
I am a firm believer that technical tasks and user stories don’t translate into each other. And they should not.
What is the difference? A user story is something a customer wants to achieve, whereas technical tasks are the little things that need to be done before the customer can achieve his or her goal. In other words, you should not convert every request in the backlog into user stories. Instead, have a larger user story that encompasses several technical tasks.
As a first-time buyer,
I can visit the “About us” page
So that I can learn more about the company
Above is a typical example of a technical task wrapped with a user story. The reason those “stories” are so widespread is that they align well with the Behaviour-Driven Development paradigm. Still, it’s a technical task, not a user story. Why? Let’s take a look at what the proper user story may look like:
As a first-time buyer,
I want to check if the company is credible
so that I can be sure I won’t be fooled.
See the difference? We don’t describe (or prescribe) implementation details, but instead, focus on what the user wants to achieve. This story is not actionable enough and needs to be split into multiple technical tasks. But most importantly, it acts as a guiding light, a clear test if we are moving in the right direction.
There is no “User”
It is easy to explain this mistake using an example:
As a user,
I want a “Contact us” page
So that I can get in touch with company representatives
What’s wrong with this story? Well, there are several things we could improve, but the main problem is that we have an abstract “user” here. The thing is, there is no just “user” or “customer” that uses your product. In fact, there are multiple segments, groups, personas - whatever you call it - with different goals, skill level, and preferences.
It doesn’t make much sense to tailor the product for abstract people because you never know if you have succeeded. It’s much better to have a few personas defined and craft user stories so that they solve the problems of these personas. The best thing is, when you have a particular user segment to target, you start thinking of the requirements from a different perspective, through the eyes of a specific role.
In our example, we can choose to target first-time buyers, and when we think of it that way, we realize the first-time buyers don’t probably need a generic “Contact Us” page. They might want, say, an online chat to help them check out. So a better version of the story would be:
As a first-time user,
I want someone to help with my order
So that I can check out online
Customer doesn’t need you
Does that sound too strong? Yet, it is true. User stories should focus on customer’s goals and expected outcomes, not on details of the technical implementation. Sometimes, (okay, almost all the time), we forget that the customer doesn’t need our website, system, or mobile app. What they do need is a means of achieving their goal. Remember the saying that the customer doesn’t buy a drill in a hardware store? They buy a hole in the wall.
Here is a good illustration of thinking too much of us instead of the customer:
As a returning user
I want to log in
So that I can store a list of my searches
Let’s be honest: the customer doesn’t want to log in at all. More than that, they may not want to store the list of searches in and of itself. What they want may be, for instance, this:
As a returning user
I want to access my searches quickly
So that I don’t have to re-type them
The second iteration of the story is not ideal, but much better. We now focus on the customer’s goal - save time not retyping the searches. Also, that may lead to a technical implementation 180 degrees opposite from the initial login functionality.
The last part is the most important one
It is a pervasive issue, especially if the team does not have all the people required to deliver value. When we create a story, we might focus too much on the first two parts - the role and description of the functionality required. So when it comes to the third part - why I need that - we are tempted to go “Well, let’s just put something in there. We already have perfect two parts”. The result may look like this:
As a regular buyer
I want to have a list of recent orders
So that I can view them
What’s the main problem with this story? It doesn’t explain to us why the customer wants the feature. Also, as you can imagine, it may well lead to the functionality that doesn’t satisfy the user’s need, albeit fully conforming to the story.
How to fix that? Let’s modify it so that it contains a user-oriented goal. Like this:
As a regular buyer
I want to have a list of recent orders
So that I can flag an issue with an order
Now we know why the user wants the feature, so even if our technical implementation changes, we can quickly check if we are doing the right thing!
When are you done?
Almost every story has acceptance criteria - a set of conditions when the story is deemed completed. It’s very tempting to put technical exit criteria in the story:
The code passes system tests
However, if we take a look at previous mistakes, we know that a user story must be focused on the user to be successful. A user usually doesn’t care about system tests, repository check-ins and releases. A user story is not done until the user hits their goal.
So what we need here is:
A cross-functional team
Our team should have all the people required to go from the idea to code to deployment to marketing to sales to measurements. Because, as we know, hand-offs between teams account for up to 90% of the lead time. Also, it’s a huge demotivator when you know that the customers will see the feature you just developed in half a year.
Metrics
Next, we need metrics to measure if we actually hit the goal. Everyone on the team should be aligned along those metrics. Otherwise, the story just falls apart to the traditional departmentalized “throwing stuff over the wall”.
Ownership
Finally, we need shared ownership, when all the team is responsible for the user story, or rather, for the successful outcome of the user story.
Let’s look at a better example of the acceptance criterion.
About us” page drop-off ratio is down at least 30%.
The difference is obvious. We have a crystal-clear metric, and regardless of what technical approach we choose, we can always determine if we have succeeded. Also, this prevents us from gold plating - perfecting the solution because of some perceived “quality” issues.
Do you have a “good” example of an agile story mistake? Please share in the comments!
We are actively hiring Python and Javascript developers who are, among other things, keen to agile practices. Want to join us in creating top-notch, award-winning cybersecurity solutions? Check the job postings!