Have you been notified of a new project assigned to your team and you’re not sure where to begin? Have you ever felt lost trying to understand the obscure jargon of your business domain? One way to overcome this development obstacle is to create user stories.

What is a user story? As per Atlassian: “A user story is an informal, general explanation of a software feature written from the perspective of the end user. Its purpose is to articulate how a software feature will provide value to the customer.” In short, user stories are simple user perspective tales describing at a high level the user’s interactions with the product. They are generally 1 to 3 sentences per story and typically describe the benefits a user earns when they take a particular action within the application.

Creating user stories will likely require cross organizational collaboration with the non-technical users of your product. The goal here is not to create the user stories in the silo of your development team, but rather to work iteratively with the end users, project managers and project stakeholders to flesh out what it would be like to use an idealized version of the product. The earlier you start these stories in the project process the better the chances your project team will end up with something like the idealized product. And as a result of creating the user stories, your team will gain a better understanding of the context of the business domain the product resides in.

What makes a good user story? As per Lara Letaw’s Handbook of Software Engineering Methods, good user stories follow the INVEST characteristics:

1. Independent – doesn’t rely on other user stories to make sense
2. Negotiable – not tied to a specific contract and can be changed during development
3. Valuable – actually addresses a need for the user
4. Estimable – a good approximation of when the story is complete can be provided
5. Small – can fit within a single Sprint
6. Testable – there is a method to determine the story works correctly and subsequently there is a method to determine the story is done

Now you might be thinking, “Well, creating user stories is just another thing to do, and it doesn’t directly involve development of the product for this project, so why should I care?” Without user stories your team will hinder your collaboration with the non-technical individuals that either use the product or have road mapped the plan for the product for the next couple of years. Without this collaboration your team will have a tougher time getting the inspiration to form a cross organizational energy to solidify the product. In addition your team may be left out of crucial non-technical product design considerations as the team will likely be viewed (fairly or unfairly) as uninterested in understanding the business details of the project.

Creating user stories will be an opportunity for your team to learn the business domain if there is any confusion over the particular methods of the business. Once the user stories are complete not only will the development team be one step closer towards design and implementation, but your team will form a close relationship built on trust with both the project team, the stakeholders, and the eventual end users. That sounds like a win to me.