Most of the issues with gathering requirements in agile software development and agile testing derive from issues with User Stories. Somehow expressing requirements in such a simple form causes a lot of trouble to agile teams. Of course art of writing good User Stories is the most difficult for new teams starting with a new agile project or these, which freshly transformed development methods to agile software development methodologies. Mistakes made at that point lead to wrong Test Cases, wrong understanding of requirements, and the worst of all wrong implementation which can be direct cause of rejecting the deliverables of the iteration. Lets take a look at the five most common mistakes people make writing User Stories.
Introduction to User Stories
User Story is a short description of customer’s need. User Stories are commonly used in agile software methodologies and frameworks such as Extreme Programming or Scrum as a way of gathering requirements. Whenever possible User Story should be written by a customer otherwise it can be written by business representative in behalf of the customer or referring to a potential customer aliased as persona. User Story should be kept short and fit on 3×5 inches index card. The text on that card covers role of the user in the system, the need expressed by user and the benefit from implementing described feature.
The main purpose of using this tool is estimation of an effort needed to implement a new feature in software accordingly to the Definition of DONE for the team. User Stories also enable conversation that leads to extracting business and technical requirements and eliminating hidden assumptions. Sometimes they are mistaken with Use Cases and Use Scenarios, but the biggest difference is that they are much shorter and do not describe the application interface, steps or flows in the application. Implementation of User Story is confirmed by Acceptance Test being derivatives of Acceptance Criteria sometimes referred as Conditions of Satisfaction. For estimation at that level we use only points, ideal days or other unit representing size rather than actual time that needs to be spend implementing the feature. There is also simple template helping to make sure that all the elements are kept, “As who I want what so that why.” Here is the longer and more descriptive version of that template:
“As a <specific user/persona/role>” I what <desired feature/issue that needs to be solved>, so that <benefit from implementing the feature>” + Acceptance Criteria
Each of these elements is important and has a role in expressing and understanding the captured requirement.
The Five Most Common Mistakes
1. User Story for a User
Example: "As a user I want to be able to manage ads, so that I can remove expired and erroneous ads."
At the first glance you don’t see any issues with that User Story, because all the required elements are present. Now tell me who is the user for whom you are going to build that feature of ads management and what does he understand ads management? Is that a portal administrator, who wants to have possibly of database clean-up and ads moderation? Or maybe it is an advertiser, who wants to have list of all ads he submitted to the side and have possibility of removing ads when they are not needed any longer or there was error found in the content? As you may noticed, I mentioned only two different roles with different expectations from the system. I this case what is missing is persona or role mentioned.
2. User Story for Product Owner
Example: "As a Product Owner I want the system to have possibility of deleting ads, so that users have possibility of deleting ads."
And again, all three elements are here, but there is something wrong. First of all this User Story is type of ‘you want story, here you have one’. Obviously person writing this User Story did that only for sake of doing it. You can have a Product Owner as role of person using the system if you build software for teams using agile software development. That indicates issues with implementation of agile methodology in that organization.Second of all you have here exactly the same issue as in the previous example. There is no role or persona to give you clues about user expectations.
3. User Story for Developer
Example: "As a developer I want to replaced the folder widget, so that I have maintained folder widget."
This typical example of Story for a Technical Backlog or technical requirement representation. Sometimes User Stories like this one are also part of so called technical debt. Technical debt consists of necessary maintenance tasks like software updates, re-factoring, changing frameworks and so on. They are totally rightful to be implemented, but represented like in the example above they do not represent value for the customer and you will not get a buy-in from Product Owner. Also from the ‘agile point of view’, you need to deliver a business value at the end of every iteration and the team needs to be able to present it to the stakeholders on the review meeting. How to write such a story correctly? Rewrite it from a user point of view with persona on role.Example: ‘As a commercial user I want the system to allow me run multiple searches at the same time, so that I can do my job faster.’ Task to go with it can be: ‘Re-factor search handling mechanism to allow multiple threads for single user.’, ‘Update java version to 64-bit one.’ Acceptance criteria need to define some measurable and testable definition of improvement like: ‘Single user can run 5 searches at the same time.’ and ‘Search returns results in less than 4 seconds.’
4. No Business Value or Benefit for Customer
Example: "As an commercial advertiser I want to have filtering option."
We have the role, we have the need, but reason and business value are missing. Why does an commercial advertiser want to have filtering option? What does he want to achieve?
5. No Acceptance Criteria or Conditions of Satisfaction
Here you can use as an example one of the examples above. The problem in such practice is often underestimated. Not having Acceptance Criteria sometimes referred as Conditions of Satisfaction can cause the whole chain of mistakes starting with wrong definition of development tasks or wrong estimation. Story can failed the tests or Test Cases will cover different criteria due to lack of understanding. Acceptance Criteria pay great role is confirmation of requirement understanding and decide about acceptance of iteration deliverables. Conditions of Satisfaction question the User Story enable conversation between the Product Owner and the team. Good way of gathering Acceptance Criteria is asking questions such as ‘What if … ?’, ‘Where …?’, ‘When …?’, ‘How …?’. Use examples and simple drawings to remove assumptions. It can happen that Story needs to be refined and re-planed or quite often split to smaller stories.