Is this user story substantively correct:

As a system owner, I want everybody that uses the system to have to log in using a secure password and login system, to prevent unauthorised and random access to system data.

And then:

As a user, I want to be able to log in with my secure password, so that only I can access areas of the system I need to do my work.

I have several other stories for the system owner, like password format, lockouts etc. Is this a good place for these requirements? As stories for the system owner?

4 Answers 4


I (as a user) are always angry about passwords - they need to be too long, they need to be changed too often, they need to be too different (across systems), etc. etc. So my user story would go like:

As a user, I want quick and hassle-free access to my system. 

If you have really considerate users, who are worried about security and traceability, you might add:

As a user, I want to be sure that nobody without permissions can fiddle with my data. 

I guess that is as far as any user goals would go. Passwords are not supporting any user tasks, they are supporting system administration goals, and thus should only go into stories for the "system owner", where you already have them.

  • IMHO putting passwords in the stories for users is ok, since the story decribes an interaction of the user with the system. Thus I would not put those stories into the list for the "system owner", instead I would avoid the "I want" form.
    – Doc Brown
    Jan 9, 2014 at 11:35
  • I prefer your second example, and the user needs their login account and to enter a password to ensure nobody fiddles with my data, so keep the password in the user story, but minimise its impact. Requirements for password format etc. belong in system owner stories.
    – ProfK
    Jan 9, 2014 at 11:58

Consider not to stick to the "I want" form for this kind of requirements, since as we see from the other answers, the difference between "what the user wants" and "what the system owner wants how the user should work with the system" may be a cause of misunderstandings. The important parts of a user story are the parts describing the "who", "when/where", "what", and "why", the "I want" is just an exchangeable template.

As an example:

A user when starting to work with the system has to log in with her secure password, so that only she can access areas of the system she need to do her work.

This is formally a correct user story, just as yours. If this story describes your requirements correctly, or if it is on the correct level of abstraction for your case, is a different question.

  • 1
    Not arguing for or against, but I've seen "I want" part in a number of blogs/books on writing stories. Here's one of many examples: mountaingoatsoftware.com/blog/…
    – DXM
    Jan 9, 2014 at 16:31
  • @DXM: don't get me wrong, in 99% of all cases "what the user wants" is exactly what a system should do (assumed the user knows what he wants, but that's a different question ;-) ). So most times the "I want" form is fine. Its only the "password" situation where this does not fit very well.
    – Doc Brown
    Jan 9, 2014 at 18:54
  • As a plus, we teach our users what they want. I work for a large, international security company, and while we allow plenty of room for customisation plugins, we decide how secure the system must be and what it does.
    – ProfK
    Jan 11, 2014 at 15:24

Whenever I read a User Story, my first question is "Really?" I put myself in the role of the User and ask "Do I REALLY want that feature". Security is one of those areas where User Stories are often written from the perspective of the user of a system but, as others have pointed out, they don't want to have to login, or create complex passwords. They just want to get to their stuff and have their stuff protected.

As well as asking the "Really?" question, I look to see if the User Story demands a particular solution. Security is, once again, a great example. Most User Stories do seem to insist on requiring passwords. But why? I like to write User Stories such that I give the developers room to consider alternatives. By doing this, we create an environment that encourages innovation. A good thing.

So, here's what I'd like to see:

As a New Member I want to create an account quickly and easily So that I can access Member Benefits

or maybe:

As a Current Member I want my personal information kept private So that I can maintain my privacy

Finally, if the "As a ... I want ... So that ..." template isn't helping you, feel free to use something else but I'd advise that you understand the reasons why (and "It's too difficult" is probably not the best answer :)


Users never really want restricted access. I would include access restriction as system owner (also commonly referred to as "product owner") stories. Depending on how much access control is required, you may even want to specify the who and what in individual stories such as:

As a system owner I want only managers to be able to create new employees. 

Avoid specifying solutions in your stories such as describing how the roles are defined or retrieved.

I wouldn't have stories including details such as password format criteria (validation), this should be acceptance criteria for a story about registering new accounts.

Lockouts seems like a good candidate for a system owner story.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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