The user story is one of the primary development artifacts for the agile project teams. A user story contains just enough information so that development team can reasonably give an estimate about completing, a tester can discuss how it will be validated and a customer can see its value.
One of the common questions that we hear most of the time is, how user stories are different from use cases. User stories are much simpler than use cases. User stories are very easy to create, discuss and develop. They also do not contain any technical details.
Typically good user stories are defined in the following format
As a <<USER>> I would like to <<DO SOMETHING>> so that <<I CAN>>
While discussing User Stories, you should make sure that they are not very big. A big user story leaves the chances of ambiguity and absence of clarity in the mind of the development team. Ideally, you should be able to break user stories so that it can be finished by two persons in a week’s time.
If you are working as a tester in an agile project and see any story taking longer to finish, consider this as an opportunity to ask questions and see if this can be broken by functionality or platform or in any other way.
Once a story is broken to the last level, this story is assigned some points based on how long it will take a pair of programmers to finish it. These user stories are then broken down in the tasks and assigned to appropriate developers. Typically in the start of a project, you create a deck of user stories and for each iteration or sprint you choose stories based on their priority and time it would take to complete them.
User stories are often written on the paper medium like index cards or post-its. This also ensures that there are no unnecessary details on the user stories. Once development team decides on the stories that will be developed in a sprint, it is further divided into tasks and resources are allocated accordingly.
Most of the time, these user stories are defined only in acceptance term. For example,
As a user I should be able to register with the site so that I can receive newsletter is a good example of a user story. As a tester, it should be your job to find out negative scenarios and assumptions in this story. For example, what information user should provide to register? Are there any distinctions between optional and required information? Should we validate email address of user before registering?And many more such questions can be raised about this user story.
Remember, one of the main reason for using user stories is to have an invitation to further conversation. According to Ron Jeffries, every user story in XP have three components –
- Cards (Physical Medium)
- Conversation (Discussion Surrounding them)
- Confirmation ( tests that verify them).
One of the widely used acronyms for good user stories is called INVEST. Getting right user stories is essential for the success of any agile project and hence this acronym INVEST is used to justify the investment that you make in creating user stories.
According to this acronym,
- I for independent
- N for negotiable
- V for valuable
- E for Estimable
- S for small and
- T for testable
As a tester in agile projects, it is very important for you to make sure that every story you work on conforms to the characteristics defined by these terms. There are good reasons for doing this.
Stories should be independent so that it is easier to plan them. Consider the situation when you need to decide stories to be included in the Sprint and most of the stories are dependent on each other.
Stories should be negotiable, user stories are not contracts with the customer they are a platform to clear understanding between everyone involved. Anyone should be able to challenge its intention as well as implementation.
User stories should be valuable. It is possible that your stories will not bring direct value to your customer, but it should bring value to someone, it could be developer or tester. For example, As a tester, I should be able to access application below UI layer so that Automation is not dependent on the UI, is a good user story as it adds value to the tester.
Stories should be estimable, remember we are not saying accurate estimate, but it should be
a reasonable estimate. Since stories are negotiable, these estimates can change, but initially, it should be possible to estimate reasonable on how much time it would take to complete a story.
Most of the characteristics defined above make sure that user stories are clear and small. This is very important, most of the time big stories are also vague. It is also possible to keep the team moving with smaller stories as it gives a sense of accomplishing or finishing something.
Since user stories are requirements which drive the development you should make sure that these stories are testable. You can find this by looking for some characteristics like ambiguity, clarity etc which you might have used in the verifying requirement in traditional development model.
Remember, user stories are the crux of agile software development methodology and as a tester, you should make sure that your team INVEST in user stories.