Here's one I hear all too often (paraphrased): "Our team doesn't support customer-facing application software.…
What is a User Story?
User stories are short and simple descriptions of capabilities. They are written from the perspective of a user or customer of the system. They typically follow a simple format:
As a [user type], I want [some goal] so that [some reason].
An alternative includes:
As a [user type], I want [some goal] because [why]
Originally, user stories were written on index cards or sticky notes. They were arranged on walls to facilitate planning and discussion. You now find them prominently in any major Agile tool. The physical card or note shifts the focus away from writing about capabilities and toward a shared understanding through discussion. In fact, these discussions are more important than whatever is written in the story.
Examples of user stories
As a [valid user], I want [to access the system] so that [I can review my information].
As an [administrator], I want to [restrict access to the system to valid users] so that [I can ensure we protect user information].
Who writes the user stories?
User stories are written by a business representative in customer specific language. We do this because, we want requirements to be clear to both the business and the development team around what the customer wants and why. The development team’s job is to satisfy the acceptance criteria of the user story. In Scrum, the Product Owner represents the business. At scale, a Product Owner team will complete the activity.
When to write user stories
Last but not least, write user stories throughout the product or project lifecycle. At any time, anyone can write and add new stories to the product backlog. If your delivery team is trying to be predictable, maintain roughly 3 sprints of ready user stories in your product backlog. On larger efforts, write user stories as a subset of features. In these cases, the product owner team collaborates with the delivery team to decompose stories to a sufficient level.