I have an issue at work where we have just started using scrum as a development team. I am having some trouble with the user stories we are provided with in that they don’t seem to fit what my interpretation of what a user story is.
Here is an actual example of the user stories we have been given for this sprint:
-
As a website user I want to have a registration page so that I can register and supply my details.
-
As a merchant user I want have validation on the registration form so that I provide the correct information. (This relates to Form Validation)
-
As a merchant user I want support when registering so that any questions that i have about the required details are answered. (This relates to Tool tips on the form)
The first one in my mind is the user story. The second two seem to be traditional requirements of the first user story and I think they should probably be acceptance criteria of the first user story.
The other confusion I have is in the last sprint we had:
-
As a user I want to be able to login to the website.
-
As a user I want to be able to login to the website with a username.
The Product Owner says this is two different user stories which need to be tested separately.
My issue is that in creating test cases and acceptance criteria for the second two – it is difficult as they are so specific and so related to the first user story. It seems that we are just putting up traditional requirements on a card up on a board and calling it something else. I mainly just want to know if I am wrong about this / why?
It just seems to me that we are currently just letting the users create whatever they want as a user story and not helping them filter them from requirements into proper user stories. I am told we need to keep them all separate for reporting so we can keep a log of everything the user requests.
[Emphasis mine.]
Since neither provides any customer value, neither are user stories.
You use application software to manage information, make decisions and (ultimately) take an action. If the user story doesn’t provide some hint as to what information, decision or action gets taken, there’s no customer value, it’s just technical folderol — implementation details that a customer has to endure to get to the interesting part of the application.
Login, specifically, has zero customer value. It’s a roadblock that IT erects between customers and the valuable information they need to make decisions and take actions. It’s a security mechanism, and most people do not actually like security. Security is imposed on customer by IT. The most popular password (IIRC) is "aaaaaaaa". Why? Customers don’t like security.
Detailed, microscopic login user stories may be a symptom of failing to see the real value to the customer.
Good.
Not a bad plan, really.
The issue is to separate "crap the user happened to say" from "stuff that makes sense that we can build". It’s very, very important to allow the users to say any crap they want to say. It’s a good thing to let them ramble.
Periodically (before each sprint) you will prioritize crap the user said into a few things that (1) you might be able to build during the sprint, and (2) create the most significant and dramatic user value you can possibly create. Some stories will get ignored. Some will be low priority. Some will be combined and some will be split. Some things the user said will be contradictory. Some will be outright lies. Some will be incomplete. It’s all good. It’s just crap the user happened to say. Not divine directives from the mouths of the gods directly to you.
This revised set of user stories drives the sprint. Now you start collaborating with the users to get the details, write test cases, define acceptance, etc., etc.
As you’re sprinting toward delivery, the users can continue to say crap that will get appended to the backlog of unimplemented user stories. It’s very, very important to allow the users to say any crap they want to say. It’s a good thing to let them ramble.