Tips for Planning User Stories

= 1. User is #1 Priority = Since the user story involves a scenario of the application in use based on the users’ perspective, it makes total sense to make sure that they are the ones who will benefit. You should not write user stories if you do not have a good understanding on who will use the application. The relationship between the user and the product is what makes up the user story.

= 2. Use Different Perspectives = A key to making sure that no user is left out is to make stories based on different personas. They are fictional characters based on the knowledge of the target user. Things to consider in creating these personas is characteristics, behaviors, attitudes, and a goal.

These help in determining the right functionality of the product. They should make it easier to meet the users’ goals.

(romanpichler.com)

= 3. Start with Epics = Using an epic, or big broad stories, helps in creating smaller chunks of stories. The epics can be broken down into as many user stories that will help in determining the functionality without worrying about the details. “It is helpful for describing new products and features. It allows you to capture the rough scope, and it buys you time to learn more about how to best address the needs of the users.” (Pichler, Roman).

This also helps with the time and effort allotted to the new functionality. Having a specific user story in the backlog can cause some hiccups along the way wasting time and resources as also risks adding inconsistencies.

= 4. Refine the Stories = By breaking down the epics, the stories that remain are clear, feasible, and organized. You can put them onto paper and transfer all the user stories that are completed to the backlog. You can split the big, coarse grained epics into small, specified user stories that becomes effective in determining requirements.

(romanpichler.com)

= 5. Do Not Rely on User Stories = User experience relies on more than user stories. It is not useful in determining the user journeys and the visual design. They should be used to supplement any concerns with how the user interacts with the product. They are also not well suited for technical requirements. Determining the technologies involved does not need to rely on user stories at all.

Writing stories may not be necessary for quick mockups or prototypes as a proof of concept. Rather they are used for software that’s developed to likely be used again. The main idea about user stories is that they enable speedy mobility to develop the software quickly, and not to force any costs.

