In order to prioritize the development tasks in Scrum, it is very common to use user stories. User stories describe a certain action by the user of the software that has business value, and thereby help the team visualize and strive for the end result as well as prioritize tasks that lead to that result.
User stories can take several forms. According to Mike Cohn, the most common one describes an action by a user, and is written as follows: “As a [role] I can [function] so that [rationale]”. Other common forms include description of the user story as a noun – “[Function]” – or as a testable assertion – “[function] is available”.
When writing user stories, it is important to follow several guidelines to make them effective. Below is a brief overview of factors that make user stories work well for agile development purposes:
1. Be valuable. User story needs to describe an action that is valuable to a specific user. If there is no inherent business value in a user story, it does not provide a rationale for a certain action and therefore is not particularly useful for the development team. For example, a user story “The user is to be able to hover the mouse over a button.” carries no rationale or inherent business value, and therefore is ineffective. A much better version is “The user is able to make the payment in no more than three steps”.
2. Target a specific user. A common trap in writing user stories is targeting no one in particular. If you are running a business for a certain type of customers, it makes sense to explicitly state these target customers and the value they will be able to derive from using your software. For example, a CRM software company could have the following user story “As a person, I can purchase the software on the website”. This gives little information on how the purchasing process should look like. A much better version is “As a corporate purchasing manager, I am able to purchase the CRM software online with my corporate credit card and install it within 30 minutes.”
3. Have clear acceptance criteria. In order to understand whether the tasks have been completed, it is important to specify exact acceptance criteria for a user story. Therefore, vague user stories can paralyze the team, not yielding any tangible results. It is often tempting to have user stories that are abstract – e.g. “As a user, I enjoy the purchasing experience.” Such user story does not give much guidance on what tasks should be implemented in order to achieve that, and therefore is ineffective. It can be solved by making the user story more precise “As a buyer of books, I am able to find and purchase the book with no more than five steps.” Also, acceptance criteria can be specified to make sure that the user story is implemented – such as “The purchasing process supports Visa, Mastercard and Maestro.”
4. Be testable. After the tasks related to the user story are accomplished, it should be easy to test whether the user story is implemented or not. A good example of a testable user story is “The app shows user’s current location on the map.” On the contrary, a bad example of a user story is “The app looks appealing to the users”. In some cases, it could be possible to aim for abstract user story – but then it has to be accompanied by a test, such as “Over 50% of the surveyed users indicate that the interface of the application is appealing.”
5. Be small. User stories need to be small enough to be implemented within the sprint – depending on the process in your company, it typically means implementable within a week or two. Therefore, a user story “As a user, I can access my software on iPhone, Android and Windows Phone” is not particularly useful if you are just starting to develop the mobile version of your application. Instead, try to limit the user story to what is achievable during the sprint: “As a user, I can access the scheduling function of my software via a mobile web browser.”
6. Be described concisely. Finally, the description of the user story should ideally be short and clear – so short that you can actually have it written on a post it note, or in an agile tool like Eylean.
Do you have any further tips on how to write effective user stories for Scrum? Share with us in the comments!
