How to keep CRUD user stories from being trite and simplistic?

Question

I'm having trouble keeping my user stories for basic operations from sounding ... basic. For example, suppose I'm building a CRM to keep track of clients:

• C: As a user, I want to create a client, so I can ... keep track of my clients?
• R: As a user, I want to view my clients and their properties, so I can ... know what's going on?
• U: As a user, I want to change my clients' information, so I can ... not use outdated information?
• D: As a user, I want to delete a client, so I can ... not have old clients lying around?

It seems like there are lots of reasons to want to perform CRUD operations on your objects, the primary reason being a kind of obvious "just because" reason. I suppose I could just pick one reason. For example:

• As a user, I want view my clients and their properties, so I can sound knowledgeable when they call.

But there are many, many more reasons why I want to view my clients. It would be tedious to enumerate out every reason why I would want to look up a client, and even if I tried, I probably still wouldn't be able to think of every reason.

How do you write user stories for basic operations?

Answer 1

Your reasons ("So I can ...") are too vague.

"Keep Track of my Clients" is not a requirement; it is a wish. Make your reasons more specific. A genuine requirement is always accompanied by a test that, when the test is performed, allows unambiguous declaration of success if the test succeeds.

Tedium is not a good excuse for not writing detailed requirements and specifications. You say there are many, many reasons why you might want to keep track of your clients? Enumerating those reasons will ultimately make your software better.

CRUD doesn't make good user stories.

Good applications are not just Create, Read, Update and Delete; if that were true, we could auto-generate every new application from a database schema. Good applications perform recognizable business operations like "make a sale" and "reconcile this account." They embody actual business processes and workflows. So should your use cases.

The same can be said of your application architecture. Many systems expose a CRUD model to the client, but sometimes it's better to expose the actual business operations in a Service Layer instead, and let the Service Layer make the necessary CRUD calls.

Answer 2

Your User doesnt want these things. Your User wants a website that they can enter client details on with shiney buttons and all sorts of sparkely UI goodness.

The Developer wants to implement that via a CRUD interface.

Try to make user stories from what the user would actually say. ie

"As a User I want a Save Button which will store the Client Details so that I can View them later"

This will spawn a whole load of sub tasks

"Add save button to client detail page"
"Create Client Database table with fields..."
"Create API for Client DB with Create action"
"Add java script to savd button so that Api is called"

etc

When all the task are done, you can look back at the user story and say... OK did all of that stuff actually deliver what the user wanted?

To do that the reason has to give the developer enough information so they can tell when their solution falls short of the users needs.

But it also has to be short enough so that the User can express it without an extended Business Analysis process

So "So I can evaluate client data" isn't enough.

And "So that I can see fields X, Y and Z with character limits a, b and C in fonts I,J and K" is too much.

The right size will depend on how knowledgable the developers are on the subject matter