After meeting with stakeholders and potential users to gather/elicit a product’s requirements and organizing them using the MoSCoW framework, it is necessary to communicate these requirements to the team in a way that is easy enough to be understood by stakeholders, developers, and even users.
A popular approach across agile development practices is the use of user stories for listing the requirements of a project. A user story is a feature request (or need) expressed from the point of view of a user with a description of the value it provides to that user. To create a user story, you will need the persona which is the target audience of your product and the list of requirements that you got from all the stakeholders. Then, the format for listing these requirements is the following:
As a [PERSONA | USER], I want to [BEHAVIOR | ACTION] so that I can [BENEFIT | VALUE]
Using this template, we can create the following User Story :
As a teacher, I want to post announcements so that my students know the changes and recommendations I make to the class during the semester.
INVESTS Model for User Stories
When creating User Stories, it is recommended to use the INVEST model to make sure that each user story is small enough and clear enough for the understanding of everybody involved. William C. Wake promotes the use of the INVEST acronym for the characteristics of a good user story.
Independent
A user story should not be dependent on other user stories. Avoiding dependencies between user stories helps the requirements be arranged based on priorities instead of dependencies. This means that you will be able to deliver the features with the highest value first. For example, you might have a high-priority story depending on a very low one which would force you to work on this low-priority one before you can deliver real value to the users.
Negotiable
User stories are not the final version of the requirements. They should have enough details to start the conversation between the product owner, client, and developers. Once the user story is written, developers and the product owner/manager can discuss what is the best course of action to take to meet the user’s needs.
Valuable
User stories should provide some value to the users. They should solve a problem or meet the users’ needs. The value is what decides the priority when creating and taking user stories for the developers to build the software.
Estimable
Developers should be able to estimate the time or story points that would take to implement the requirement of a user story. With the time estimate, developers can predict how much work/user stories can be completed during a sprint. Further, there are some instances when developers cannot provide a time estimate of a user story. Developers might not understand fully the user story, they might lack domain or technical knowledge to complete the user story. Another reason for not being able to provide a time estimate is that the user story might be too large and it should be broken down into multiple user stories.
Small
A user story should be small enough that it can be developed within a sprint. Usually, a user story takes no longer than several days. When a user story is considered too large, it is called an epic and should be divided into multiple user stories.
Testable
All user stories must be verified against some criteria and meet the definition of done so the team knows that the user story is meeting the user’s needs. They should have acceptance criteria that will allow the team to test the user stories.
Some Observations
- User stories should be short enough to fit into a post-it note or an index card.
- At the back of this index card, you can list the acceptance criteria for the user story.
- The user story by itself is not a direct requirement set in stone. It is used to start the conversation between the product owner/manager and the developers to find a solution for the user problem that needs to be solved.
- User stories are about clearly communicating requirements and their value.
- Stakeholders might create user stories, but it is the responsibility of the product owner.
