When we are practicing Agile, we don’t use comprehensive documentation, instead we create user stories. User stories are by definition a conversation between the user and the development team. Basically we convert the user requirements to User stories. So these requirements must fall into the INVEST acronym.
I – Independent: Should be able to execute it without any dependency to other features.
N – Negotiable: Requirements are not contracts or promises, because there are too many details to be discovered to actually understand the problem.
V – Valuable: Should be valuable to the end user, i.e. expressed in a way that is easily understandable by the end user.
E – Estimable: These are used in planning and if the team lacks the domain knowledge or if the item is too large to be estimated then it does not meet this criteria.
S – Sizable: The item should be easily fit into the coming up iteration. If it is too large to be included then it has to be broken down to much smaller items
T – Testable: Ability to define the acceptance criteria for the requirement.
So how can we write effective user stories? Following are some guidelines that I follow when creating user stories.
- It should be a short description of a single functionality
- Make sure it is small as much as possible so that it is valuable, estimable, sizable and testable
- The user story must contains the three parts by definition: as a [user] , I want [functionality] , so that [benefit]
- All three parts of the story must be clearly defined, the person, the functionality and the benefit.
- Using “user” as the person is bad practice. Specify the actual user.
- Some argue that the benefit part is optional but try to complete it as well. For me a user story with a specific benefit is much meaningful.
- Must include the acceptance criteria which is the basis for functional testing
When companies move from traditional methods to agile methods they tend to write very long user stories which are expanding to paragraphs, even into several pages. We call these Epic User Stories. So during planning sessions we break down them into much smaller stories where the development team can easily implement.
In non-agile methods they produce very large specifications upfront, even before the developers produce their work. In agile methods user stories replace these lengthy specs. There are scenarios where organizations take these lengthy specs and break it into user stories, but according to my understanding it is waste of time. It is a best practice to write user stories to cover the core functionality of the software upfront and make sure it covers 3 to 4 months of work for developers if it is a large project.
Lastly remember a user story do not need to cover tremendous amount of details upfront. As mentioned above the user story that you create initially should facilitate a conversation between the user and the developers. When a user story is written the development team may have lots of questions and when these questions are answered the users or the proxy may write sub user stories which will give more follow on information. So ideally the user stories should not be written in greater details upfront, rather keep shorter to facilitate the conversation. Bottom line is encouraging this conversation so that the development team knows what they are doing.
You will know your user story strategy is working when your team have tremendous amount of conversations rather than writing tremendous amount of user stories.