There is no such thing as a perfect a user story. There is a spectrum of quality, from bad to good. And user story quality can be assessed against at least 10 criteria. I investigate here a single user story relating to a common scenario – the login process – and see how we can move along the quality line.
Authenticating with a software application, or logging in, is found in almost every software application. It’s such a common feature that most developers will try to reuse code to implement this functionality. Yet how often do we think about re-using the requirement? And how big and complicated is this functionality? And what does it actually mean when we login? In this article we will explore these questions and end up with a set of (good quality) re-usable user stories.
A well formed user story will avoid unnecessary discussion, reduce rework and shorten development time significantly, so it is worthwhile to spend time getting the words right.
Let us remember that a user story is written by and for a number of readers for more than one purpose. The two main messages that a user story should convey are are:
- What functionality needs to be developed and who it is for. (who and what)
- To help readers understand why this important (why)
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 found this useful, please comment below.