User stories anti-patterns

User Stories are used to define requirements.

The word requirement implies something mandatory rather than an exploration.

User stories are conversation tokens. Thus not complete requirements but pieces of a greater conversation.

It is a promise between the delivery team and the stakeholders.

User stories are, in fact, questions without answers, not total fledge solutions.

Without having the token, we will shoot blanks. We can end up filling our team’s backlog with fake User Stories.

Conversations between engineers are valuable if what we are sharing is learning resources.

The conversation will define how to drive the value required for the stakeholder to accept the work done.

This is a contract between both parties.

Creating a user story is a promise that at some point, the business stakeholders and the delivery team will get together to discuss delivering something in that particular area[¹]

Not all User Stories need to become a feature implementation. In fact, the leading utility of User stories is to acquire data about a problem.

Business value can be defined by the Impact that the development efforts provide to the company.