Before we write the user stories of the TaskAgile applications, let's go through some tips on how to write effective user stories:

• Tip 1: Write user stories in the following format if you can:

As a <type of user>, I want to <do something>, so that I <get some benefit>.

That is a user story that basically consists of who, what, and why. However, don't force your stories into this template if they do not fit. And you don't want to stick with I want to, you can choose other phrases, such as I can or I'd like to, as you see fit. For example, the following is a user story of TaskAgile about user login:

As a registered user, I can use my username or email address with the password to log into the application.

In this user story, you don't have to write the so that part because the reason you log into the application might be that you want to check tasks in progress or create a new team. It wouldn't make sense to put all of these into the so that part.

• Tip 2: Make sure that user stories can provide end-to-end functionalities to users. For example, if one user story is about filling out the registration form and another user story is about creating the user account with the details provided in the form when the first user story is finished, users won't be able to actually perform the registration action. It doesn't provide a functionality that can let users accomplish something.
• Tip 3: Keep user stories small and feasible. User stories need to be small enough so that they can fit into an iteration during the planning stage. When a user story is too large, it usually means that there are undiscovered details and developers usually cannot implement it directly. For example, in TaskAgile applications, there can be a user story like this:

As a board member, I can manage cards.

This story is too large because there are many details regarding how to manage cards that are not specified. On the other hand, when a user story is too small, it won't be able to provide a useable functionality to users, like the example mentioned in tip 2.

Large user stories are epics, and they should be broken into smaller stories. For example, the preceding user story can be broken into the following stories:

• As a board member, I can create cards
• As a board member, I can archive cards
• As a board member, I can move cards between card lists
• As a board member, I can change card positions
• As a board member, I can delete archived cards
• Tip 4: Add acceptance criteria to user stories. Acceptance criteria, or conditions of satisfaction, provide additional details to user stories. They are the conditions that will be true when the story is complete. For example, the following is a TaskAgile user story about user registration:

As a visitor, I want to register a user account with my email address, username, and password.

The acceptance criteria is as follows:

• The email address must not already exist in the system
• The username must not already exist in the system
• The password must be at least six characters
• The password must contain at least one number
• The password must contain at least one letter

If you use a paper card for writing user stories, put these conditions at the back of the card. Make them no more than five items so that they can fit in one card. And when you implement this user story, these conditions should be included in your automation test.

• Tip 5: Avoid including user interfaces in user stories. There is a tendency to add user interface-related details to user stories. For example, in a user management system, there can be a user story such as the following:

As an administrator, I want to click the Open Filters button to open filters so that I can use the keyword field and date selector to search users by name, email address, and registration date.

In fact, a user interface is more like a specific solution to a requirement, rather than the requirement itself. It is better to change the preceding user story to the following:

As an administrator, I want to search users by name, email address, and registration date so that I can find a user quickly.

• Tip 6: Use themes to group user stories. A theme is a collection of user stories that share a common attribute. For example, we can use a theme named Cards and group all the card-related user stories in this theme. Themes are a way to organize your user stories.

• Tip 7: Use short titles instead of numbers to reference user stories. When the team has discussions about user stories, it would be confusing to reference cards with numbers. For example, Let's discuss story 39. And then everybody else has to think about what story 39 is about, and every time the name story 39 pops up, people need to do the translation. The discussion will be much easier when stories have short titles. For example, story edit card title is much better than story 39.