Well-written User Stories provide a solid basis for communication and collaboration — focusing on what matters most to the role of the Story. They help  achieve cross-team clarity on what to build, for whom, and why. The format of a User Story is straightforward and writing them is easy. But writing great ones might be a bit tricky.

User Stories Describe a Business Need from Different Perspectives 

Primarily, a User Story expresses a need from the perspective of a single user, meaning from the point of view of someone who will use the product or the application. That individual expresses the User Story from the perspective of his/her role or set of responsibilities. Each User Story focuses on the outcome of a single interaction between a “user” and the application under development. 

A User Story is justified by the value it provides and is expressed from the perspective of the person who has the need. The business value must express why this particular User Story is needed to give the technical team a fighting chance at prioritizing and scheduling it.

The main purpose of the User Story is to replace documentation with dialogue. User Stories shift the focus from writing about requirements to talking about them. We no longer document requirements to the lowest level of detail. They now serve as a reminder to collaborate about the topic of the User Story. The documentation is secondary to the collaboration. This is a fundamental shift in paradigm.

User Stories are a phenomenal new concept because they focus on something we have been trying to achieve for many years in this industry – the business and technical teams working together to create solutions. This approach will get us higher quality digital solutions in a shorter time.