DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
View Events Video Library
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Integrating PostgreSQL Databases with ANF: Join this workshop to learn how to create a PostgreSQL server using Instaclustr’s managed service

Mobile Database Essentials: Assess data needs, storage requirements, and more when leveraging databases for cloud and edge applications.

Monitoring and Observability for LLMs: Datadog and Google Cloud discuss how to achieve optimal AI model performance.

Automated Testing: The latest on architecture, TDD, and the benefits of AI and low-code tools.

Related

  • Linking User Stories to a Data Model: A Tutorial for Agile Development With Jira and ERBuilder
  • The Trouble with User Stories
  • Realizing User Story With Storyboard
  • Code Review for Software Quality

Trending

  • Effective Tips for Debugging Complex Code in Java
  • Parallelism in ConcurrentHashMap
  • Send Your Logs to Loki
  • Deploy a Session Recording Solution Using Ansible and Audit Your Bastion Host
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. The Anemic User Story

The Anemic User Story

Marco Behler user avatar by
Marco Behler
CORE ·
Jun. 10, 15 · Interview
Like (0)
Save
Tweet
Share
3.12K Views

Join the DZone community and get the full member experience.

Join For Free

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. The article will be published on our blog soon. Stay tuned!

User story

Opinions expressed by DZone contributors are their own.

Related

  • Linking User Stories to a Data Model: A Tutorial for Agile Development With Jira and ERBuilder
  • The Trouble with User Stories
  • Realizing User Story With Storyboard
  • Code Review for Software Quality

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: