The Anemic User Story

June 02, 2015 - Marco Behler

Ever been assigned a user story which looks like this? (Taken almost verbatim from a real life customer project some time ago)

Headline: Improve Pagination

Description: As a user I want to have proper pagination functionality so
I can scroll through my item list without a long loading period

Acceptance Criteria: It is possible for a client to implement a proper pagination

Do you know what the hell you are supposed to do here? No?

Good, me neither. A classic example of an anemic user story.

How do I spot an anemic user story?

As a rule of thumb: If you look at a user story (or feature request or task) one day after it has been written and you have literally no clue what exactly to do, you have an anemic user story.
Imagine you got the story above from one of your colleagues who went on vacation. Feel like joining him immediately, huh?

Absence of length is also a very good indicator: One or two-line user stories like "implement the new text processing logic", which literally could mean anything.

How do anemic user stories surface?

Anemic user stories or requirements in general are almost always "shot from the hip", often under pressure. Your boss shouts over "uuh, pagination takes too long, have a look at that urgently."

Now, you might have an idea why pagination for your e.g. shopping basket is so slow. But there is 100 more pressing tasks and so you decide to take a shortcut and come up with that anemic placeholder story instead. I mean you roughly know what to do, right? Customers will be able to live with slow pagination for a couple of more weeks.

And then some time you finally come around to implement the story. Chances are very high that you will go like: "Erm, what am I supposed to do again?"

Why are these stories such a pain?

There are mainly three things that go wrong with stories like that: You do not know

• what to implement exactly
• therefore you do not really know when you are finished
• and you certainly cannot properly estimate stories like that.

In short: A developer's dreamland!

The problems with this specific story

The headline is about "improving" pagination, so pagination seems to be in place, but is supposedly too slow. (Mental Leap: check this link for those interested in a technical solution if you are fighting with SQL pagination)

The description is your general vague user story resulting from "agile" brainwashing saying that everything consisting of "as...I want to do this.." is good enough as a user story. It is not.

Additionally, the acceptance criteria says something about "clients". And "implementing"? What the hell is that supposed to mean? Could it be that we should actually expose parts of our API for other e.g. third-party REST clients and that we promised them some specific response times in an SLA? And we maybe need to improve our current response times by 10% for that? For which calls? For all of them?

Fighting the anemia

If you encounter a story like this in real life you have to delete it and rewrite it. No really, hit delete in JIRA or equivalent tool. The story will not be of any use for you or your programming team. When you finally rewrite the story, take the following steps:

First Step: Asking Questions

See the questions that came up in the last paragraph? We already talked a bit about asking the right questions a couple of weeks ago. To write a proper user story, you need to ask questions - except if you have every little detail of the story already sorted out in your head.

Next Step: Outlining

As with all writing, from books to movies to technical user stories it pays off to have an outlining system in place. You should not make the wrong assumption that writing a user story is done in 2 minutes and you can just bang them out one after another.

You need a bit of dedicated time and then your quickest way forward is to outline the user story and only then write it. As opposed to trying to fill a blank JIRA page with everything that comes to your head regarding one specific feature.

Last Step: Writing the User Story

When you have the outline in place then fleshing out your story in detail is almost just a formality.

But I do not have time for this!

I can assure you that in any software team with size 1+ anemic user stories will take up a lot more time in the long run, than spending 5 minutes on some questions, outlining and then writing a sound user story.

But feel free to take "shortcuts" if you are into having constant debates with your boss,clients or teammates about what to implement, whether it was the right thing to implement and when it is done.

Next Step

In the next article we will first look at what this anemic pagination user story should have looked like. Then what the outlining and writing process for this new, good version of the user story were. Stay tuned!

As always, if you liked this article, join our newsletter below!