0

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?

  • 1
    It seems you lack knowledge of the domain. Have you talked to end users to find out what they want and why they want it? – Rik D Dec 4 '18 at 21:30
4

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.

  • I appreciate the feedback. User stories usually give a single reason. Supposing I still went with CRUD user stories, is it acceptable to have a long bulleted list of "so I can" reasons? If not, how do I enumerate my many, many reasons for wanting to view? – Travis Dec 4 '18 at 16:05
  • Your source of truth for your software's design is still your software requirements and design specifications, not your use cases. I view use cases as a "brainstorming" or "prototyping" tool; you won't be referring to them when you write the software, except perhaps for completeness reasons. (i.e. "did we make this feature-complete?) – Robert Harvey Dec 4 '18 at 16:09
  • 1
    Ergo, despite my answer, I don't believe you have to have an exhaustive list of reasons. The reasons just have to be representative of your needs. – Robert Harvey Dec 4 '18 at 16:10
3

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.