Member-only story
Contracts for Business Value Delivery
User Stories are not complete requirements but tokens of conversations. More of a *question* than an *answer*. User stories thus represent a contract between stakeholders and the delivery team. Creating a user story promises that the business stakeholders and the delivery team will meet at some point to discuss the details.
User Stories are valuable pieces of functionality required by a customer segment. User stories define business rules. User stories are conversation tokens aimed at delivering business value. Fake user stories describe a *need* for one or more delivery team members.
As a QA
I want the database server to restart to make automated tests faster.
Even when the story above might be a potential source of value for the team, it doesn’t correlate to business impact. Fake user stories create a potential disconnect between what the team pushes out and what the business sponsors care about. Fake user stories produce no significant outcome for the business. Independent and valuable are often difficult to reconcile with a minor. The value of software is a vague and esoteric concept in the domain of business users. Still, task size is controlled by a delivery team, so many couples choose size over value.