4 paths to utterly useless user stories

So whats the big deal with user stories?

Since the proliferation of agile software development, I've had the opportunity to see a vast amount of user stories as part of my job in the IT industry. In this post I will give a quick run through of the most common anti patterns that are worth trying to avoid.

Since user stories have become the only written documentation for the requirements for many teams, getting them right has become crucial. If you can get them right, you're more likely to be working on a happy and efficient team.

What is a user story?

The canonical user story is a short description of how a system is supposed to behave when a specific user type is interacting with the system. This means that a user story specifies requirements and behavior, but not how to achieve this behavior.

Here is a short example. Joe's Pizza has a special every day, but their online shop doesn't support them. This is the story that covers it. Usually a user story is accompanied by a number of success criteria:

As an online shopper on Joe's Pizza, I want to be able to view and optionally order today's special, so I don't have to call the shop to ask about it.

• The front page shows me what is on today's special.
• I can put today's special in my shopping basket from the front page.
• The list of pizzas offered at Joe's Pizza also contains today's special.

That's all.

Anti pattern 1: the wall of text

As an online shopper on www.joespizza.com looking for a delicious family pizza to share with my buddies at home (brought out by delivery), I'd like to be able to see if there is a special of the day. If there actually is a special of the day, then it should be possible for me to order that (together with other pizzas and possibly snacks or drinks). When I get to the checkout, it should be on the receipt along with all the other items that I ordered. If I look at the front page, it should display the special, just like the list of normal pizzas should have it.

Wall of text-user stories usually come in two variants - one where the success criteria are missing and another where the success criteria exhibit the same issues as the user story itself.

Consequences

Wall of text stories require much more mental resources to decode because of the immense amount of information, most of which is irrelevant. Teams that have wall of text user stories will have trouble aligning internally because each team member is forced to make up her own interpretation of the story as she goes along.

The likely end result is that the author of the wall of text story doesn't get what he or she intended. The team will make their own interpretation and deliver that instead.

Beyond the risk of not getting the right outcome, the team also pays a high price while they are working on the story because they are forced to constantly align and re-interpret the story internally. In other words, this type of story makes the team inefficient.

Anti pattern 2: the design specification

As an online shopper at Joe's Pizza, I want to see an advertisement for today's special in the upper left corner on the front page.

• There is a green button that I can click on to add the special to my shopping basket.
• The list of normal pizzas starts with today's special with yellow background and embossed extra sized text.
• When I put today's special in my shopping basket, it is not added to a new field on the order in the database.

This type of story is easy to recognize because it looks like a design specification, and not a specification of requirements. It specifies of how the system should work, but not what the user needs and it is likely that the author has been so eager to write specifications that he or she completely forgot the leading "As a <some user>, I want to".

Consequences

Depending on the team culture, the design specification can influence the team performance in very different ways.

The team may decide to just comply with the specifications and don't ask questions. Their solutions will then be substandard because they aren't designing them themselves. Even though the compliant team may have roles like UX analyst, software engineer or tester, they aren't using their skills to develop an optimal solution for the end user. They are basically just doing what they are told.

Anti pattern 3: unrelated requirements

As a user on Joe's Pizza, I want to be able to view and review the today's special online.

• I can see the today's special on the front page.
• I can review the today's special or any other pizza from the list of pizzas.
• I can order today's special from the front page as well as from the list of pizzas.
• The pizza with the highest review should be featured on top of the pizza list, next to the special of the day.

Completing this story will result in two different features delivered: that the user can view today's special on the front page and that the user can review (all) the pizzas as well as today's special.

Consequences

Stories containing unrelated requirements tend to come with very long lists of success criteria (unless the author gave up and didn't write any!). The basic deficiency in a story with unrelated requirements is that it can be split into some smaller, more specific stories. The story with unrelated requirements can lead to the following complications when the team is working on it:

• The team may deliver something else than what the author of the story expected because the requirements are inherently ambiguous.
• The story is hard to complete in time because it is larger than normal.
• The technical implementation is more complex because it may require that the team works on many different parts of the system at once.
• Specifying how to test the story is complicated by a much larger number of combinations of normally unrelated user facing options, making the test tasks take more time.

Anti pattern 4: turning everything into a user story

As a developers at Joe's Pizza, I want to deploy the next version of our shopping system when the shop is closed so that I don't disrupt the online shoppers.

The obvious problem with turning everything into a user story is that the extra layer added by the user story template ("As a <user role>, I want ..") is supposed to help the author describe end user requirements. When describing a bug or a simple task, this extra layer is misleading, because there aren't necessarily any end user requirements in sight and the team member taking responsibility for the "user story" doesn't need to analyze the requirements before starting.

About me

I've been working with IT and leadership of development teams since 1995 and created a scrum-like development process for my own company, Netropolis back in 2002.

Follow me here on LinkedIn or on twitter.