For the login user story, you might start with this:
As a user I want to login.
But this is a poor user story and we will explore why. This leaves a number of questions unanswered, like what does “login” actually mean. What does “user” actually mean? We might all think we know, but the truth is a lot might need to take place behind the scenes, when logging in. Let’s look what might actually happen when we log in to a web application.
A Login Scenario
Here is a typical successful web login scenario:
- Enter a username and password. The username is most often the user’s email address.
- Click submit, the username/email is searched. If found,
- an encrypted version of the password is then compared with the stored encrypted version.
- The profile is updated with the latest login date time.
- The system performs a lookup of groups (or roles) and group memberships,
- Finally the user is shown a screen that they are entitled to see based on the outcome of the previous steps.
Now this is a fairly basic scenario, the login process can get much more complicated, for example it could involve federated authentication services, event logging and more, but let’s stick with the simple one for now.
The English language has over 150,000 words we might use, and virtually in any order, so the alternatives are virtually endless. The purpose of the story is to communicate, and there is no need to be complex if we can express it simply. This is just one version of what the user story might look like:
As a registered_user I can authenticate against my profile.
The system should also lookup my group_membership.
It should also retrieve the group
[information to determine what features I am permitted to access].
A use case model diagram created by ScopeMaster:
Here is the detailed analysis performed by ScopeMaster:
The use of squared brackets tells ScopeMaster to ignore some text when determining functional meaning.
As you can see, the functional steps are determined and these are then mapped to Data Movements (the unit of the COSMIC Function Point).
So this version of the story is much better because it is:
- User oriented (registered_user presumes that they person should already exist).
- Concise (un-detailed, referring only to object types, not their individual properties)
- Complete (describes all the key functional steps of this user story)
- Sizeable, at 9 COSMIC Function Points.
- Unambiguous (successfully mapped to functional steps)
- No design (it does not specify how it should look nor how it should be coded).
Further considerations. Alternative Paths (Negative tests)
The other paths also need to be considered within the context of this story, and should probably be added separately as success criteria:
- My user id is incorrect – display an error message
- my password doesn’t match – display an error message
- my password has expired – display an error message
- my account has been disabled – display an error message
- I can log in but I am not a member of a role with any permissions – display an error message
Related User Stories
Now that we have covered the basic login user story, we might go on to create stories for the following.
- Forgotten password
- Change my password.
- Store a cookie to remember my identity
- Administrator can trigger a reset of my password.
- Register as a user
- Administrator can register me on my behalf
- Synchronise or share my id with another authentication system (e.g. Facebook)
These will be the subject of future articles, so stay tuned.
I hope you have found this article useful. Now I suggest you take a look at 10 Tests for Writing Great User Stories